From: "Frits Riep" <riep@riepnet.com>
To: <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
Date: Sat, 12 Apr 2014 14:46:22 -0400 [thread overview]
Message-ID: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> (raw)
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@lists.bufferbloat.net
[mailto:cerowrt-devel-bounces@lists.bufferbloat.net] On Behalf Of
cerowrt-devel-request@lists.bufferbloat.net
Sent: Saturday, April 12, 2014 7:54 AM
To: cerowrt-devel@lists.bufferbloat.net
Subject: Cerowrt-devel Digest, Vol 29, Issue 22
Send Cerowrt-devel mailing list submissions to
cerowrt-devel@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@lists.bufferbloat.net
You can reach the person managing the list at
cerowrt-devel-owner@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@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@reed.com
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>, bloat
<bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and
underfunded critical infrastructure
Message-ID: <1397245399.392818481@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@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@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@gmail.com>
To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491E4F.4040108@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@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@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@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@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@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@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@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@toke.dk>
To: Robert Bradley <robert.bradley1@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <878urakdj7.fsf@alrua-x1.kau.toke.dk>
Content-Type: text/plain
Robert Bradley <robert.bradley1@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@gmail.com>
To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53491FD5.4020600@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@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released
Message-ID: <53492745.90101@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@gmail.com>
To: Toke H?iland-J?rgensen <toke@toke.dk>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via
dnsmasq?
Message-ID: <53492939.4090508@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@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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
End of Cerowrt-devel Digest, Vol 29, Issue 22
*********************************************
next reply other threads:[~2014-04-12 18:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-12 18:46 Frits Riep [this message]
2014-04-12 20:28 ` Sebastian Moeller
2014-04-12 20:42 ` Valdis.Kletnieks
2014-04-13 13:57 ` Joel Stanley
2014-04-14 11:48 ` Frits Riep
2014-04-14 13:17 ` Sebastian Moeller
2014-04-15 0:29 ` Joel Stanley
2014-04-19 19:12 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001cf567f$80b2f1c0$8218d540$@riepnet.com' \
--to=riep@riepnet.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox