Subject: Re: [dnsext] CNAME and NXDOMAIN

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 08:05:46 -0400

At 6:47 +0000 5/26/10, Paul Vixie wrote:

>then RCODE=NXDOMAIN is the response i have sent back. nobody ever complained
>or said that they interpreted RFC 1034 differently than i had.

Except for the implementers at NLnetlabs. ;)

It's good to have multiple, independent implementations.

The reason this hasn't come up before is that no one looks much at 
the trivial cases.  No matter how this is implemented, the request is 
not going to be fulfilled.

(my text is the >> stuff:)
>>  ... 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.

No, I meant the QTYPE was matched to CNAME.  In the section you 
included (and I removed), there's this "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."  Just as we have been seeing in the 
IDN-related "equivalence" discussions, there are more than one way to 
define what "matches."  IN RFC 1034 matching names includes matching 
"*" and matching types includes matching "CNAME" to what we otherwise 
take to be "equivalence."

There's no NXDOMAIN once the name has been found.  Once the name has 
been found, then you switch to matching types.  And that is why the 
CNAME says "restart" - because you now look again for name, and then 
type.

>there's no weakness in the spec about this.

I think there is.  And I think that RFC 2038 is wrong.  RFC 2038 is 
just a Proposed Standard, not vetted to Draft Standard status.  STD 
13 holds more weight, even if it achieved it's status by fiat 
(alleged, I've never seen a citation).

>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 ...
>+---

This because it pretty much solidifies in my mind that the server 
that returned this is buggy - assuming both returns were from the 
same serial number of the zone.  How can a name both exist and not 
exist?  nxowner.vix.com was found in the first query and then was 
"lost" in the latter.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Donald Eastlake <[email-masked]>
Date: Tue, 8 Jun 2010 10:27:33 -0400

To help facilitate the resolution of this question I have written a draft,
current version
http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02

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

On Tue, Jun 8, 2010 at 8:05 AM, Edward Lewis <[email-masked]> wrote:

> The reason this hasn't come up before is that no one looks much at the
> trivial cases.  No matter how this is implemented, the request is not going
> to be fulfilled.
>
> No, I meant the QTYPE was matched to CNAME.  In the section you included
> (and I removed), there's this "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."  Just as we
> have been seeing in the IDN-related "equivalence" discussions, there are
> more than one way to define what "matches."  IN RFC 1034 matching names
> includes matching "*" and matching types includes matching "CNAME" to what
> we otherwise take to be "equivalence."
>
> There's no NXDOMAIN once the name has been found.  Once the name has been
> found, then you switch to matching types.  And that is why the CNAME says
> "restart" - because you now look again for name, and then type.
>
>
> I think there is.  And I think that RFC 2038 is wrong.  RFC 2038 is just a
> Proposed Standard, not vetted to Draft Standard status.  STD 13 holds more
> weight, even if it achieved it's status by fiat (alleged, I've never seen a
> citation).
>
>
> This because it pretty much solidifies in my mind that the server that
> returned this is buggy - assuming both returns were from the same serial
> number of the zone.  How can a name both exist and not exist?
> nxowner.vix.com was found in the first query and then was "lost" in the
> latter.
>
>
> --

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jun 2010 00:46:45 +1000

> exist?  nxowner.vix.com was found in the first query and then was 

The first query say "does nxowner.vix.com exist and is it a alias".
The second query say "does nxowner.vix.com exist and is there a AAAA
record there otherwise is nxowner.vix.com a alias and does that exist
and is there a AAAA record there otherwise is it a alias and does that
exist .....".  You asked very different question.

The answers are self consistant and there is no ambiguity.

Mark
-- 
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: Tue, 08 Jun 2010 15:47:38 +0000

> Date: Tue, 8 Jun 2010 08:05:46 -0400
> From: Edward Lewis <[email-masked]>
> ...

we just disagree. cname's are not meant to be processed at the application
layer -- the only reason we return cname chains at all is to inform the app
why we answered with a different owner name than they were asking about. if
we're going to treat CNAME as "existing" even if it points at nothing, then
we would also have allowed MX's and NS's to point at CNAME's. a CNAME is a
hard link not a soft link, and if it points at nothing, then it's a "name
error" which is what RCODE 3 is described as, even though we pronounce it
"no such domain".

> weight, even if it achieved it's status by fiat (alleged, I've never seen a

perhaps others should chime in, since our disagreement is pretty clear here.

> > ...
> > ...

if we match on the QTYPE then it's not a name error since when QTYPE=CNAME
we are explicitly asking about the alias and overriding the alias-following.

> nxowner.vix.com was found in the first query and then was "lost" in the

on the second query QTYPE<>CNAME and so the alias-following logic was not
disabled and so the restart led to RCODE 3 ("name error") which is not, no
matter how we might like to pronounce "NXDOMAIN", the same as "no such name".

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Jun 2010 13:02:54 -0400

...
> perhaps others should chime in, since our disagreement is pretty clear here.

While I'm willing to be persuaded, I agree with Ed on this one.

