Subject: Re: draft-ietf-dnsext-rfc2672bis-dname-09.txt: CNAME synthesis

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 12:19:30 +1100

> > 	Given the offending text from RFC 1034 is repeated in this
> > 	document we need to address this issue now rather than
> > 	wait.
> 
> 	The offending text for reference.
> 
>            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 or DNAME.  If the name is
>            original, set an authoritative name error in the response and
>            exit.  Otherwise just exit.

	Note we could theoretically fix this for CNAME records by
	banning CNAMEs that point to non-existant names.  We can't
	however do that for DNAME as there will almost certainly
	be synthsised CNAMEs that point to non-existant names.

	If anyone can provide a rational for the quoted text I'd
	like to hear it.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Feb 2008 22:09:20 -0500

At 12:19 +1100 2/8/08, Mark Andrews wrote:

>	banning CNAMEs that point to non-existant names.

It is impossible to definitely decide, in the most general case, if 
the domain name in the RDATA of the CNAME exists (for the zone's 
managing process).  I.e., if the name is like this:

           onename.example. CNAME onename.tld.

With example. and tld. not mutually served authoritatively by any name server.

>>             exit.  Otherwise just exit.

That text is quite unclear, because what is the status of a name that 
is below a DNAME?  In CNAME it is clear, if you followed a CNAME you 
were at a name along the way, hence there's something in the answer 
section.  But DNAME the query is rewritten from "some other" name. 
One way to scratch your head over it is whether a name comes into 
existence because there's a CNAME record generated by the DNAME? 
Whether explicitly or implicitly.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 08 Feb 2008 09:14:00 +0100

Edward Lewis wrote:
| At 12:19 +1100 2/8/08, Mark Andrews wrote:
|
|>     Note we could theoretically fix this for CNAME records by
|>     banning CNAMEs that point to non-existant names.
|
| It is impossible to definitely decide, in the most general case, if the
| domain name in the RDATA of the CNAME exists (for the zone's managing
| process).  I.e., if the name is like this:
|
|           onename.example. CNAME onename.tld.
|
| With example. and tld. not mutually served authoritatively by any name
| server.
|
|>     If anyone can provide a rational for the quoted text I'd
|>     like to hear it.
|
| I assume the quoted text is this:
|
|>>             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 or DNAME.  If the name is
|>>             original, set an authoritative name error in the response
|>> and
|>>             exit.  Otherwise just exit.
|
| That text is quite unclear, because what is the status of a name that is
| below a DNAME?  In CNAME it is clear, if you followed a CNAME you were
| at a name along the way, hence there's something in the answer section.
| But DNAME the query is rewritten from "some other" name. One way to
| scratch your head over it is whether a name comes into existence because
| there's a CNAME record generated by the DNAME? Whether explicitly or
| implicitly.

I think it is very clear. Once you add a CNAME (or DNAME) to the answer
section, then the rcode will be NOERROR (not NXDOMAIN), even if the
rdata of the CNAME does not exist.

Since the answer section is not going to be empty. Even will be filled
with the qname. And the name with a CNAME certainly exists. Thus the
qname domain name exists.

In my opinion, adding the rdata of the CNAME (following the CNAME chain)
is an optional 'nicety' by the server, and therefore does not change the
rcode. The real answer is the CNAME, which exists, which causes the name
to exist, and rcode=NOERROR.

A consequence is that all names below a DNAME come into existance.

Anyway, my interpretation, which seems wildly different from yours :-)

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 19:22:35 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Edward Lewis wrote:

	Yet if you make the same question of a cache you will get
	NXDOMAIN unless QTYPE is CNAME or ANY.
 
> Best regards,
> ~   Wouter
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHrA9IkDLqNwOhpPgRAu81AJ0cF63I+Y3ENzF4YsOe3u3WHWZEcACgpybt
> fPsGS1xqccW5PZhCq7bY8AE=
> =wGdS
> -----END PGP SIGNATURE-----

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 08 Feb 2008 10:09:06 +0100

Mark Andrews wrote:
| Anyway, my interpretation, which seems wildly different from yours :-)
|
|> 	Yet if you make the same question of a cache you will get
|> 	NXDOMAIN unless QTYPE is CNAME or ANY.

