[Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
Dave Taht
dave.taht at gmail.com
Sat Apr 19 15:12:16 EDT 2014
I just tried a sysupgrade from 3.10.36-1 to 3.10.36-6 and saw this error go by:
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header
The upgrade did indeed succeed, regardless, and kept the files in place.
The only "big" update to the conf files I think I've made to the default
config since -1 was enabling dnssec-check-unsigned by default
in /etc/dnsmasq.conf
Going to go beat up wifi for a while today and look into some other dnssec
issues.
On Sat, Apr 12, 2014 at 11:46 AM, Frits Riep <riep at riepnet.com> wrote:
> 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
> *********************************************
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
More information about the Cerowrt-devel
mailing list