To continue Paul's filesystem analogy, CNAMEs would pretty much have
to be symlinks, because they can point to other partitions (zones).

But there are other reasons.  A CNAME RR constitutes an RRset, can be
signed, can be proven to exist or not to exist, etc.  One can query
for it explicitly and get back a perfectly sane response.

There is no reason why a purely authoritative nameserver for a zone
containing a CNAME that points out of zone could not return an answer
of the form RCODE=0, ANCOUNT=1, with the CNAME as the sole RR in the
answer section (add DNSSEC if zone is signed).  The authoritative
nameserver in question is under no obligation whatsoever to chase down
the target of the CNAME.

By analogy, I would expect similar results for an in-zone CNAME to a
target that doesn't exist; one would like to think that zone
maintenance tools would detect and try to prevent this, but that's not
really the nameserver's problem, and the resolver has to cope with the
possibility.

In either case, if the resolver wants more information, it can restart
the query itself at the target name (or the last target name, in the
case of a muli-link CNAME chain).

So I agree with Ed that the real problem here is that the protocol
semantics aren't rich enough to express the morass of possible
resolution result states that a recursive nameserver might need to
send back to a recursive client.  This might be grounds for future
work (EDNS extended RCODEs, anybody?).

As far as I can remember, the "don't allow NS and MX to point to
CNAME" was not because the protocol couldn't support those, it was
because somebody (perhaps PVM) argued that the double indirection was
anti-social: an unnecessary waste of the resolver's time by the zone
owner, who could have just used the "real" name (remember that CNAME
started out as the analogue of nickname fields in HOSTS.TXT, with an
assumption that every host had a "real" name and zero or more
nicknames).  I sort of buy the anti-social argument, have never really
bought the purported stronger arguments that all hell would break
loose if this were allowed (in modern terms, I interpreted the
original restriction as a SHOULD NOT, not a MUST NOT).  This
discussion may have finally pinpointed the underlying disconnect.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Jun 2010 13:13:40 -0400

> perhaps others should chime in, since our disagreement is pretty clear here.

I'd like to suggest that people go and read and comment on
http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02.  That
draft (wich Donald volunteered to write the last time this flared up)
is an attempt to lay things out systematically.  Is it right? 

Thanks,

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Jun 2010 05:27:00 +0900

Isn't RFC1034 clear enough?

   - 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.

						Masataka Ohta

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 08 Jun 2010 17:25:24 -0400

+1

-- 
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
Phone: +1 978-936-0001                     Boxborough, MA  01719-2205

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 17:53:17 -0400

I hate to do this, but the below statement is below this precondition:

# If recursive service is requested and available, the recursive response
# to a query will be one of the following:

...so, name error only include this in recursive situations?  (I say 
with a voice inflection of - now this beats me....)

I don't mean to argue against...but...RFC 1034 is so hard to read definitively.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Jun 2010 07:27:11 +0900

Edward Lewis wrote:

> ...so, name error only include this in recursive situations?
> (I say with a voice inflection of - now this beats me....)

	Note that the name server should never perform recursive
	service unless asked via RD, since this interferes with
	trouble shooting of name servers and their databases.

> I don't mean to argue against...but...RFC 1034 is so hard to read

It took me one minuite to find the relevant parts in this and the
previous mails.

Then, I wasted more than 10 minuites to read what is discussed.

You all should first learn to read before writing something.

						Masataka Ohta

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 08 Jun 2010 18:41:41 -0400

> I don't mean to argue against...but...RFC 1034 is so hard to read

It isn't clear that this case of combining CNAMEs and name-error is
limited to recursion, though it is mentioned only in that case. The
non-recursive section below the section Ohta cited mentions nothing
about following or returning any CNAMEs at all.

I will admit that the Algorithm in 4.3.2 indicates that one would not
return name error when a CNAME has been traversed and one is still
looking in an authoritative zone.  In step 3.c it says:

         c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.

            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.

But stop 4 of that algorithm (matching in the cache) mentions nothing
about CNAMEs at all, and also doesn't really factor in negative caching.
And the text in the resolver algorithm around processing CNAME responses
is also open to interpretation, basically saying "if the answer is in
local information, return it to the client", and "if the response
answers the question or contains a name error... [return] it back to the
client."

I think this is an important reason why 2308 is needed to clarify
negative answers, and it handles this case explicitly.  My +1 was
because I agree with the text cited by Ohta, free of any constraining
context, and I think 2308 reflects that as well.

-josh

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jun 2010 09:17:50 +1000

We need RFC 1034-bis but given how poorly we do -bis documents
	I'm scared to start down that path.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 19:15:16 -0400

>context, and I think 2308 reflects that as well.

Going back over the thread, when I initially prepared a response it 
was to support the way BIND treats the situation and not the way NSD 
does.  But in looking through the RFCs, I completely changed my 
opinion before my first post.  I think there's clear statements in 
support of the NSD handling, but there are places where the RFCs also 
support BIND's way.

