Subject: [dnsext] CNAME and NXDOMAIN

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2010 22:16:15 -0400

I had this additional thought - if the QNAME is pop.example.tld. and 
I find this:

pop.example.tld.    CNAME      mail.example.tld.

but there is no mail.example.tld...

The answer cannot be NXDOMAIN because there was no error in finding 
the QNAME (=pop.example.tld.).  QNAME owns data, a CNAME.  The fact 
that the CNAME points to nothing is immaterial because the search for 
the name ended and then the QTYPE was matched to CNAME.

The issue is that there is only one RCODE in a return packet and it 
applies to the QNAME, not where the query is redirected.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Mark Andrews <[email-masked]>
Date: Wed, 26 May 2010 12:33:14 +1000

> applies to the QNAME, not where the query is redirected.

No. 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2010 06:47:54 +0000

> Date: Tue, 25 May 2010 22:16:15 -0400
> From: Edward Lewis <[email-masked]>
> 
> I had this additional thought - if the QNAME is pop.example.tld. and I find
> this:
> 

before we start, note, i concur w/ marka, who answered simply:

	From: Mark Andrews <[email-masked]>
	Date: Wed, 26 May 2010 12:33:14 +1000

	No. 

but, let's look deeper.

> The answer cannot be NXDOMAIN because there was no error in finding the
> QNAME (=pop.example.tld.).  QNAME owns data, a CNAME.   ...

your analysis went off the rails right there.

+---
| 3.6.2. Aliases and canonical names
| ...
| RFC 1034             Domain Concepts and Facilities        November 1987
| ...
| CNAME RRs cause special action in DNS software.  When a name server
| fails to find a desired RR in the resource set associated with the
| domain name, it checks to see if the resource set consists of a CNAME
| record with a matching class.  If so, the name server includes the CNAME
| record in the response and restarts the query at the domain name
| specified in the data field of the CNAME record.  The one exception to
| this rule is that queries which match the CNAME type are not restarted.
| ...
| Mockapetris                                                    [Page 15]
+---

having now implemented the recursive logic several times, i can tell you
that "restart the query" has seemed unambiguous to me, it means add a CNAME
to the answer section and then replace the current QNAME with the target of
that CNAME and try again. if in the end the last CNAME target is NXDOMAIN,
then RCODE=NXDOMAIN is the response i have sent back. nobody ever complained
or said that they interpreted RFC 1034 differently than i had.

> ... The fact that the CNAME points to nothing is immaterial because the
> search for the name ended and then the QTYPE was matched to CNAME.

the query processing specified in RFC 1034 says that a CNAME RR can only be
considered an answer if QTYPE=CNAME. i think you meant QNAME not QTYPE above
but if you didn't then you're merely mistaken differently, or confused.

> The issue is that there is only one RCODE in a return packet and it applies
> to the QNAME, not where the query is redirected.

there's no weakness in the spec about this. the fact that there's only one
RCODE means that QCOUNT>1 is undefined, but it does not affect CNAME chains
ending in nonexistent targets. either QTYPE=CNAME in which case no following
will be done and the RCODE is of the CNAME RR itself, or QTYPE<>CNAME in
which case chain-following will be done and RCODE is of the canonical name
(at the end of the CNAME chain) and of the resulting canonical rrset.

here are two illustrative examples:

+---
| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776
| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7
| ;; ANSWER SECTION:
| nxowner.vix.com.        3600    IN      CNAME   nxtarget.vix.com.
| nxowner.vix.com.        3600    IN      RRSIG   CNAME 5 3 3600 ...
+---

and:

+---
| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414
| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
| ;; ANSWER SECTION:
| nxowner.vix.com.        3600    IN      CNAME   nxtarget.vix.com.
| nxowner.vix.com.        3600    IN      RRSIG   CNAME 5 3 3600 ...
| ;; AUTHORITY SECTION:
| vix.com.                3600    IN      NSEC    ns-lah1._meta.vix.com. \
| 	A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
| vix.com.                3600    IN      RRSIG   NSEC 5 2 3600 ...
| nxowner.vix.com.        3600    IN      NSEC    oj.vix.com. \
| 	CNAME RRSIG NSEC
| nxowner.vix.com.        3600    IN      RRSIG   NSEC 5 3 3600 ...
+---

---

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

Hi Paul,

> before we start, note, i concur w/ marka, who answered simply:

However, this line of reasoning is why NOERROR is returned.  Since the
QNAME exists.  And 'if the query is original' line from the algorithm.

> but if you didn't then you're merely mistaken differently, or confused.

Actually, maybe not.  Perhaps the user wants the CNAME that the CNAME is
pointing to with its QTYPE=CNAME?   (or could be pointing to if you
modify your example).  Otherwise, how could the user specify he wanted
the second or third link in the chain of redirections?  It makes sense
to return the entire chain as far as it goes, lookup of the x-th CNAME
in the packet is very easy for the client, making it follow the chain
itself is hard (and the chain may change while it is working on it).

[Ed says:]
>> to the QNAME, not where the query is redirected.

Yes I think this is.  You sometimes also get referrals after a CNAME for
example ... and there is but one AA flag.  (more evidence that QCOUNT!=1
is not easy).

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 May 2010 10:38:05 -0400

> or said that they interpreted RFC 1034 differently than i had.

It seems that at least two people in this thread say they do interpret
1034 differently than you have, though.

With my hat on, this does look as though something clarifying what is
expected (or even saying that more than one response is justified)
could be helpful, assuming we could reach consensus.  But it looks
like a new work item, I think?  Is someone volunteering?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2010 16:21:35 +0000

> Date: Wed, 26 May 2010 09:24:26 +0200
> From: "W.C.A. Wijngaards" <[email-masked]>
> 
> > the query processing specified in RFC 1034 says that a CNAME RR can
> > only be considered an answer if QTYPE=CNAME. i think you meant QNAME
> > not QTYPE above but if you didn't then you're merely mistaken
> > differently, or confused.
> 
> the second or third link in the chain of redirections?

they'd have to chase it one transaction at a time with QTYPE=CNAME on each.

> It makes sense to return the entire chain as far as it goes, lookup of
> the x-th CNAME in the packet is very easy for the client, making it
> follow the chain itself is hard (and the chain may change while it is
> working on it).

QTYPE<>CNAME has exactly that behaviour.

---

From: Noah Treuhaft <[email-masked]>
Date: Wed, 26 May 2010 10:29:58 -0700

> 1034 differently than you have, though.

My reading of RFC 2308 is that it supports Paul's interpretation without
ambiguity (though I've been meaning to get myself to the optometrist for
a while now).

----
RFC 2308                       DNS NCACHE                     March 1998
...
1 - Terminology
...
   "QNAME" - the name in the query section of an answer, or where this
   resolves to a CNAME, or CNAME chain, the data field of the last
   CNAME.  The last CNAME in this sense is that which contains a value
   which does not resolve to another CNAME.  ...
...
2.1 - Name Error

   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
   in the RCODE field.  In this case the domain referred to by the QNAME
   does not exist.  Note: the answer section may have SIG and CNAME RRs
   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
----

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 May 2010 23:35:32 -0400

To try to clarify this issue, I have posted
draft-eastlake-dnsext-xnamercode-00

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]