Re: [Dnsmasq-discuss] DNSSEC BOGUS still replied to with IP
Hey Simon, I was assuming dnsmasq was sending the address to the client as it was able to resolve the page (as in able to access it). However, this could very well have been caused by the client sending out multiple queries and at least one of the were answered with IPs. This seems to be the exact situation DNSSEC was created for. CloudFlare is trying to provide information that is not accurate and should be flagged BOGUS so there is no dnsmasq bug here. Maybe logging was a bit misleading but I should have paid more attention to the replies to the client. Thanks! Best regards, Dominik On Fri, 2019-03-01 at 21:01 +, Simon Kelley wrote: > On 01/03/2019 20:33, Simon Kelley wrote: > > > What's worrying is that Cloudflare and Google are both quite happy that > > the answer is _not_ bogus, but dnsmasq thinks it is. I shall poke around > > some more to try and understand that. > > > > > > > > Answering myself, this appears to be a cloudflare bug, which I've seen > before. Sometimes the Cloudflare servers give a correct answer to a > query for a DS record at vp4.navy.mil with proof that such a record > doesn't exist ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC BOGUS still replied to with IP
On 01/03/2019 20:33, Simon Kelley wrote: > > What's worrying is that Cloudflare and Google are both quite happy that > the answer is _not_ bogus, but dnsmasq thinks it is. I shall poke around > some more to try and understand that. > > > Answering myself, this appears to be a cloudflare bug, which I've seen before. Sometimes the Cloudflare servers give a correct answer to a query for a DS record at vp4.navy.mil with proof that such a record doesn't exist. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec @1.0.0.1 DS vp4.navy.mil ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56156 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1452 ;; QUESTION SECTION: ;vp4.navy.mil. IN DS ;; AUTHORITY SECTION: navy.mil. 2149IN SOA ns1.csd.disa.mil. hostmaster.navy.mil. 2019022501 7200 900 2592000 3600 navy.mil. 2149IN RRSIG SOA 8 2 7200 20190327183033 20190225183033 3624 navy.mil. yXqgMb/KaKhAFD+nK/rOWxRA+e0SNcxFNMduE9JCOF9CLbmEEY79hH0/ aDHC6F+0R3AYRhk3FrZVrZcZTDnbNjHgX8VFI+ffYGJyQ1xL929Fr4pv W+ZBnQlMyZ/XNHcOD23h/03YTP9ZBl40Ham+FdAFAxeHPGieWSzO/g4i mtw= j8j5otdlg2trckk1ihstd584fjv5uh4n.navy.mil. 2429 IN NSEC3 1 0 10 32313032434343 J8UPVKMCB2UQO4TIS8VJACGU4JIFPAFI NS j8j5otdlg2trckk1ihstd584fjv5uh4n.navy.mil. 2429 IN RRSIG NSEC3 8 3 3600 20190327183033 20190225183033 3624 navy.mil. S+Y4RODqxYLEQML5+5qxUk2bp/opzKwinQMrlDufegat4ElU+Cby/tUG Mbew4tYdZFMmMS3G6zGE2xA+zC0Doa3iTK4qYnQ2wHkqj08nwrCi1y3z ruLw8GMowcAgtjc5NtkG+T94N2MiWFM64AqoNeFzGOcfrnUlDS4h1r9l TC4= ;; Query time: 103 msec ;; SERVER: 1.0.0.1#53(1.0.0.1) ;; WHEN: Fri Mar 01 20:46:33 GMT 2019 ;; MSG SIZE rcvd: 523 But then if you repeat exactly the same query and get back the same answer, but without the required DNSSEC records as proof. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec @1.0.0.1 DS vp4.navy.mil ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59281 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1452 ;; QUESTION SECTION: ;vp4.navy.mil. IN DS ;; AUTHORITY SECTION: navy.mil. 3306IN SOA ns1.csd.disa.mil. hostmaster.navy.mil. 2019022501 7200 900 2592000 3600 ;; Query time: 173 msec ;; SERVER: 1.0.0.1#53(1.0.0.1) ;; WHEN: Fri Mar 01 20:46:35 GMT 2019 ;; MSG SIZE rcvd: 106 If dnsmasq gets the second form, it has no choice but to declare the original answer bogus. Running the DS query multiple times to both 1.1.1.1 and 1.0.0.1, the answers seem to be pretty much randomly distributed between correct and incorrect, with about 0.5 probability. 8.8.8.8 gets it right every time. Doing the same thing with a DS query for thekelleys.org.uk, (as another example of an unsigned subomain of a signed, NSEC3-using domain) gives the correct answer all the time, so this looks like some interaction between that particular domain and Cloudflare. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC BOGUS still replied to with IP
On 01/03/2019 18:56, Dominik DL6ER wrote: > Dear list members, > > to my understanding, dnsmasq should not return any valid records for BOGUS > domains. > However, using Cloudflare (1.1.1.1 / 1.0.0.1) as upstream, I see a domains > being > validated as BOGUS in the log, however, the A query still succeeds and the > client > receives valid IP addresses. I'm using dnsmasq v2.80. > > Corresponding log excerpt: > > Mar 1 12:07:43 dnsmasq[28682]: query[A] www.vp4.navy.mil from 192.168.0.135 > Mar 1 12:07:43 dnsmasq[28682]: forwarded www.vp4.navy.mil to 1.0.0.1 > Mar 1 12:07:43 dnsmasq[28682]: dnssec-query[DS] mil to 1.0.0.1 > Mar 1 12:07:43 dnsmasq[28682]: reply mil is DS keytag 59896, algo 8, digest 2 > Mar 1 12:07:43 dnsmasq[28682]: reply mil is DS keytag 59896, algo 8, digest 1 > Mar 1 12:07:43 dnsmasq[28682]: dnssec-query[DS] navy.mil to 1.0.0.1 > Mar 1 12:07:43 dnsmasq[28682]: dnssec-query[DNSKEY] mil to 1.0.0.1 > Mar 1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 59896, algo 8 > Mar 1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 10428, algo 8 > Mar 1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 15450, algo 8 > Mar 1 12:07:43 dnsmasq[28682]: reply navy.mil is DS keytag 33826, algo 8, > digest 2 > Mar 1 12:07:43 dnsmasq[28682]: reply navy.mil is DS keytag 33826, algo 8, > digest 1 > Mar 1 12:07:43 dnsmasq[28682]: dnssec-query[DS] vp4.navy.mil to 1.0.0.1 > Mar 1 12:07:43 dnsmasq[28682]: Insecure DS reply received, do upstream DNS > servers support DNSSEC? > Mar 1 12:07:43 dnsmasq[28682]: reply vp4.navy.mil is BOGUS DS > Mar 1 12:07:43 dnsmasq[28682]: validation www.vp4.navy.mil is BOGUS > Mar 1 12:07:43 dnsmasq[28682]: reply www.vp4.navy.mil is > Mar 1 12:07:43 dnsmasq[28682]: reply > open-elb-prod-277276106.us-east-1.elb.amazonaws.com is 34.196.13.230 > Mar 1 12:07:43 dnsmasq[28682]: reply > open-elb-prod-277276106.us-east-1.elb.amazonaws.com is 52.0.22.76 > > Is this intended behavior? Is the client actually getting the IP addresses, or are you assuming that it is based on the log? I just ran the same query and got the same logs, but the reply which went back to the client has a SERVFAIL return code, and an empty answer section. What is happening here is that 1.0.0.1 is returning a valid but unsigned answer to the original query, which is being logged. (You can think of the the "reply" noun is the logs as "reply from 1.0.0.1", not "reply to 192.168.0.135".) Dnsmasq fails to prove that an unsigned reply is OK, and therefore labels it as bogus, and turns it into a SERVFAIL reply. What's worrying is that Cloudflare and Google are both quite happy that the answer is _not_ bogus, but dnsmasq thinks it is. I shall poke around some more to try and understand that. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
