Subject: [dnsext] [DNAME] What to do when it points to a non-existing name?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 May 2010 17:18:23 +0200

Testing the new service at .NZ, which uses DNAME to make IDN and LDH
names "equivalent", I ran into the following question, which seems
connected to the DNAME-bis draft.

When the synthetized CNAME goes to a non-existing domain, what does a
recursive resolver return?  NXDOMAIN? NOERROR? BIND and Unbound behave
differently. Unbound (and the maintainer claims he is right and that
no RFC mandates a specific behaviour):

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

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

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

;; ANSWER SECTION:
xn--mori-qsa.dns.net.nz. 86400	IN	DNAME	maori.dns.net.nz.
doesnotexistatall.xn--mori-qsa.dns.net.nz. 0 IN	CNAME doesnotexistatall.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: 622 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue May 25 16:53:51 2010
;; MSG SIZE  rcvd: 181

BIND:

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

; <<>> DiG 9.7.0-P1 <<>> ANY doesnotexistatall.xn--mori-qsa.dns.net.nz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 425
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;doesnotexistatall.xn--mori-qsa.dns.net.nz. IN ANY

;; ANSWER SECTION:
xn--mori-qsa.dns.net.nz. 74662  IN      DNAME   maori.dns.net.nz.
doesnotexistatall.xn--mori-qsa.dns.net.nz. 0 IN CNAME doesnotexistatall.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: 306 msec
;; SERVER: 192.134.7.248#53(192.134.7.248)
;; WHEN: Tue May 25 16:54:16 2010
;; MSG SIZE  rcvd: 186

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 May 2010 02:05:55 +1000

In message <[email-masked]>, Stephane Bortzmeyer writes:
> recursive resolver return?  NXDOMAIN? NOERROR?
>
> BIND and Unbound behave

First pass:

         If a DNAME record exists at that point, copy that record into
         the answer section.  If substitution of its <target> for its
         <owner> in QNAME would overflow the legal size for a <domain-
         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
         perform the substitution and continue.  If the query was not
         extended [EDNS0] with a Version indicating understanding of the
         DNAME record, the server SHOULD synthesize a CNAME record as
         described above and include it in the answer section.  Go back
         to step 1.

Adds 

Second pass:

         If the "*" label does not exist, check whether the name we are
         looking for is the original QNAME in the query or a name we
         have followed due to a CNAME.  If the name is original, set an
         authoritative name error in the response and exit.  Otherwise
         just exit.

RFC 2308 makes NAME ERROR the correct response.

Note this is a ambiguity that exists in RFC 1034 and is not specific
to DNAME.  A plain CNAME pointing to a non-existing name also reaches
this paragraph for qtypes other than "*".  For qtype "*" you exit
via this path.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

To make qtype any + DNAME consistent with qtype any + CNAME one would
have to address to NOT go back to step 1, but rather just go to step 6 on
qtype "*".

> ;; WHEN: Tue May 25 16:53:51 2010

Which says the name exists (RFC 2308) so is wrong.  You can not add
the SOA to the  authority section and have NOERROR or set NXDOMAIN
with or without the SOA in the authority section.  You don't set
NOERROR and add the SOA unless the name exist and is empty which
it isn't in this case.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2010 12:17:49 -0400

From RFC 2672 this is what happens when a DNAME is "activated."

Going back to step 1:

    1. Set or clear the value of recursion available in the response
       depending on whether the name server is willing to provide
       recursive service.  If recursive service is available and
       requested via the RD bit in the query, go to step 5, otherwise
       step 2.

    2. Search the available zones for the zone which is the nearest
       ancestor to QNAME.  If such a zone is found, go to step 3,
       otherwise step 4.

    3. Start matching down, label by label, in the zone.  The matching
       process can terminate several ways:

and the part that now matters is:

       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.
...
          If the "*" label does not exist, check whether the name we are
          looking for is the original QNAME in the query or a name we
          have followed due to a CNAME.  If the name is original, set an
          authoritative name error in the response and exit.  Otherwise
          just exit.