Then the cache is wrong (I mean, RFC noncompliant)?
Or does a cache use a different algorithm from the RFC specs?

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 21:09:06 +1100

> Or does a cache use a different algorithm from the RFC specs?

	Note the second point below.

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.

   - A temporary error indication.

	Also note it is possible to argue that "authoritative name
	error" is "add SOA record to authority section".  See 4.3.4.
	Negative response caching (Optional).

	Mark

> iD8DBQFHrBwykDLqNwOhpPgRAhExAJ47ts9PKI+JV5vapcUMQhimYIgl2ACgn4TY
> c1pl70ZDqILk6iuM2OXhDTI=
> =2uzE

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Feb 2008 17:27:31 +0700

Date:        Fri, 08 Feb 2008 19:22:35 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Yet if you make the same question of a cache you will get
  | 	NXDOMAIN unless QTYPE is CNAME or ANY.

How can that possibly be?   NXDOMAIN only occurs when the name being
sought does not exist in the DNS at all, with any RR type (or descendants).

If the name does exist, then NXDOMAIN is simply wrong, whatever RR type
the name might own (including CNAME, and regardless of the value of the
CNAME data field) - and I cannot even begin to imagine how getting the
answer from a cache can possibly make any difference to that.

kre

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 08 Feb 2008 11:52:29 +0100

Mark Andrews wrote:
| Or does a cache use a different algorithm from the RFC specs?
|
|> 	Note the second point below.

|> 	Also note it is possible to argue that "authoritative name
|> 	error" is "add SOA record to authority section".  See 4.3.4.
|> 	Negative response caching (Optional).

OK, you are right, it looks like the authoritative and cache algorithm
differ there. That certainly is inconsistent.

Back to the DNAME draft. It is not going to update RFC1034, but we can
say something sensible there. Perhaps remove some lines and let 1034
handle it, change to 'handle DNAME like encountering a CNAME on the way'?

Or is the text fine the way it is now?

Best regards,
~   Wouter

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Feb 2008 17:49:11 +0700

Date:        Fri, 08 Feb 2008 21:09:06 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Note the second point below.

I think that's a mistake in 1034.

  | If recursive service is requested and available, the recursive response
  | to a query will be one of the following:
[...]

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

Then see 1035, section 4.1.1 ...

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation: 

                3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.

The bit about "only for responses from auth name server" is a bit
obsolete now, we permit caching of NXDOMAIN, but the

	"the domain name referenced in the query does not exist."

is really very clear, and has never been changed.

What's more, even if things were to be extended to allow NXDOMAIN if the
value of a CNAME is a non-existing domain, the difference isn't in whether
the server is a cache or not (aka, whether recursive service is being
provided or not), it would be whether or not the server in question has
data about the existence (or not) of the result of a CNAME.

We know that there is no rule that a non-recursive server must return
only the CNAME if it receives an A lookup of a name that is an alias,
if it has the A record for the canonical name, it returns that as well.

So, if I have

	FOO IN CNAME BAR

	; BAR IN A 10.10.10.10	; deleted last week

(and that was the only record for BAR), then an A lookup aimed at
the server could (if this were the right thing to do, which I do not
believe it is) return

	RCODE=NXDOMAIN (aka Name Error, aka 3)
	ANSWER="FOO IN CNAME BAR"

which is exactly what you're saying a cache would return.   The only
place there's a difference is when the canonical name is (would be) in
a zone for which the server is not auth - then if it isn't recursive,
it won't be able to ascertain whether the canonical name exists or not,
whereas if it is, it can.

Lastly, aside from being absurd to even contemplate (and totally
unenforceable) banning CNAME records containing non-existing names
would not solve this problem (there still needs to be a behaviour
defined), and is the wrong thing to do in any case.

Let's just make it clear that 1035, 4.1.1 (quoted above) is correct,
and RCODE==3 applies only when the name in the query section does not
exist, and in absolutely no other cases whatever.

kre

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 00:14:34 +1100