What I mean to say, despite my seeing a fairly strong "evidence" 
supporting the NSD way and the, basically, dilemma of how I can't see 
a QNAME getting NXDOMAIN for one QTYPE and not another, there are 
also droplets of text that strongly support BIND's way.  Given that 
my first reaction was to side with BIND, I have a feeling that that 
approach is correct - it wasn't until I dove into the passages of RFC 
1034 that I was swayed to agree with NSD.

The NSD way is closer to the "strict interpretation" of the protocol, 
but more pragmatically, the BIND tells you that the system failed to 
locate the name where the answer should be.  Hence the "Name *Error*".

My conclusion is that the specifications aren't clear.  I would think 
that rewriting them in favor of name error for an essentially 
dangling CNAME chain.

Am I willing to write a "CNAME-clarify?"  You gotta be kidding.[0] 
(Besides, Donald's draft is already there.)

[0] Referring to the back lash over wildcard-CLARIFY and 
axfr-CLARIFY, neither of which was exactly a clarification...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 09 Jun 2010 10:29:56 +0200

Hi Ed,

> locate the name where the answer should be.  Hence the "Name *Error*".

My best interpretation [at the current time] is that 1034 appears to say
that for authoritative zones NOERROR is the strict interpretation and
for recursive lookups (+RD flag) NXDOMAIN.

> that rewriting them in favor of name error for an essentially dangling
> CNAME chain.

Yes, I agree.

Best regards,
   Wouter

---

From: Ray Bellis <[email-masked]>
Date: Wed, 9 Jun 2010 08:54:58 +0000

> for recursive lookups (+RD flag) NXDOMAIN.

For what it's worth, that's my interpretation too.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jun 2010 15:43:25 +0000

> From: Ray Bellis <[email-masked]>
> Date: Wed, 9 Jun 2010 08:54:58 +0000
> 
> > My best interpretation [at the current time] is that 1034 appears to
> > say that for authoritative zones NOERROR is the strict interpretation
> > and for recursive lookups (+RD flag) NXDOMAIN.
> 

strangely, i see what you mean, and if this were day 1 of DNS i could
live with that interpretation. however, i think if we were to clarify
it today we'd take account of the installed base.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 19 Jun 2010 14:31:08 -0400

Hi,

> is an attempt to lay things out systematically.  Is it right?

I believe Andrew's question above is whether that draft correctly describes
the two alternative view so that, for example, it could be used as the basis
for a consensus call. I don't think anyone has responded to this question...
I think it does describe them clearly.

Thanks,
Donald

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 19 Jun 2010 15:45:37 -0400

On Sat, Jun 19, 2010 at 02:31:08PM -0400, Donald Eastlake wrote:
> for a consensus call. 

Yes, this was exactly my question.  Thanks for clarifying.

And yes, responses are needed, please.

A

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jun 2010 12:24:48 -0400

>And yes, responses are needed, please.

I'm responding to thank Donald for taking the initiative to do the 
right thing - form a draft to capture this.

Beyond that I'm not much help.  Outside of once believing alternative 
B was true and then diving into the spec and coming out believing 
alternative A was true, I can't add much.  Through in that I've then 
seen other parts of the spec that support alternative B again.

The difference is very fine, not a common case.  The difference is 
seen only when examining the implementations that have diverged 
because of the unclear specification.

I could really live with either alternative, mostly because it isn't 
an earth shattering matter.

For the sake of closure we should fix this.  But when it comes to the 
practicality of the debate, we'd be more productive ... cleaning up a 
oil spill somewhere.

I do not mean to demean's Donald's document nor am trying to be 
sarcastic.  Just trying to justify why I haven't had anything to add 
to Donald's document.

The World Cup would be more fun if they didn't interrupt it with soccer games.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 28 Jun 2010 22:42:05 -0400

I also agree that B is the best alternative and should be the
mandatory behavior.

Thanks,
Donald

On Tue, Jun 22, 2010 at 1:30 PM, George Barwood
<[email-masked]> wrote:
> It's my view that alternative 3.B is correct.
>
>    When an xNAME chain is followed, all but the last query cycle
>    necessarily had no error. The RCODE in the ultimate DNS response MUST
>    BE set based on the final query cycle leading to that response. If
>    the xNAME chain was terminated by an error, it will be that error
>    code. If the xNAME chain terminated without error, it will be zero.
>
> If the final query cycle gives rise to a NXDOMAIN, then there must be a
> NXDOMAIN
> NSEC proof in the response, and a validating resolver will check that this
> proof is correct.
>
> It would be bizarre I think for the RCODE not to match the NSEC proof that
> is present.
>
> George
>
> ----- Original Message -----
> From: Donald Eastlake
> To: [email-masked]
> Sent: Tuesday, June 08, 2010 3:27 PM
> Subject: Re: [dnsext] CNAME and NXDOMAIN

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 29 Jun 2010 09:19:58 -0400

I think the I-D captures the alternatives correctly, and I agree that
"B" is the best alternative, as well as being consistent with RFC 2308.

-josh