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

2019-09-11 Thread Simon Kelley
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

2019-09-11 Thread Tore Anderson
* 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

2019-09-04 Thread Tore Anderson
* 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

2019-09-03 Thread Simon Kelley
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

2019-09-03 Thread Simon Kelley
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

2019-09-03 Thread Tore Anderson
* 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

2019-09-03 Thread Tore Anderson
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

2019-09-03 Thread Tore Anderson
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

2019-09-03 Thread Simon Kelley
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 

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

2019-09-03 Thread Simon Kelley
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