> is really very clear, and has never been changed.

	RFC 1034 allows a name error to be returned from a cache.
	RFC 2308 allows a authoritive name error to be returned
	from a cache.
	RFC 403[345] allow a name error to be cryptographically
	validiated in the response from a cache.

	In all case the name at the end of the CNAME chain is what
	is being referred to by the name error.

	Prior to RFC 2308 the cache had to make a new query each
	time you got to the end of the CNAME chain then "append"
	the result.  The stub resolver was not expected to do
	this and no stub resolver, as far as I am aware, will issue
	a second query on a CNAME chain the terminates on with NoError.

	Also no stub resolver goes and follows the authority and
	additional sections to retrieve a NXDOMAIN response as you
	interpretation would require them to do as it precludes a
	caching resolver *ever* returning NXDOMAIN whether proceeded
	by CNAMEs or not.

	RFC 1034 and RFC 1035 have lots of errors in them.  They also
	have lots of incomplete ideas.  Negative caching was incomplete
	by RFC 1034's own admission and that seriously impacted on
	how NXDOMAIN responses were described including the text
	which started this thread.

	As for RFC 1035's definition of name error, whether it was
	initially correct or not, it has been superceeded by RFC
	2308 which clearly allow for name error to be return from
	caches.  It also makes no distiction between authoritative
	servers or caches and expects name error at the end of
	CNAMEs in both cases.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Feb 2008 14:47:29 +0000

[kre]
> is really very clear, and has never been changed.

it's not clear to me at all.

> value of a CNAME is a non-existing domain, ...

you mean like this?

	; <<>> DiG 9.4.1 <<>> somewhere.vix.com in a @::1
	; (1 server found)
	;; global options:  printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40272
	;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
	
	;; QUESTION SECTION:
	;somewhere.vix.com.             IN      A
	
	;; ANSWER SECTION:
	somewhere.vix.com.      3600    IN      CNAME   nowhere.vix.com.
	
	;; Query time: 2 msec
	;; SERVER: ::1#53(::1)
	;; WHEN: Fri Feb  8 14:31:13 2008
	;; MSG SIZE  rcvd: 57

i can't think of any other way to signal this.  (the above is from a recursive
DNS implementation made by me from memory, without reference to BIND or RFCs.)

> the difference isn't in whether the server is a cache or not (aka, whether
> recursive service is being provided or not), it would be whether or not the
> server in question has data about the existence (or not) of the result of a
> CNAME.

"has data" won't do, as a standard.  a recursive server has to follow 
out-of-zone cnames and thus, will keep searching until there is a definitive
answer.  an authority server does not have to follow out-of-zone cnames and
so, can return a dangling cname chain (ANCOUNT>0) and no error (RCODE=0) 
which is a partial, nondefinitive result.  if the cname is in-zone, an
authority server will give a definitive result very much like the one above
(which i now realize probably ought to include an SOA RR in its authority.)

> which is exactly what you're saying a cache would return.

that's what everybody does, and it's the only way that a recursive server who
talks to that authority server is going to be able to build a complete CNAME
chain when out-of-zone CNAMEs are allowed.

when i put this question to PVM about ten years ago, he said "out-of-zone
CNAME RRs were never part of my early thinking on DNS, so the spec is
incomplete on that point" and "good luck storming the castle, boys!"

> ... The only place there's a difference is when the canonical name is (would
> be) in a zone for which the server is not auth - then if it isn't recursive,

you mean like this?

	; <<>> DiG 9.4.1 <<>> +bufsize=1500 elsewhere.vix.com in a
	;	@ns.lah1.vix.com
	; (1 server found)
	;; global options:  printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64677
	;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 18
	;; WARNING: recursion requested but not available
	
	;; OPT PSEUDOSECTION:
	; EDNS: version: 0, flags:; udp: 4096
	;; QUESTION SECTION:
	;elsewhere.vix.com.             IN      A
	
	;; ANSWER SECTION:
	elsewhere.vix.com.      3600    IN      CNAME   nowhere.munnari.oz.au.
	
	;; AUTHORITY SECTION:
	.                       518368  IN      NS      I.ROOT-SERVERS.NET.
	...
	
	;; ADDITIONAL SECTION:
	M.ROOT-SERVERS.NET.     604760  IN      A       202.12.27.33
	...
	
	;; Query time: 0 msec
	;; SERVER: 204.152.188.234#53(204.152.188.234)
	;; WHEN: Fri Feb  8 14:43:18 2008
	;; MSG SIZE  rcvd: 624

