[Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
Frits Riep
riep at riepnet.com
Sat Apr 12 14:46:22 EDT 2014
I have a Netgear WNDR-3800 and I last updated the firmware about a week ago
successfully using the web interface. I've been trying today to upgrade to
the latest image the same way, but I am not having success and I've tried
the download several times and even with three different browsers but the
result is the same.
Current Image is 3.10.36-3
Using this new image for 3.10.36-4:
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin
Error Message:
The uploaded image file does not contain a supported format. Make sure that
you choose the generic image format for your platform.
Please advise if I need to do something different, or have I found a bug.
thanks
-----Original Message-----
From: cerowrt-devel-bounces at lists.bufferbloat.net
[mailto:cerowrt-devel-bounces at lists.bufferbloat.net] On Behalf Of
cerowrt-devel-request at lists.bufferbloat.net
Sent: Saturday, April 12, 2014 7:54 AM
To: cerowrt-devel at lists.bufferbloat.net
Subject: Cerowrt-devel Digest, Vol 29, Issue 22
Send Cerowrt-devel mailing list submissions to
cerowrt-devel at lists.bufferbloat.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.bufferbloat.net/listinfo/cerowrt-devel
or, via email, send a message with subject or body 'help' to
cerowrt-devel-request at lists.bufferbloat.net
You can reach the person managing the list at
cerowrt-devel-owner at lists.bufferbloat.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Cerowrt-devel digest..."
Today's Topics:
1. Re: wired article about bleed and bloat and underfunded
critical infrastructure (dpreed at reed.com)
2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley)
3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Toke H?iland-J?rgensen)
4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Robert Bradley)
5. Re: cerowrt-3.10.36-4 released (Neil Shepperd)
6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq?
(Robert Bradley)
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT)
From: dpreed at reed.com
To: "Dave Taht" <dave.taht at gmail.com>
Cc: "cerowrt-devel at lists.bufferbloat.net"
<cerowrt-devel at lists.bufferbloat.net>, bloat
<bloat at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
underfunded critical infrastructure
Message-ID: <1397245399.392818481 at apps.rackspace.com>
Content-Type: text/plain; charset="utf-8"
I'm afraid it's not *just* underfunded. I reviewed the details of the code
involved and the fixes, and my conclusion is that even programmers of
security software have not learned how to think about design, testing, etc.
Especially the continuing use of C in a large shared process address space
for writing protocols that are by definition in the "security kernel"
(according to the original definition) of applications on which the public
depends.
Ever since I was part of the Multics Security Project (which was part of the
effort that produced the Orange Book
http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've
known that security-based code should not be exposed to user code and vice
versa. Yet the SSL libraries are linked in, in userspace, with the
application code.
Also, upgrades/changes to protocols related to security (which always should
have been in place on every end-to-end connection) should be reviewed *both
at the protocol design level* and also at the *implementation level* because
change creates risk. They should not be adopted blindly without serious
examination and pen-testing, yet this change just was casually thrown in in
a patch release.
I suspect that even if it were well funded, the folks who deploy the
technology would be slapdash at best. Remember the Y2K issue and the cost of
lazy thinking about dates. (I feel a little superior because in 1968 Multics
standardized on a 72-bit hardware microsecond-resolution hardware clock
because the designers actually thought about long-lived systems (actually
only 56 bits of the original clock worked, but the hardware was not expected
to last until the remaining bits could be added)).
The open source movement, unfortunately, made a monoculture of the SSL
source code, so it's much more dangerous and the vulnerable attack surface
of deployments is enormous.
Rant off. The summary is that good engineering is not applied where it must
be for the public interest. That remains true even if the NSA actually
snuck this code into the SSL implementation.
On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht at gmail.com> said:
> http://www.wired.com/2014/04/heartbleedslesson/
>
> And Dan Kaminisky writes about "Code in the Age of Cholera"
>
> http://dankaminsky.com/2014/04/10/heartbleed/
>
>
>
> --
> Dave T?ht
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140411/
5a81cc38/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 12 Apr 2014 12:06:55 +0100
From: Robert Bradley <robert.bradley1 at gmail.com>
To: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491E4F.4040108 at gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed today that attempts to visit www.cloudflare.com and other
subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when DNSSEC
checks are enabled, but not if I query Google DNS directly.
The resulting queries are:
root at cerowrt:~# dig www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd ;; Got
answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; Query time: 808 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:10 UTC 2014
;; MSG SIZE rcvd: 47
root at cerowrt:~# dig +adflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> +adflag www.cloudflare.com A IN ;; global options:
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3689 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; Query time: 913 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:21 UTC 2014
;; MSG SIZE rcvd: 47
root at cerowrt:~# dig +cdflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> +cdflag www.cloudflare.com A IN ;; global options:
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd ra
cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 297 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 297 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 297 IN A
198.41.212.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
297 IN A 198.41.213.157
;; Query time: 22 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 12 11:04:26 UTC 2014
;; MSG SIZE rcvd: 169
root at cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 www.cloudflare.com A IN ; (1 server found) ;;
global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31488 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 84 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 166 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 166 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
166 IN A 198.41.212.157
;; Query time: 22 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:35 UTC 2014
;; MSG SIZE rcvd: 169
root at cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 server
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 77 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 159 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 159 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
159 IN A 198.41.212.157
;; Query time: 22 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:41 UTC 2014
;; MSG SIZE rcvd: 169
root at cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN
; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 server
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43503 ;; flags: qr rd ra
cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 69 IN CNAME
www.cloudflare.com.cdn.cloudflare.net.
www.cloudflare.com.cdn.cloudflare.net. 151 IN CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 151 IN A
198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.
151 IN A 198.41.212.157
;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 12 11:04:48 UTC 2014
;; MSG SIZE rcvd: 169
root at cerowrt:~#
Can anyone explain why this should be the case?
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
4de94408/attachment-0001.pgp>
------------------------------
Message: 3
Date: Sat, 12 Apr 2014 13:11:56 +0200
From: Toke H?iland-J?rgensen <toke at toke.dk>
To: Robert Bradley <robert.bradley1 at gmail.com>
Cc: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <878urakdj7.fsf at alrua-x1.kau.toke.dk>
Content-Type: text/plain
Robert Bradley <robert.bradley1 at gmail.com> writes:
> Can anyone explain why this should be the case?
If you turn on log-queries in the dnsmasq config, you can see the
results of the dnssec validation in the logs which might give a hint :)
-Toke
------------------------------
Message: 4
Date: Sat, 12 Apr 2014 12:13:25 +0100
From: Robert Bradley <robert.bradley1 at gmail.com>
To: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491FD5.4020600 at gmail.com>
Content-Type: text/plain; charset="utf-8"
On 12/04/2014 12:06, Robert Bradley wrote:
> I noticed today that attempts to visit www.cloudflare.com and other
> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when
> DNSSEC checks are enabled, but not if I query Google DNS directly.
If it helps, it seems to be an issue with dnssec-check-unsigned again.
This time though was via Google's DNS. (Using the Virgin Media DNS
servers, dnssec-check-unsigned kills all DNS as per my previous posts.)
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
04b015bc/attachment-0001.pgp>
------------------------------
Message: 5
Date: Sat, 12 Apr 2014 21:45:09 +1000
From: Neil Shepperd <nshepperd at gmail.com>
To: cerowrt-devel at lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
Message-ID: <53492745.90101 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Bad news, or perhaps "interesting news": I just managed to trigger the
bug while testing with sw00 configured to use sfq. I don't know anything
about the qdiscs code (maybe even sfq and fq_codel share code), but this
might not be a bug in fq_codel...
Still on 3.10.34-4 right now.
On 11/04/14 19:50, David Personette wrote:
> I just thought of it now, but at Dave's suggestion (because of having a
> DSL with only 4/.5), I was using nfq_codel instead of straight up
> fq_codel. Could the difference in the nfq_codel code path have protected
> me from the bug? Just thought that it might be a clue for Felix...
> hopefully not a red herring. Thanks all.
>
> --
> David P.
>
------------------------------
Message: 6
Date: Sat, 12 Apr 2014 12:53:29 +0100
From: Robert Bradley <robert.bradley1 at gmail.com>
To: Toke H?iland-J?rgensen <toke at toke.dk>
Cc: cerowrt-devel <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53492939.4090508 at gmail.com>
Content-Type: text/plain; charset="utf-8"
On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote:
> Robert Bradley <robert.bradley1 at gmail.com> writes:
>
>> Can anyone explain why this should be the case?
> If you turn on log-queries in the dnsmasq config, you can see the
> results of the dnssec validation in the logs which might give a hint :)
>
> -Toke
OK, with log-queries on I get:
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: query[A]
www.cloudflare.com from 127.0.0.1
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: dnssec-query[DS]
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.8.8
Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded
www.cloudflare.com to 8.8.4.4
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com is BOGUS DS
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: validation result
is BOGUS
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com is <CNAME>
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
www.cloudflare.com.cdn.cloudflare.net is <CNAME>
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.213.157
Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.212.157
Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7
nslookup, I see:
11:44:44.884477 IP (tos 0x90, ttl 64, id 16465, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.44272 > 8.8.8.8.53: [udp sum ok] 20890+ [1au] A?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:44.884652 IP (tos 0x90, ttl 64, id 26115, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.44272 > 8.8.4.4.53: [udp sum ok] 20890+ [1au] A?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:44.904068 IP (tos 0x0, ttl 47, id 47459, offset 0, flags [none],
proto UDP (17), length 197)
8.8.8.8.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.212.157,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.213.157 ar: . OPT UDPsize=512 OK (169)
11:44:44.904120 IP (tos 0x0, ttl 45, id 57740, offset 0, flags [none],
proto UDP (17), length 197)
8.8.4.4.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.212.157,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A
198.41.213.157 ar: . OPT UDPsize=512 OK (169)
11:44:44.904720 IP (tos 0x90, ttl 64, id 16466, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.60232 > 8.8.8.8.53: [udp sum ok] 43145+ [1au] DS?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.430963 IP (tos 0x0, ttl 49, id 13829, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.60232: [udp sum ok] 43145 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:45.434094 IP (tos 0x90, ttl 64, id 16467, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.27765 > 8.8.8.8.53: [udp sum ok] 6810+ [1au] AAAA?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.455145 IP (tos 0x0, ttl 47, id 13830, offset 0, flags [none],
proto UDP (17), length 221)
8.8.8.8.53 > 86.1.32.208.27765: [udp sum ok] 6810 q: AAAA?
www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME
www.cloudflare.com.cdn.cloudflare.net.,
www.cloudflare.com.cdn.cloudflare.net. CNAME
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net.,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
2400:cb00:2048:1::c629:d59d,
cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA
2400:cb00:2048:1::c629:d49d ar: . OPT UDPsize=512 OK (193)
11:44:45.455845 IP (tos 0x90, ttl 64, id 16468, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [1au] DS?
www.cloudflare.com. ar: . OPT UDPsize=4096 OK (47)
11:44:45.895583 IP (tos 0x0, ttl 47, id 16395, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:45.896049 IP (tos 0x90, ttl 64, id 26116, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.4.4.53: [udp sum ok] 37758+ [b2&3=0x182]
[1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
11:44:45.896242 IP (tos 0x90, ttl 64, id 16469, offset 0, flags [DF],
proto UDP (17), length 75)
86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [b2&3=0x182]
[1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 OK (47)
11:44:46.335616 IP (tos 0x0, ttl 46, id 44525, offset 0, flags [none],
proto UDP (17), length 75)
8.8.4.4.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
11:44:46.341564 IP (tos 0x0, ttl 47, id 47460, offset 0, flags [none],
proto UDP (17), length 75)
8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS?
www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=512 OK (47)
That seems to suggest that it's the DS queries that are failing and that
this is probably not a dnsmasq bug. Trying Verisign's DNSSEC debugger
(http://dnssec-debugger.verisignlabs.com/blog.cloudflare.com) seems to
suggest that their nameservers refuse requests for DNSKEY records.
--
Robert Bradley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/
f7c270a9/attachment.pgp>
------------------------------
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
End of Cerowrt-devel Digest, Vol 29, Issue 22
*********************************************
More information about the Cerowrt-devel
mailing list