getting NXDOMAIN for existing entry

Wed Jun 12 15:16:05 UTC 2019

Hi Nevel,

Because the servers for havedane.net reply with NXDOMAIN for the name
_tcp.wrong.havedane.net. This is one step above the 25... name, and it
is what qname minimisation attempts to do.  They give dnssec proof too
of the nonexistance of the 25... name.

So, this means the servers are not protocol correct.  And they respond
with both the (dnssec signed) presence and the (dnssec signed) absence
of the TLSA records.  Depends on what you look at first on what the
answer is going to be.  The NXDOMAIN for the _tcp name is wrong, and
should be an empty nonterminal answer.  Likely a flaw in the software on
the server.  And also for the signer I guess, otherwise it would not be
validly dnssec signed, but actually it is dnssec insecure, it seems that
the nsec3 for havedane has optout set.  This is also against the spec,
there should not really be authoritative data under an optout span.

If you turn off qname minimisation unbound first asks for the TLSA and
it seems it works.  But really it doesn't, and does not fail
immediately.  Maybe also for other servers, eg. once you asked for the
_tcp name they may no longer return the TLSAs (or until those time out
and the cache software looks in cache first and finds the valid NXDOMAIN
first).

Best regards, Wouter

dig @2a05:1500:501:1:1c00:6cff:fe00:12d _tcp.wrong.havedane.net. +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17746
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1680
;; QUESTION SECTION:
;_tcp.wrong.havedane.net.    IN    A

;; AUTHORITY SECTION:
havedane.net.        300    IN    SOA    ns091.auroradns.eu.
admin.auroradns.eu. 2019011601 86400 7200 604800 300
havedane.net.        300    IN    RRSIG    SOA 8 2 4800 20190620000000
20190530000000 42609 havedane.net.
otoo7bUY2JuWE6zUCcSNTML5Vw8OQyq5ktlx0FcOEllIxYJEC47jSkOP
DChJNkxiOL5fSKhwakb6TPaMLoksfE5X9DeWQniZzb1iZPO6ntzDeaUv
Sonm0dUp/1wEH5pSwM3pMiI8/D2CeH0qv2hlT3ZQxCl3Y+oTGIbQ0/Op 0tI=
tchk01a6c4u00v4qferegafj8uaa0kuu.havedane.net. 300 IN NSEC3 1 1 10
80052F2BC65F99C0 TCHK01A6C4U00V4QFEREGAFJ8UAA0KUV A AAAA RRSIG
tchk01a6c4u00v4qferegafj8uaa0kuu.havedane.net. 300 IN RRSIG NSEC3 8 3
300 20190620000000 20190530000000 42609 havedane.net.
meZexDBWPuLCY8cwAiFeAEhxroLz+0dgYiuxAeWdODETPVAP3+oPdABJ
v6hTDKXLkHRlg2q8FOBPjOZkbUCnRmf203a8LauZpnFSz101PK//iswP
1fSD/4YvyLVrdIhRUyhlOagsOO+LdGg9vRYTPNgq83ohUI1U09Tq1toV /hI=
kfm2301lp75trvmmcmnjomhet1anrkcc.havedane.net. 300 IN NSEC3 1 1 10
80052F2BC65F99C0 KFM2301LP75TRVMMCMNJOMHET1ANRKCE
kfm2301lp75trvmmcmnjomhet1anrkcc.havedane.net. 300 IN RRSIG NSEC3 8 3
300 20190620000000 20190530000000 42609 havedane.net.
pkNh8bMF5PrVpDkz3vZwme+JEwhknNHS20sslBYAzVO+y0pYqdrGGUOb
TR8ievdPhSd94CchOu4Zg4coRKdPqM3E1j50E20qsrlgpd13LQLJ3h+5
Bwc6Xr1tYrzR2tnx6h2V4emAYVSLPskUWhTRYY0RLJxL0kZqIS+mYD9y UIY=
d75017d9r7ogr9sj2sll546mdo1miven.havedane.net. 300 IN NSEC3 1 1 10
80052F2BC65F99C0 D75017D9R7OGR9SJ2SLL546MDO1MIVEP
d75017d9r7ogr9sj2sll546mdo1miven.havedane.net. 300 IN RRSIG NSEC3 8 3
300 20190620000000 20190530000000 42609 havedane.net.
V5tLLyA7ZMpFBCkSNne+Jzbmob1WCnRufrCJKy7ZudhN7QI7jWivkeGn
AaNRCHvIOyxUV9sY1oh4IuK00uhgqbhF8Elq97M05jaoGP5ItpQW0ic0
32HhSZ/OBy3BUJPhzDoAbF8DJDybeRXoL4SCDgMTYd/vgS1Zj5xmj5qu D6I=

On 12/06/2019 06:13, Nevel Gandish via Unbound-users wrote:
> Hello,
>
> I'm trying to test my mail server with https://havedane.net but it
> will send mails to the subdomain with invalid DANE entry.
> Reason seems, that my local unbound (1.9.0) installation gives
> NXDOMAIN when looking up _25._tcp.wrong.havedane.net
> <http://tcp.wrong.havedane.net>:
>
> ; <<>> DiG 9.10.3-P4-Debian <<>> _25._tcp.wrong.havedane.net
> <http://tcp.wrong.havedane.net> TLSA
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29911
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;_25._tcp.wrong.havedane.net <http://tcp.wrong.havedane.net>.  
> IN      TLSA
>
> ;; AUTHORITY SECTION:
> havedane.net <http://havedane.net>.           103     IN      SOA    
> ns091.auroradns.eu <http://ns091.auroradns.eu>. admin.auroradns.eu
> <http://admin.auroradns.eu>. 2019011601 86400 7200 604800 300
>
>
> Unbound log:
> Jun 11 20:53:27 unbound[8830:0] info: reply from <havedane.net
> <http://havedane.net>.> 185.103.243.231#53
> Jun 11 20:53:27 unbound[8830:0] info: query response was NXDOMAIN ANSWER
> Jun 11 20:53:27 unbound[8830:0] info: 127.0.0.1
> _25._tcp.wrong.havedane.net <http://tcp.wrong.havedane.net>. A IN
> NXDOMAIN 0.451754 0 116
>
>
> But this TLSA RR exists and it's found when using any other NS like
> here (or with @46.182.19.48 <http://46.182.19.48> or @9.9.9.9
> <http://9.9.9.9> or whatever):
>
> ; <<>> DiG 9.10.3-P4-Debian <<>> _25._tcp.wrong.havedane.net
> <http://tcp.wrong.havedane.net> TLSA @8.8.8.8 <http://8.8.8.8>
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22860
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;_25._tcp.wrong.havedane.net <http://tcp.wrong.havedane.net>.  
> IN      TLSA
>
> ;; ANSWER SECTION:
> _25._tcp.wrong.havedane.net <http://tcp.wrong.havedane.net>. 3599
> IN    TLSA    2 1 1
> 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF72
> _25._tcp.wrong.havedane.net <http://tcp.wrong.havedane.net>. 3599
> IN    TLSA    3 1 1
> 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871E
>
>
> I don't know what to look for in my installation or configuration.
> What results do you get when running that request?
>
> Bye,
> Nevel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190612/3a21943c/attachment.htm>