> defined), and is the wrong thing to do in any case.

right.

> exist, and in absolutely no other cases whatever.

how would an iterative resolver ever build a complete cname chain in that
case, if out-of-zone CNAMEs are present?  i think we have to make it clear
that RFC 1035 did not know about out-of-zone CNAMEs and that when those are
present we have to look at a larger picture than the definition of RCODE=3.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 11:37:31 -0500

>A consequence is that all names below a DNAME come into existance.

What a wacky idea.

When we came up with RFC 4592 we had to have a clearer definition of 
"existence."  Just because a name appears in an answer doesn't mean 
it exists.  (But then, how did it get into the answer?)  Synthesized 
answers, of which wild cards are the one defined mechanism, are the 
alternative to answers from existing names.

To avoid making this long, I won't paste in RFC 4592's section 2.2.3. 
"Yet Another Definition of Existence" section.  But that defines 
existence as things "on the tree" and not "things in answers."

Here's the conflicting "precedents."  CNAME processing removes 
NXDOMAIN from answers that wind up at non-existing names - but the 
(first if a chain) CNAME owner has to equal the QNAME.  Wild cards 
remove NXDOMAIN from any answer in their spheres of influence but 
that's because an answer is being synthesized to overlay the name 
error.  However, wild cards don't cause names to come into being, if 
they did, the wild card would never be invoked (look carefully at RFC 
1034, 4.3.2).

It's not clear to me that I agree.

Ergo, it's a wacky idea.

>Anyway, my interpretation, which seems wildly different from yours :-)

No, really, I asked because I hadn't thought of it before.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 11:43:18 -0500

>	NXDOMAIN unless QTYPE is CNAME or ANY.

I should have included in the previous message, but the mailer sent it out.

That's significant - existence of a name it transferrable from 
authoritative server to cache, synthesis rules are not.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 11:48:04 -0500

>Or is the text fine the way it is now?

Don't rely on analogy to define something ("DNAME like CNAME").  And 
it's clear to me after Robert Elz's point that:

>is really very clear, and has never been changed.

Still, I'm not satisfied with what I am thinking now......
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Robert Elz <[email-masked]>
Date: Sat, 09 Feb 2008 02:50:42 +0700

Date:        Fri, 08 Feb 2008 14:47:29 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i can't think of any other way to signal this.

Huh?   What's difficult, you return the CNAME alone, RCODE==0
just as if it were an out of zone cname.

If that comes from a non-recursive server, then just like any other
incomplete answer from such a server, you make another query, this
time using the canonical name, and you get the answer (data, no data,
or NXDOMAIN as appropriate).

