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 <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
> 
> ?
> 
>

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.


Cheers,

Simon.


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

Reply via email to