Looks like 2672 should have said "CNAME or DNAME" in the last quoted 
paragraph, as well including the presence of DNAME when talking about 
the "*" label, that is what I would have assumed the intent was. 
Both CNAME and DNAME are query-rewrite rules, saying "followed due to 
a CNAME" is just an over-literalization (yes, not a word) of the 
idea.  I bet that paragraph was overlooked in the update of the 
algorithm.

I would accept NoError and no applicable data as the appropriate final answer.

At 17:18 +0200 5/25/10, Stephane Bortzmeyer wrote:
>maori.dns.net.nz.	3600	IN	SOA	loopback.dns.net.nz. 
>soa.nzrs.net.nz. 2010051262 3600 1200 604800 3600
>
>;; Query time: 622 msec
>;; SERVER: ::1#53(::1)
>maori.dns.net.nz.       3600    IN      SOA     loopback.dns.net.nz. 
>soa.nzrs.net.nz. 2010051262 3600 1200 604800 3600
>
>;; Query time: 306 msec

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2010 12:27:13 -0400

>this paragraph for qtypes other than "*".  For qtype "*" you exit

I don't see this.  The problem is in how you read 3.c.  I cut out 
important text to highlight the "goto" control structure.

          If a DNAME record exists at that point, ... Go back
          to step 1.

          If there was no DNAME record, look to see if the "*" label
          exists.

          If the "*" label does not exist, ... set an
          authoritative name error in the response and exit.  Otherwise
          just exit.

          If the "*" label does exist, match RRs at that node against
          QTYPE.  If any match, copy them into the answer section, but
          set the owner of the RR to be QNAME, and not the node with the
          "*" label.  Go to step 6.

The problem is that in 1034 this passage, I am told, was meant as a 
guide to developers, not pseudo-code.  If I look at the passage as 
updated in 2672, it seems like it reads as if the editor thought it 
was pseudo-code.

The question to ask, before DNAME, if CNAME went to an non-existent 
name, it seems to me that because we had followed a CNAME we'd 
"Otherwise just exit" because there was something at the original 
QNAME, just not what we wanted.

I would extend this to the DNAME era, and would "read" the DNAME rfc 
as if it was mid-edited, over-literalizing, etc.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 26 May 2010 09:04:01 +0200

Hi George,

>> no RFC mandates a specific behaviour):

OK, now I see 1034 4.3.2-3-c.  The query name is not the original name,
therefore the name error is not set.  This is for CNAMEs, but a DNAME
(having a synthesized CNAME to go with it) is to be treated the same I
should think.

> [snip]
> 
> I think it must return a name error (NXDOMAIN). 

Not that that is impossible, its just not what I thought the specs say.

> From RFC 1034, Section 4.3.1
> <<
> If recursive service is requested and available, the recursive response
> to a query will be one of the following:
> 
>    - The answer to the query, possibly preface by one or more CNAME
>      RRs that specify aliases encountered on the way to an answer.
> 
>    - A name error indicating that the name does not exist.  This
>      may include CNAME RRs that indicate that the original query
>      name was an alias for a name which does not exist.
>>>

Yes that points to name error possible.

> 
> That seems quite explicit to me.
> 
> The section just below
> 
> does not apply for recursive service.

one) yes this does apply to recursive service, it even talks about using
the resolver and cache.

two) this is indeed the 'if the name is original' text.

three) it's weird for authority and recursor to send a different rcode
for the same event (cname to not-existing-name).

> My take is that Unbound is erronesous here.
> It seems to get it wrong even in the plain CNAME case ( I made a test ).
> DNAME should surely be treated the same as CNAME, although I have not
> attempted to verify what the DNAME standard says.

This was by design...

> 
> Hmm.. I feel a bit uneasy now, as if  I'm missing something.

Yes, I admit to taking my understanding of NSD (authority service) and
thus that line in the wildcard treatment, and coding Unbound's CNAME
behaviour from that.

Best regards,
   Wouter