If the answer above is from a recursive server (RA==RD==1) then you
know you have the complete answer, as much as you need anyway, the
name queried exists, but the data you're looking for does not exist
(there's no A, or MX or whatever).

That's all that's needed, there's no difference between that case,
and the empty answer (plus SOA, not a referral, with NS records).
There's no need to have a different kind of application error return
for the case of a dangling CNAME, the data sought doesn't exist,
that's the end of it.

  | "has data" won't do, as a standard.

No, that was shorthand typing...   I think you know what I meant (which
there was just to point out that Mark's recursive vs non-recursive
distinction for different answers being returned wasn't correct, that's
not what would make the difference).

  | a recursive server has to follow out-of-zone cnames and thus,
  | will keep searching until there is a definitive answer.

Of course.

  | an authority server does not have to follow out-of-zone cnames and
  | so, can return a dangling cname chain (ANCOUNT>0) and no error (RCODE=0) 
  | which is a partial, nondefinitive result.

Yes, of course.

  | if the cname is in-zone, an
  | authority server will give a definitive result very much like the one above

That's what I don't think it should do, the name queried did exist, it
should not be NXDOMAIN.

  | (which i now realize probably ought to include an SOA RR in its authority.)

Yeah - but that's hardly relevant just now...

  | that's what everybody does, and it's the only way that a recursive server
  | who talks to that authority server is going to be able to build a
  | complete CNAME chain when out-of-zone CNAMEs are allowed.

Really?   I sure must be missing some problem, as that just doesn't
sound that difficult to me (more packets than we'd like to send perhaps,
but dangling CNAMES also, one hopes, aren't a very common disease.)

  | when i put this question to PVM about ten years ago, he said "out-of-zone
  | CNAME RRs were never part of my early thinking on DNS, so the spec is
  | incomplete on that point" and "good luck storming the castle, boys!"

That's probably true, but it isn't out of zone CNAMEs that we're really
discussing, what the auth server does there is pretty clear, and we agree
on that I think, its in zone CNAMEs where we're disagreeing about what is
the appropriate response.

  | you mean like this?

Yes, but that's boring, and isn't really adding everything, we all
agree (I hope) that that response is correct,

  | how would an iterative resolver ever build a complete cname chain in that
  | case, if out-of-zone CNAMEs are present?

I can't believe that you're asking for a lesson on pointer chasing, so
I won't give one, but ***really***!

  | i think we have to make it clear
  | that RFC 1035 did not know about out-of-zone CNAMEs and that when those are
  | present we have to look at a larger picture than the definition of RCODE=3.

I think it would be OK to make that point somewhere (the first of your
two points), but I'm also not sure it is relevant right now, as that's
actually the easy case.

I kind of suspect that people have been hung up on the idea that if the
canonical name doesn't exist, then its alias cannot exist.  To me that's
just wrong, the alias exists, and no lookup of it should give name error.

I never really paid a lot of attention to all of the DNSSEC stuff about
proof of non-existance, but I can't even imagine the convoluted chain of
logic that would be needed to attempt to authoritatively claim that a
"name error" is correct for a name that demonstratively exists (and for
which, a different query - type=CNAME - would be required to say "does
exist").   That would just be perverse.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 09 Feb 2008 03:14:36 +0700

Date:        Sat, 09 Feb 2008 00:14:34 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	RFC 1034 allows a name error to be returned from a cache.
  | 	RFC 2308 allows a authoritive name error to be returned
  | 	from a cache.
  | 	RFC 403[345] allow a name error to be cryptographically
  | 	validiated in the response from a cache.

Yes, I know, as I said, the part about "only relevant in an auth
answer" is not the way things work, that part was wrong.

  | 	In all case the name at the end of the CNAME chain is what
  | 	is being referred to by the name error.

That part I think is a mistake, it is logically wrong.

  | 	Prior to RFC 2308 the cache had to make a new query each
  | 	time you got to the end of the CNAME chain then "append"
  | 	the result.

Yes.   That's what it needs to do if the data hasn't been included in
the answer - that's clearly needed for an out of zone CNAME reply from
a non-recursive server (there's no other way forward, whether or not
the canonical name exists), doing the same thing for an apparently
in-zone CNAME doesn't seem to be a great burden to me ("apparently"
as there isn't any way to tell (without a bunch of extra queries) if
the canonical name is in the same zone as the alias or not, so there
cannot really be different behaviours.)   What's more, if the
canonical name doesn't exist, then it is impossible to say that
it would have been in the same zone had it existed, we cannot possibly
know (we do sometimes know that it cannot have been in the same zone,
but never that it must have been.)

What I'm trying to say, is that if you get a noerror and a cname, and
no record of the type being queried, then you always MUST do another
query.   By defining the rcode to relate to the end of the (included
in the response, I assume) CNAME chain, all you're really doing is
occasionally saving a query (in the comparatively unusual case of
dangling CNAMEs).    I don't believe that's worth the inconsistency
it generates.

  |     The stub resolver was not expected to do
  | 	this and no stub resolver, as far as I am aware, will issue
  | 	a second query on a CNAME chain the terminates on with NoError.

No, and that's fine, its recursive server (since it returned an answer)
has already done all the work - if there's no terminating type==A (or
whatever the query type was) in the response, then it doesn't exist.
That's no different than simply getting an empty answer, the fact that
there is a CNAME floating in the ether doesn't really change anything.

  | 	Also no stub resolver goes and follows the authority and
  | 	additional sections to retrieve a NXDOMAIN response as you
  | 	interpretation would require them to do

No I don't, why is a NXDOMAIN needed?   All it needs to know is that
the data it sought doesn't exist.   When it fails to find that data
in the response from its cache (back end resolver), it knows all it
needs to know.

  |     as it precludes a
  | 	caching resolver *ever* returning NXDOMAIN whether proceeded
  | 	by CNAMEs or not.

No, I agree that negative answers from caches are fine (and I said
that last time...)

  | 	RFC 1034 and RFC 1035 have lots of errors in them.

Yes.   We are discussing an inconsistency between them, so clearly one
of them is wrong.   The question is, which one?

It has been a long time since I read 2308, I will look at it again.

kre

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 10:59:42 +1100

> not what would make the difference).

	Actually it was making the difference.  You only get to that
	part of the algorithm if you recursion was not requested
	or not available (See step 1).

	ra=0 or rd=0
	QNAME -> no-existant name in zone -> auth name error
	QNAME -> CNAME -> non-existant name in zone -> no error
	QNAME -> CNAME -> name not in zone -> referral
	QNAME -> existant name in zone but no data -> no error
	QNAME -> CNAME -> existant name in zone but no data -> no error

	ra=1 and rd=1
	QNAME -> no-existant name in zone -> name error
	QNAME -> CNAME -> non-existant name in zone -> name error
	QNAME -> CNAME -> non-existant name on other server -> name error
 
	You will note that the following two answer are indistingishable.

	QNAME -> CNAME -> non-existant name in zone -> no error
	QNAME -> CNAME -> existant name in zone but no data -> no error

	I don't think that was ever intended.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 20:10:14 -0500

