On 23/04/14 16:42, Dave Taht wrote: > I will argue that a better place to report dnssec validation > errors is the dnsmasq list. > > On Wed, Apr 23, 2014 at 8:31 AM, Aaron Wood <[email protected]> wrote: >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: query[A] >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net from 172.30.42.99 >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.4.4 >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is BOGUS DS >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: validation result is >> BOGUS >> Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply >> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is 2.20.28.186 >> >> This one validates via verisign, however. >>
Something strange in that domain. Turning off DNSSEC with the checking-disabled bit, the original A-record query is OK ; <<>> DiG 9.8.1-P1 <<>> +cd @8.8.8.8 a e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45416 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN A ;; ANSWER SECTION: e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. 19 IN A 23.195.61.15 ;; Query time: 112 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Apr 23 16:52:06 2014 ;; MSG SIZE rcvd: 81 But a query for DS on the same domain, which is what dnsmasq does next, returns SERVFAIL, _even_with_ checking disabled. ; <<>> DiG 9.8.1-P1 <<>> +cd @8.8.8.8 ds e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44148 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN DS ;; Query time: 149 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Apr 23 16:52:30 2014 ;; MSG SIZE rcvd: 65 Dnsmasq does the DS query next because the answer to the A query comes back unsigned, so dnsmasq is looking for a DS record that proves this is OK. It's likely that Verisign does that top-down (starting from the root) whilst dnsmasq does it bottom up. Hence Verisign never finds the broken DS, whilst dnsmasq does. That's as good an analysis as I can produce right now. Anyone who can shed more light, please do. (And yes, please report DNSSEC problems on the dnsmasq-discuss list for preference.) Cheers, Simon. _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
