Puzzling behavior with DNAME

I'm playing with māori domain names
<http://www.te-reo.maori.dns.net.nz/&gt; and Unbound's behavior surprises
me.

There is a DNAME from māori.dns.net.nz (xn--mori-qsa.dns.net.nz) to
maori.dns.net.nz:

% dig ANY te-reo.xn--mori-qsa.dns.net.nz
...
;; ANSWER SECTION:
xn--mori-qsa.dns.net.nz. 86400 IN DNAME maori.dns.net.nz.
te-reo.xn--mori-qsa.dns.net.nz. 0 IN CNAME te-reo.maori.dns.net.nz.
te-reo.maori.dns.net.nz. 3437 IN A 202.160.48.39

When the name does not exist, a BIND resolver tells me NXDOMAIN:

% dig ANY tagadatsointsoin.xn--mori-qsa.dns.net.nz
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57869

But Unbound 1.4.1 tells me NOERROR, which seems wrong:

% dig ANY tagadatsointsoin.xn--mori-qsa.dns.net.nz

; <<>> DiG 9.5.1-P3 <<>> ANY tagadatsointsoin.xn--mori-qsa.dns.net.nz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3907
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;tagadatsointsoin.xn--mori-qsa.dns.net.nz. IN ANY

;; ANSWER SECTION:
xn--mori-qsa.dns.net.nz. 86400 IN DNAME maori.dns.net.nz.
tagadatsointsoin.xn--mori-qsa.dns.net.nz. 0 IN CNAME tagadatsointsoin.maori.dns.net.nz.

;; AUTHORITY SECTION:
maori.dns.net.nz. 3600 IN SOA loopback.dns.net.nz. soa.nzrs.net.nz. 2010051262 3600 1200 604800 3600

;; Query time: 290 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue May 25 13:43:40 2010
;; MSG SIZE rcvd: 179

I confess I have little experience with DNAMEs. Am I wrong to say that
Unbound is wrong?

Hi Stephane,

The reason I put NOERROR in there is because, like with a CNAME, if a
CNAME is followed the answer is NOERROR not NXDOMAIN. I thought this is
part of the spec (the CNAME algorithm).

Best regards,
   Wouter

Hi Stephane,

But I cannot find text in the RFCs about this. I know that NOERROR can
be both NXDOMAIN or 'no RR type' for validation. This I could also not
find in RFC. BIND behaves differently in different versions...

Best regards,
   Wouter

Stephane Bortzmeyer wrote:

I'm playing with māori domain names
<http://www.te-reo.maori.dns.net.nz/&gt; and Unbound's behavior surprises
me.

I'd like to add the behavior from Unbound is strange (yes, I already
read Wouter response).

The authoritative nameservers for maori.dns.net.nz and
xn--mori-qsa.dns.net.nz are the same and run BIND9.

Saying that, if you ask any of them for the query Stephane sent, you get
an NXDOMAIN response:

secastro@klendathu:~$ dig ANY tagadatsointsoin.xn--mori-qsa.dns.net.nz
@ns1.dns.net.nz +norec

; <<>> DiG 9.6.1-P2 <<>> ANY tagadatsointsoin.xn--mori-qsa.dns.net.nz
@ns1.dns.net.nz +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8271
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;tagadatsointsoin.xn--mori-qsa.dns.net.nz. IN ANY

;; ANSWER SECTION:
xn--mori-qsa.dns.net.nz. 86400 IN DNAME maori.dns.net.nz.
tagadatsointsoin.xn--mori-qsa.dns.net.nz. 0 IN CNAME
tagadatsointsoin.maori.dns.net.nz.

;; AUTHORITY SECTION:
maori.dns.net.nz. 3600 IN SOA loopback.dns.net.nz. soa.nzrs.net.nz.
2010051262 3600 1200 604800 3600

;; Query time: 16 msec
;; SERVER: 202.46.190.130#53(202.46.190.130)
;; WHEN: Wed May 26 12:10:37 2010
;; MSG SIZE rcvd: 173

Because the nameserver queried in authoritative for both zones,
according to RFC2672, Section 4.1, 3.c: "If at some label, a match is
impossible (i.e., the corresponding label does not exist), look to see
whether the last label matched has a DNAME record.", then the
substitution is performed and the resulting name is searched again,
leading to a NXDOMAIN.

So I'm not completely clear which steps is Unbound taking to handle that
query which led to a NOERROR response, but sounds interesting to know.

Cheers!

Hi Sebastian,

Stephane Bortzmeyer wrote:

I'm playing with māori domain names
<http://www.te-reo.maori.dns.net.nz/&gt; and Unbound's behavior surprises
me.

I'd like to add the behavior from Unbound is strange (yes, I already
read Wouter response).

Because the nameserver queried in authoritative for both zones,
according to RFC2672, Section 4.1, 3.c: "If at some label, a match is
impossible (i.e., the corresponding label does not exist), look to see
whether the last label matched has a DNAME record.", then the
substitution is performed and the resulting name is searched again,
leading to a NXDOMAIN.

Well when you search again you encounter the line 'if the QNAME is
original', which it is not.

So I'm not completely clear which steps is Unbound taking to handle that
query which led to a NOERROR response, but sounds interesting to know.

Well, over at namedroppers (the IETF DNSEXT working group mailing list)
you can see me get yelled at by the protocol experts :slight_smile:
[http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01420.html ]

That mailing list is the right place to find what the right rcode is.
Of course unbound should send out the proper rcode and be able to accept
leniently what it receives from other servers.

Best regards,
   Wouter