>	ra=1 and rd=1
...(for clarity, a server willing to do recursion and a query wanting it)

>	QNAME -> CNAME -> non-existant name on other server -> name error

The latter two sound incorrect according to RFC 1035, section 4.1.1 ...

RCODE           3               Name Error - Meaningful only for
                                 responses from an authoritative name
                                 server, this code signifies that the
                                 domain name referenced in the query does
                                 not exist.

Even if the recursion is done by a server that is authoritative for 
the QNAME, the QNAME has to exist for it to have a CNAME.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 12:46:41 +1100

> cannot really be different behaviours.)

	Only if there is not a SOA add or a referral added or
	a NXDOMAIN rcode added.  The real problem is that there
	wasn't a NODATA rcode.  NODATA is inferred.

	It's a rare that none of these are done.

>  What's more, if the
	
	If the stub resolver can't get this information then how is
	it to meet this requirement of RFC 1034?  Think MTA and MX
	query response.
 
5.2. Client-resolver interface

It is important to note that the functions for translating between host
names and addresses may combine the "name error" and "data not found"
error conditions into a single type of error return, but the general
function should not.  One reason for this is that applications may ask
first for one type of information about a name followed by a second
request to the same name for some other type of information; if the two
errors are combined, then useless queries may slow the application.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 14:52:01 +1100

> the QNAME, the QNAME has to exist for it to have a CNAME.

	Yet if you read RFC 1034 they are correct.

	There are inconstancies and errors all through RFC 1034 and
	RFC 1035.

---

From: Robert Elz <[email-masked]>
Date: Sun, 10 Feb 2008 05:24:22 +0700

Date:        Sat, 09 Feb 2008 10:59:42 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Actually it was making the difference.  You only get to that
  | 	part of the algorithm if you recursion was not requested
  | 	or not available (See step 1).

I think some of the problem that we're having is that you're slavishly
following the precise words of 1034, despite (many times) also saying ...

(this particular instance from a reply to Ed Lewis, Sat, 09 Feb 2008
14:52:01 +1100).

That just makes no sense, if they're full of errors (and they are)
then what we need to do is look and see what should be correct, and
then ignore the parts of 1034 (& 1035) which contradict that - those
being the parts we decide are the errors.   Otherwise we have known
inconsistencies, but no method to use to determine what the correct
position should be.

