Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
On 04/09/2019 18:40, Tore Anderson wrote: > > (By the way, I did send the promised PCAP yesterday. However, because the > message was >40KB, it was queued for moderation by the mailing list > administrator.) > So you did, it's there, as are several others, which raises the question of why mailman didn't email me about it. it did, but over-enthusiastic spam-removal rules in my procmail deleted it. Fixed now, I think. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Tore Anderson > I can confirm that Dnsmasq 69a0477 resolves www.linuxquestions.org and > www.ipv6.org.uk as expected (DNSSEC state insecure). Great work, thanks! Apologies, I botched my test (using the wrong upstream server). It does *not* work, but the error is different: $ src/dnsmasq -d -p 5353 dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile dnsmasq: DNSSEC validation enabled dnsmasq: configured with trust anchor for keytag 20326 dnsmasq: configured with trust anchor for keytag 19036 dnsmasq: using nameserver 87.238.33.1#53 dnsmasq: cleared cache dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DS] uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 dnsmasq: reply . is DNSKEY keytag 59944, algo 8 dnsmasq: reply . is DNSKEY keytag 20326, algo 8 dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS [...] This query is repeated ~44 times in a tight loop. It makes a total of 50 queries before giving up, I guess it hits a built-in limit. PCAP attached. It seems to happen with *all* Insecure domain names (not only those that have CNAMES pointing to other Secure domain names). Tore foo.pcap Description: application/vnd.tcpdump.pcap ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Simon Kelley > OK. I think I see the problem.. > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e24abf28a29574069717af78c1d3e0ede64388ff > > should fix. It does indeed. Good catch! (By the way, I did send the promised PCAP yesterday. However, because the message was >40KB, it was queued for moderation by the mailing list administrator.) Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
On 03/09/2019 18:29, Tore Anderson wrote: > * Tore Anderson > >> Apologies, I botched my test (using the wrong upstream server). It does >> *not* work, but the error is different: >> >> $ src/dnsmasq -d -p 5353 >> dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 >> dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 >> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify >> dumpfile >> dnsmasq: DNSSEC validation enabled >> dnsmasq: configured with trust anchor for keytag 20326 >> dnsmasq: configured with trust anchor for keytag 19036 >> dnsmasq: using nameserver 87.238.33.1#53 >> dnsmasq: cleared cache >> dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 >> dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DS] uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 >> dnsmasq: reply . is DNSKEY keytag 59944, algo 8 >> dnsmasq: reply . is DNSKEY keytag 20326, algo 8 >> dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 >> dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 >> dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 >> dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 >> dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> [...] >> >> This query is repeated ~44 times in a tight loop. It makes a total of 50 >> queries before giving up, I guess it hits a built-in limit. >> >> PCAP attached. >> >> It seems to happen with *all* Insecure domain names (not only those that >> have CNAMES pointing to other Secure domain names). > > Bisected: > > ae7a3b9d2e8705af203a1347c397718a24331747 is the first bad commit > commit ae7a3b9d2e8705af203a1347c397718a24331747 > Author: Simon Kelley > Date: Tue Sep 3 14:40:47 2019 +0100 > > DNSSEC: implement RFC-4036 para 5.3.3. rules on TTL values. > > :04 04 52d7ead3d28019308dff0cb0dfcd80e4ef0341de > 60ff380eb9c6b813d5081dee470d276be2109480 M src > > If I revert this one, www.ipv6.org.uk and www.linuxquestions.org both resolve > fine (as Insecure). So the fix in 69a0477 seems good. > OK. I think I see the problem.. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e24abf28a29574069717af78c1d3e0ede64388ff should fix. Simon. > Tore > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
On 03/09/2019 18:29, Tore Anderson wrote: > * Tore Anderson > >> Apologies, I botched my test (using the wrong upstream server). It does >> *not* work, but the error is different: >> >> $ src/dnsmasq -d -p 5353 >> dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 >> dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 >> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify >> dumpfile >> dnsmasq: DNSSEC validation enabled >> dnsmasq: configured with trust anchor for keytag 20326 >> dnsmasq: configured with trust anchor for keytag 19036 >> dnsmasq: using nameserver 87.238.33.1#53 >> dnsmasq: cleared cache >> dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 >> dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DS] uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 >> dnsmasq: reply . is DNSKEY keytag 59944, algo 8 >> dnsmasq: reply . is DNSKEY keytag 20326, algo 8 >> dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 >> dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 >> dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 >> dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 >> dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: reply ipv6.org.uk is no DS >> [...] >> >> This query is repeated ~44 times in a tight loop. It makes a total of 50 >> queries before giving up, I guess it hits a built-in limit. >> >> PCAP attached. >> >> It seems to happen with *all* Insecure domain names (not only those that >> have CNAMES pointing to other Secure domain names). > > Bisected: > > ae7a3b9d2e8705af203a1347c397718a24331747 is the first bad commit > commit ae7a3b9d2e8705af203a1347c397718a24331747 > Author: Simon Kelley > Date: Tue Sep 3 14:40:47 2019 +0100 > > DNSSEC: implement RFC-4036 para 5.3.3. rules on TTL values. > > :04 04 52d7ead3d28019308dff0cb0dfcd80e4ef0341de > 60ff380eb9c6b813d5081dee470d276be2109480 M src > > If I revert this one, www.ipv6.org.uk and www.linuxquestions.org both resolve > fine (as Insecure). So the fix in 69a0477 seems good. > > Ah well, one step forward, one step back. Needless to say, this doesn't occur with 8.8.8.8 as upstream server, so the promised, but missing, pcap would be useful to track it down. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Tore Anderson > Apologies, I botched my test (using the wrong upstream server). It does *not* > work, but the error is different: > > $ src/dnsmasq -d -p 5353 > dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 > dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP > DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile > dnsmasq: DNSSEC validation enabled > dnsmasq: configured with trust anchor for keytag 20326 > dnsmasq: configured with trust anchor for keytag 19036 > dnsmasq: using nameserver 87.238.33.1#53 > dnsmasq: cleared cache > dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 > dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DS] uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 > dnsmasq: reply . is DNSKEY keytag 59944, algo 8 > dnsmasq: reply . is DNSKEY keytag 20326, algo 8 > dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 > dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 > dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 > dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 > dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 > dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > [...] > > This query is repeated ~44 times in a tight loop. It makes a total of 50 > queries before giving up, I guess it hits a built-in limit. > > PCAP attached. > > It seems to happen with *all* Insecure domain names (not only those that have > CNAMES pointing to other Secure domain names). Bisected: ae7a3b9d2e8705af203a1347c397718a24331747 is the first bad commit commit ae7a3b9d2e8705af203a1347c397718a24331747 Author: Simon Kelley Date: Tue Sep 3 14:40:47 2019 +0100 DNSSEC: implement RFC-4036 para 5.3.3. rules on TTL values. :04 04 52d7ead3d28019308dff0cb0dfcd80e4ef0341de 60ff380eb9c6b813d5081dee470d276be2109480 M src If I revert this one, www.ipv6.org.uk and www.linuxquestions.org both resolve fine (as Insecure). So the fix in 69a0477 seems good. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
Hi again, > OK. scratch that. Looks like we just captured an irrelevant key-rollover. > > The problem here is that the reply to the original query contains an > unsigned RRset of NS records in the auth section. Said NS records are in > a signed zone, which flags them as bogus. As far as I can see, that's > correct for records in the answer section, but for records in the auth > section, it merely renders the reply as insecure. That would seem to > make the AD bit rather useless, but I guess it's useless anyway. > > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=69a0477b741c1f8195c64417fec4a92a50c9291a > > Attempts to fix this. > > Thanks again for your work testing and diagnosing this. I can confirm that Dnsmasq 69a0477 resolves www.linuxquestions.org and www.ipv6.org.uk as expected (DNSSEC state insecure). Great work, thanks! Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
Hi Simon, > A quick bit of differential analysis of the first query reveals that the > problem is the mythic-beasts.com DNSKEY RRset. > > 8.8.8.8, and the mythic-beasts authoritative server I tried gives the > following answer for that RRset. > > ;; ANSWER SECTION: > mythic-beasts.com.86400 IN DNSKEY 257 3 10 > AwEAAaXuiwGP7BTBwrhYj8V+J7VQ+nalXaK3Mo5pXI4x//xD4O8ZN9ZF > CMuvKYhPW+VjsDWYO/QT6KqcqHEErWgYjv/c5vdxJAkM5zfa8UJiOp0q > X2S7RJinMkGqXz05YNp7o+ZE5W/Yykzwfn3k036Mrf4NY9FYKU5uznrc > fzW4vP8vQzXLNBEn+/ErWfbG3mYFjmhYxVsvw0yoIAmhL6xzagdQHJId > vc1G00tqjIFWXwqm3med63G/SX0ggiT/QPwe/D618wibbXu7cUpSjSpP > NxSZg+pX+hejg1DTU6x3UJ6EwMIZWzCccAg0S4KJIy8uOZrifACD4okB OM6yRjFq+TM= > mythic-beasts.com.86400 IN DNSKEY 256 3 10 > AwEAAc5oGCn44Da0km1yuWnqDWJV41f/ieZFaxZxdeRTwsTllcnw3H6a > IHsgYwArtkWqVe9CatuXjBpVmdbS9xJ1V4KrSsGdasCnZpXbtoKKy7Be > tCDUES89uhMG3noqi55rEU5OS3htgmx8fNIuVLuUto5KCbp3O9Rp3+9C > 5yQbW3eZuuDwBDEJ2DgbikiTU80MexCzkhEB3ihXhYYOnEuk4n71cSYB > IM1YcEFaECkLN/meQ077fiAgyF+hkMIzs/VFlA/mOtkNhJeP81lUVT37 > Gjo1w46qWilFtRq1TJTfB47XXDxoLHZZcFmtW9fk6BR/a+4NlxL7X8xI dII0Z9B3I40= > mythic-beasts.com.86400 IN DNSKEY 256 3 10 > AwEAAbiUu+uoyM7HirzFV/VsIO+j0vLNBMcursO6mgjX8cZPrEHKZV0O > NENhRZKrNL0hFVvpjW5I60qxGaBQ+VbcJyK8XMPPnYRnsRDRez9f5I92 > yOJDqjXNca0fj8iqqx9PztolU8SPUebhJgW22GQd2PHkKPDZaUa1Oag2 > OUq6JJRUPwmeZO9dMMtXa3kY/11nj5YoD8FpJPwCZv8VMbVFrORt0kMc > HlpB/hLYpaxzPWKIs95V1o2rL0zxlIkKSwxuZCli7W5ipORB5NM2Vawq > c6m6UfoOabP2SJUm/aTKlom/ZtS4kDaO/9DIeN0F3bG1nLFRRUwRaC4M UjNs4eHCapE= > mythic-beasts.com.86400 IN RRSIG DNSKEY 10 2 86400 20191002000509 > 20190901230509 42918 mythic-beasts.com. > UltVyLHHD+qVowOQIqZLtTc9cA5T/O4t72EiLsgiH9oRjLz7D0MgB+F2 > 0TXv8OoufV3mzf2bjaou1ziIi6FBb5j1RQSqGT44O1zJyQmX40z3LQ3L > UUB6hQU5eh9Q4JTgChHNDpvlvWBTnObTy6NuJn5hdtQKtGN8yZ4gGHM7 > gGB+Y2N595abpWcz9xq2mtXQgGbVJUshe+JfQ3JgU034eDTlvLBTdM73 > HVjpfbxCoMboXOCtjndEB0200gloJSumqdEnlFufWfISqXhruSIB6IKP > 5o2yUSv4mtQUOtVm+RPwcIoprm6ON5Ln2tFHJlgquuJA5vhrIIl+/e99 qarI4Q== > > > Note, three DNSKEY records and the signature that signs the RRset. Note > that this is a self-signature: the signature, along with key 41918 signs > the digest of the set of three records. key 41918 is proved to be valid > by a separate DS record that propagates the chain of trust down from the > .com zone. > > The answer to the same query in your pcap has only two DNSKEY RRs. The > value of the signature is different, so it's possible that this still a > valid, but different, RRset. However dnsmasq thinks it is not valid, and > my feeling is that we should try and answer the question "where has this > RRset come from" before we assume it's valid and dnsmasq is mistaken. > > So, what happens when you ask your upstream server the query > > dig +dnssec DNSKEY mythic-beasts.com > > ? ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> @87.238.33.1 +dnssec DNSKEY mythic-beasts.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50476 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mythic-beasts.com. IN DNSKEY ;; ANSWER SECTION: mythic-beasts.com. 86397 IN DNSKEY 256 3 10 AwEAAbiUu+uoyM7HirzFV/VsIO+j0vLNBMcursO6mgjX8cZPrEHKZV0O NENhRZKrNL0hFVvpjW5I60qxGaBQ+VbcJyK8XMPPnYRnsRDRez9f5I92 yOJDqjXNca0fj8iqqx9PztolU8SPUebhJgW22GQd2PHkKPDZaUa1Oag2 OUq6JJRUPwmeZO9dMMtXa3kY/11nj5YoD8FpJPwCZv8VMbVFrORt0kMc HlpB/hLYpaxzPWKIs95V1o2rL0zxlIkKSwxuZCli7W5ipORB5NM2Vawq c6m6UfoOabP2SJUm/aTKlom/ZtS4kDaO/9DIeN0F3bG1nLFRRUwRaC4M UjNs4eHCapE= mythic-beasts.com. 86397 IN DNSKEY 256 3 10 AwEAAc5oGCn44Da0km1yuWnqDWJV41f/ieZFaxZxdeRTwsTllcnw3H6a IHsgYwArtkWqVe9CatuXjBpVmdbS9xJ1V4KrSsGdasCnZpXbtoKKy7Be tCDUES89uhMG3noqi55rEU5OS3htgmx8fNIuVLuUto5KCbp3O9Rp3+9C 5yQbW3eZuuDwBDEJ2DgbikiTU80MexCzkhEB3ihXhYYOnEuk4n71cSYB IM1YcEFaECkLN/meQ077fiAgyF+hkMIzs/VFlA/mOtkNhJeP81lUVT37 Gjo1w46qWilFtRq1TJTfB47XXDxoLHZZcFmtW9fk6BR/a+4NlxL7X8xI dII0Z9B3I40= mythic-beasts.com. 86397 IN DNSKEY 257 3 10 AwEAAaXuiwGP7BTBwrhYj8V+J7VQ+nalXaK3Mo5pXI4x//xD4O8ZN9ZF CMuvKYhPW+VjsDWYO/QT6KqcqHEErWgYjv/c5vdxJAkM5zfa8UJiOp0q X2S7RJinMkGqXz05YNp7o+ZE5W/Yykzwfn3k036Mrf4NY9FYKU5uznrc fzW4vP8vQzXLNBEn+/ErWfbG3mYFjmhYxVsvw0yoIAmhL6xzagdQHJId vc1G00tqjIFWXwqm3med63G/SX0ggiT/QPwe/D618wibbXu7cUpSjSpP NxSZg+pX+hejg1DTU6x3UJ6EwMIZWzCccAg0S4KJIy8uOZrifACD4okB OM6yRjFq+TM= mythic-beasts.com. 86397 IN RRSIG DNSKEY 10 2 86400 20191002000509 20190901230509 42918 mythic-beasts.com. UltVyLHHD+qVowOQIqZLtTc9cA5T/O4t72EiLsgiH9oRjLz7D0MgB+F2 0TXv8OoufV3mzf2bjaou1ziIi6FBb5j1RQSqGT44O1zJyQmX40z3LQ3L UUB6hQU5eh9Q4JTgChHNDpvlvWBTnObTy6NuJn5hdtQKtGN8yZ4gGHM7 gGB+Y2N595abpWcz9xq2mtXQgGbVJUshe+JfQ3JgU034eDTlvLBTdM73 HVjpfbxCoMboXOCtjndEB0200gloJSumqdEnlFufWfISqXhruSIB6IKP 5o2yUSv4mtQUOtVm+RPwcIoprm6ON5Ln2tFHJlgquuJA5vhrIIl+/e99 qarI4Q==
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
On 03/09/2019 15:45, Simon Kelley wrote: > On 31/08/2019 23:06, Tore Anderson wrote: >> I've noticed that Dnsmasq git master (2.80-68-gfef2f1c) will sometimes >> incorrectly return SERVFAIL and log a Bogus verdict when looking up domain >> names which are Insecure CNAMEs for a Secure names. >> >> For example: >> >> www.ipv6.org.uk. IN CNAME proxy.mythic-beasts.com. >> www.linuxquestions.org. IN CNAME www.linuxquestions.org.cdn.cloudflare.net. >> >> ipv6.org.uk and linuxquestions.org are both Insecure (non-existence of DS >> record in parent zone is proven with signed NSEC3). >> >> proxy.mythic-beasts.com and www.linuxquestions.org.cdn.cloudflare.net are >> Secure, on the other hand. >> >> See http://dnsviz.net/d/www.ipv6.org.uk/dnssec/ and >> http://dnsviz.net/d/www.linuxquestions.org/dnssec/ for detailed analysis. >> >> I have more examples, but I figured two was probably enough. >> >> /etc/dnsmasq.conf contains: >> >> dnssec >> conf-file = /usr/share/dnsmasq/trust-anchors.conf >> log-queries >> no-hosts >> no-resolv >> server=87.238.33.1 >> >> When I try to look up the two problematic hostnames (using "dig @127.0.0.1 >> -p 5353 IN A") I get the following (blank lines inserted for >> clarity): >> >> $ dnsmasq -d -p 5353 >> dnsmasq: started, version 2.80-68-gfef2f1c cachesize 150 >> dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 >> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify >> dumpfile >> dnsmasq: DNSSEC validation enabled >> dnsmasq: configured with trust anchor for keytag 20326 >> dnsmasq: configured with trust anchor for keytag 19036 >> dnsmasq: using nameserver 87.238.33.1#53 >> dnsmasq: cleared cache >> >> dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 >> dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DS] uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 >> dnsmasq: reply . is DNSKEY keytag 20326, algo 8 >> dnsmasq: reply . is DNSKEY keytag 59944, algo 8 >> dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 >> dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 >> dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 >> dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 >> dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 >> dnsmasq: reply ipv6.org.uk is no DS >> dnsmasq: dnssec-query[DS] com to 87.238.33.1 >> dnsmasq: reply com is DS keytag 30909, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] mythic-beasts.com to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] com to 87.238.33.1 >> dnsmasq: reply com is DNSKEY keytag 30909, algo 8 >> dnsmasq: reply com is DNSKEY keytag 17708, algo 8 >> dnsmasq: reply mythic-beasts.com is DS keytag 42918, algo 10, digest 2 >> dnsmasq: dnssec-query[DNSKEY] mythic-beasts.com to 87.238.33.1 >> dnsmasq: reply mythic-beasts.com is DNSKEY keytag 42918, algo 10 >> dnsmasq: reply mythic-beasts.com is DNSKEY keytag 39980, algo 10 >> dnsmasq: validation www.ipv6.org.uk is BOGUS >> dnsmasq: reply www.ipv6.org.uk is >> dnsmasq: reply proxy.mythic-beasts.com is 46.235.225.189 >> dnsmasq: reply proxy.mythic-beasts.com is 93.93.129.174 >> >> dnsmasq: query[A] www.linuxquestions.org from 127.0.0.1 >> dnsmasq: forwarded www.linuxquestions.org to 87.238.33.1 >> dnsmasq: dnssec-query[DS] org to 87.238.33.1 >> dnsmasq: reply org is DS keytag 9795, algo 7, digest 2 >> dnsmasq: reply org is DS keytag 9795, algo 7, digest 1 >> dnsmasq: dnssec-query[DS] linuxquestions.org to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] org to 87.238.33.1 >> dnsmasq: reply org is DNSKEY keytag 9795, algo 7 >> dnsmasq: reply org is DNSKEY keytag 17883, algo 7 >> dnsmasq: reply org is DNSKEY keytag 47612, algo 7 >> dnsmasq: reply org is DNSKEY keytag 44078, algo 7 >> dnsmasq: reply linuxquestions.org is no DS >> dnsmasq: dnssec-query[DS] net to 87.238.33.1 >> dnsmasq: reply net is DS keytag 35886, algo 8, digest 2 >> dnsmasq: dnssec-query[DS] cloudflare.net to 87.238.33.1 >> dnsmasq: dnssec-query[DNSKEY] net to 87.238.33.1 >> dnsmasq: reply net is DNSKEY keytag 59540, algo 8 >> dnsmasq: reply net is DNSKEY keytag 35886, algo 8 >> dnsmasq: reply net is DNSKEY keytag 2129, algo 8 >> dnsmasq: reply cloudflare.net is DS keytag 2371, algo 13, digest 2 >> dnsmasq: dnssec-query[DNSKEY] cloudflare.net to 87.238.33.1 >> dnsmasq: reply cloudflare.net is DNSKEY keytag 34505, algo 13 >> dnsmasq: reply cloudflare.net is DNSKEY keytag 2371, algo 13 >> dnsmasq: validation www.linuxquestions.org is BOGUS >> dnsmasq: reply www.linuxquestions.org is >> dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.158.7 >> dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.159.7 >> >> The upstream DNS server is running BIND 9.9.5 with DNSSEC validation enabled. >> >> I suspect t
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
On 31/08/2019 23:06, Tore Anderson wrote: > I've noticed that Dnsmasq git master (2.80-68-gfef2f1c) will sometimes > incorrectly return SERVFAIL and log a Bogus verdict when looking up domain > names which are Insecure CNAMEs for a Secure names. > > For example: > > www.ipv6.org.uk. IN CNAME proxy.mythic-beasts.com. > www.linuxquestions.org. IN CNAME www.linuxquestions.org.cdn.cloudflare.net. > > ipv6.org.uk and linuxquestions.org are both Insecure (non-existence of DS > record in parent zone is proven with signed NSEC3). > > proxy.mythic-beasts.com and www.linuxquestions.org.cdn.cloudflare.net are > Secure, on the other hand. > > See http://dnsviz.net/d/www.ipv6.org.uk/dnssec/ and > http://dnsviz.net/d/www.linuxquestions.org/dnssec/ for detailed analysis. > > I have more examples, but I figured two was probably enough. > > /etc/dnsmasq.conf contains: > > dnssec > conf-file = /usr/share/dnsmasq/trust-anchors.conf > log-queries > no-hosts > no-resolv > server=87.238.33.1 > > When I try to look up the two problematic hostnames (using "dig @127.0.0.1 -p > 5353 IN A") I get the following (blank lines inserted for clarity): > > $ dnsmasq -d -p 5353 > dnsmasq: started, version 2.80-68-gfef2f1c cachesize 150 > dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP > DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile > dnsmasq: DNSSEC validation enabled > dnsmasq: configured with trust anchor for keytag 20326 > dnsmasq: configured with trust anchor for keytag 19036 > dnsmasq: using nameserver 87.238.33.1#53 > dnsmasq: cleared cache > > dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 > dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DS] uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 > dnsmasq: reply . is DNSKEY keytag 20326, algo 8 > dnsmasq: reply . is DNSKEY keytag 59944, algo 8 > dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 > dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 > dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 > dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 > dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 > dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] com to 87.238.33.1 > dnsmasq: reply com is DS keytag 30909, algo 8, digest 2 > dnsmasq: dnssec-query[DS] mythic-beasts.com to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] com to 87.238.33.1 > dnsmasq: reply com is DNSKEY keytag 30909, algo 8 > dnsmasq: reply com is DNSKEY keytag 17708, algo 8 > dnsmasq: reply mythic-beasts.com is DS keytag 42918, algo 10, digest 2 > dnsmasq: dnssec-query[DNSKEY] mythic-beasts.com to 87.238.33.1 > dnsmasq: reply mythic-beasts.com is DNSKEY keytag 42918, algo 10 > dnsmasq: reply mythic-beasts.com is DNSKEY keytag 39980, algo 10 > dnsmasq: validation www.ipv6.org.uk is BOGUS > dnsmasq: reply www.ipv6.org.uk is > dnsmasq: reply proxy.mythic-beasts.com is 46.235.225.189 > dnsmasq: reply proxy.mythic-beasts.com is 93.93.129.174 > > dnsmasq: query[A] www.linuxquestions.org from 127.0.0.1 > dnsmasq: forwarded www.linuxquestions.org to 87.238.33.1 > dnsmasq: dnssec-query[DS] org to 87.238.33.1 > dnsmasq: reply org is DS keytag 9795, algo 7, digest 2 > dnsmasq: reply org is DS keytag 9795, algo 7, digest 1 > dnsmasq: dnssec-query[DS] linuxquestions.org to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] org to 87.238.33.1 > dnsmasq: reply org is DNSKEY keytag 9795, algo 7 > dnsmasq: reply org is DNSKEY keytag 17883, algo 7 > dnsmasq: reply org is DNSKEY keytag 47612, algo 7 > dnsmasq: reply org is DNSKEY keytag 44078, algo 7 > dnsmasq: reply linuxquestions.org is no DS > dnsmasq: dnssec-query[DS] net to 87.238.33.1 > dnsmasq: reply net is DS keytag 35886, algo 8, digest 2 > dnsmasq: dnssec-query[DS] cloudflare.net to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] net to 87.238.33.1 > dnsmasq: reply net is DNSKEY keytag 59540, algo 8 > dnsmasq: reply net is DNSKEY keytag 35886, algo 8 > dnsmasq: reply net is DNSKEY keytag 2129, algo 8 > dnsmasq: reply cloudflare.net is DS keytag 2371, algo 13, digest 2 > dnsmasq: dnssec-query[DNSKEY] cloudflare.net to 87.238.33.1 > dnsmasq: reply cloudflare.net is DNSKEY keytag 34505, algo 13 > dnsmasq: reply cloudflare.net is DNSKEY keytag 2371, algo 13 > dnsmasq: validation www.linuxquestions.org is BOGUS > dnsmasq: reply www.linuxquestions.org is > dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.158.7 > dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.159.7 > > The upstream DNS server is running BIND 9.9.5 with DNSSEC validation enabled. > > I suspect the problem might be related to something in the Authority or > Additional sections of the answer packet, since I don't get this problem if I