[Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus

Simon Kelley simon at thekelleys.org.uk
Tue Sep 3 15:45:24 BST 2019


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 <hostname> 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 <root> keytag 20326
> dnsmasq: configured with trust anchor for <root> 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 <CNAME>
> 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 <CNAME>
> 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 use 1.1.1.1 or 8.8.8.8 as the upstream server.
> 
> I tested Knot Resolver towards the same upstream server, and it gave the correct Insecure verdict for both queries.
> 
> If I query for the CNAME directly (using "dig @127.0.0.1 -p 5353 <hostname> IN CNAME"), I get a correct Insecure verdict.
> 
> If I query for the domain names the CNAME points to to (proxy.mythic-beasts.com and www.linuxquestions.org.cdn.cloudflare.net), I get a correct Secure verdict.
> 
> I am attaching PCAP files that show the DNS packets between Dnsmasq and the upstream server for the above two queries.
> 
> I'm happy to arrange access to a VM with access to the upstream server which exposes the problem, in case that is helpful.
> 
> Tore 
> 
> 

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

?

Cheers,

Simon.




> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




More information about the Dnsmasq-discuss mailing list