The results you quote are correct if you follow the algorithms in
1034 4.3.2 and 5.3.3 (and if you make some inferences about what
5.3.3 actually says, since it never actually explicitly says what
you believe it does, though I can see you could read it that way).

But as you've pointed out, this doesn't make sense - I think in
one earlier message you even proposed making a CNAME to a non-existing 
canonical name be illegal, to avoid the issue.

But the simpler solution is just to make step 4a of 5.3.3 clearer,
to indicate (as is done in the 4.3.2 algorithm) that you only return
Name Error (or for that matter, any other error) if there was no CNAME
encountered before finding the error.

  | 	You will note that the following two answer are indistingishable.
  | 
  | 	QNAME -> CNAME -> non-existant name in zone -> no error
  | 	QNAME -> CNAME -> existant name in zone but no data -> no error
  | 
  | 	I don't think that was ever intended. 

Intended?  Who knows?   But reasonable?  Why not?   Two things are
of interest here  -  does the data sought exist (no, in both cases),
and does the name used for the lookup exist (yes, in both cases), so
why would anyone care more than that (and if anyone really does care
more, they go get auth answers from auth servers for everything they
need to know, and find out that way - but that's not anything a normal
name resolution would need to do.)

And to avoid cluttering up everyone's mailbox with multiple replies,
the following relates to a different message from you ...

    From: Mark Andrews <[email-masked]>
    Date: Sat, 09 Feb 2008 12:46:41 +1100
    Message-id: <[email-masked]>

Quoting me initially ...

    > cannot really be different behaviours.)

Then ...

    |	Only if there is not a SOA add or a referral added or
    |	a NXDOMAIN rcode added.  The real problem is that there
    |	wasn't a NODATA rcode.  NODATA is inferred.

    |	It's a rare that none of these are done.

I don't agree with the real problem, rcode itself is a problem, a
better solution would have been a synthesised type=ERROR RR response,
where the RDATA contains the error indication (what caused the error,
the TYPE it refers to (including ANY), ...)    But none of that is
really useful now, as that isn't what happened.

In the case we're talking about, I still don't believe the NXDOMAIN
should ever appear, a SOA wouldn't really help, as that might be for
the zone of the QNAME, rather than the canonical name - a referral
would indicate that there was another zone involved.

I'm not sure that discussion of this is getting us any closer to any
kind of solution to the real issue however.

From the same message...

    |	If the stub resolver can't get this information then how is
    |	it to meet this requirement of RFC 1034?  Think MTA and MX
    |	query response.

It doesn't.   Big deal.    That's what I was referring to in a reply a
day or two ago to Paul - sure, sometimes there will be an extra query,
but it should be rare, after all, dangling cnames shouldn't be a very
common thing.

In the normal (common case - the MX lookup, no data, A lookup sequence,
which was very common in the timeframe of 1034, as MX was still somewhat
rare) situation it makes very good sense to be able to avoid the A
lookup when the qname doesn't exist - but the qname being an alias,
and the canonical name not existing is not something we really should be
optimising for.

There are three arguments for accepting the 1035 definition of
Name Error to what you're inferring from 1034 (and which you copied into
2308 I see)  (This is, aside from the "Auth server only" part)

First, 1034 is half in accordance with the 1035 definition (and the part that
isn't, isn't all that clear).

Second, 1035 is the DNS specification, 1034 is just a "how to do it"
(concepts and facilities...) and in general, one would expect the
specification to be more accurate than a "how to" derived from it.

Third, if you delete the part from 1035 about Name Error referring to
the name in the query, then 1035 would be left with no definition of
Name Error at all (there's nothing else there) - nor does anything else
define it, which to me is a pretty strong reason to keep it.

Lastly, there's just plain "what should it be", that is, what makes most
sense, and to me, that's for Name Error to indicate to the client
"the name you gave me is incorrect, the DNS says it does not exist",
rather than: "(the same) or there's some internal configuration error in
the DNS so we can't find the answer for you, even though the name you
searched for does in fact exist".

Keep Name Error to mean a client generated error, and let DNS administrator
mistakes be handled in other ways.

To finish, a question:  Are you special casing Name Error the way you're
claiming it should work, or do you believe that all errors should be
handled the same way (server failure and refused - I doubt format
error and not implemented can ever be an issue)?

kre

---

From: Mark Andrews <[email-masked]>
Date: Sun, 10 Feb 2008 10:43:14 +1100

Name Error - indicates that query processing terminated
	at a non-existant name.

	This covers answers from a cache.
	This covers answers to CNAME and ANY queries.
	This covers answers from an athoratiative server.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 10 Feb 2008 12:39:55 +1100

> name resolution would need to do.)

	For you there are two things of interest.  For me there are
	four things of interest.  Is the original name a alias or
	not, does the resulting name exist or not, if the name exists
	is there data there or not, is the query complete.

	A recursive server delivers all of these.   You get
	NOERROR, NXDOMAIN or YXDOMAIN is the query is complete.
	You get SERVFAIL if the query does not complete.
	You get any CNAMEs/DNAMEs and you get the data or not.

	An athoritative server can deliver these as well.

	If the SOA record is added to NODATA and NXDOMAIN respones
	a authoritative server also delivers all of these.

	no error + SOA -> NODATA regardless of the number of
	preceeding CNAME / DNAME records.

	NXDOMAIN, with or without a SOA, inidicates that processing
	ended in a non-existant name independent of the number of
	CNAME / DNAME records

	It's only when you have "no error and CNAME and no SOA" you
	step into ambiguity.  Some of that can be resolved by seeing
	if there is a referral.  The remaining ambiguity could have
	been (and should have been) address by a "type error" rcode
	or by not making adding of the SOA record optional.

	Note we have a "type error" rcode these days, NXRRSET.

	Your wanting the NXDOMAIN response to mean "The orginal QNAME
	does not exist" does not work with recursive servers.  It
	also introduces additional ambiguity.

	Yes we have to live with some ambiguity as there are old
	servers out there, we don't have to perpetuate that
	ambiguity.

	You also state that CNAME to non-existant is rare.  This
	is currently true in the forward namespace though is becoming
	less so as DNAME if find more use, it is a lot less true
	under ARPA.  RFC 2317 for IN-ADDR.ARPA and DNAME for IP6.ARPA
	fairly often result to CNAME to non-existant.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Sun, 10 Feb 2008 07:31:59 +0700

Date:        Sun, 10 Feb 2008 10:43:14 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Name Error - indicates that query processing terminated
  | 	at a non-existant name.

But that is definitely not what 1035 says, nor is it what the
algorithm for auth servers in 1034 says (which agrees exactly with 1035),
only (perhaps) the algorithm for caches (resolvers) in 1034.

I can think of no good reason why it should be that way.

You also didn't answer the question about the other error codes
in the presence of CNAMEs.

kre

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Feb 2008 09:45:43 +1100

> 	fairly often result to CNAME to non-existant.

	QUERY(AAAA) -> CNAME -> NODATA is quite common in the forward tree.

	www.<something> CNAME <something>
	<something> A 1.2.3.4
 
	This is one of the alternate sources of ambiguity if the
	SOA is not added.  The other is where a referral to the
	root is required and the authoritative server does not have
	the information.

	Mark

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 11 Feb 2008 17:30:00 +0100

Robert Elz wrote:
|     From:        Mark Andrews <[email-masked]>
|   | 	Name Error - indicates that query processing terminated
|   | 	at a non-existant name.
|
| But that is definitely not what 1035 says, nor is it what the
| algorithm for auth servers in 1034 says (which agrees exactly with 1035),
| only (perhaps) the algorithm for caches (resolvers) in 1034.
|
| I can think of no good reason why it should be that way.

It seems to me that the definition of NXDOMAIN is in error, and could be
expanded to include not only that the query name does not exist, but 'a
nonexistant domain was encountered during the processing of the query'.

That could be what Mark means with 'inconsistencies and errors in 1034'.

| You also didn't answer the question about the other error codes
| in the presence of CNAMEs.

They mean the same as for non-CNAMEs, processing errors occurred.

Best regards,
~   Wouter