Subject: [dnsext] RFC 6604 Clarification

From: Kumar Ashutosh <[email-masked]>
Date: Mon, 30 Mar 2015 09:04:33 +0000

Hi
As per RFC 6604, section 3
      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.

This is a little vague on two accounts:

1. What would be the error code if the server decides to curtail the CNAME chain after a certain length (say 20). Is it still success or do we indicate in some other way.

2. If the CNAME chain points to a Qname for which the auth server is non-authoritative (and recursion is disabled on the auth server.) The server in this case cannot get the response. A direct query for this Qname will result in SERV_FAIL. Should the auth server return SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial response?

Can we put a clarification?

Thanks
Ashu
Program Manager | Windows Networking| DNS

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 31 Mar 2015 09:22:19 +0200

Hi Kumar,

I cannot answer on the RFC part, but I want to answer on what will
make the resolver continue the lookup.

On 30/03/15 11:04, Kumar Ashutosh wrote:
> 1.What would be the error code if the server decides to curtail
> the CNAME chain after a certain length (say 20). Is it still
> success or do we indicate in some other way.

The curtailed CNAME chain is best sent with RCODE NOERROR(0).

> 
> 2.If the CNAME chain points to a Qname for which the auth server
> is non-authoritative (and recursion is disabled on the auth
> server.) The server in this case cannot get the response. A direct
> query for this Qname will result in SERV_FAIL. Should the auth
> server return SERV_FAIL in this case? Will resolvers respect
> answers with SERV_FAIL in RCODE and cache the partial response?

You must send the partial response with RCODE NOERROR(0).  Then, the
resolver can retry after the CNAME.

Best regards,
   Wouter

> *Ashu*
> _______________________________________________ dnsext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Jiankang Yao <[email-masked]>
Date: Tue, 31 Mar 2015 22:37:32 +0800

> 在 2015年3月31日，15:22，"W.C.A. Wijngaards" <[email-masked]> 写道：
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi Kumar,
> 

Based on the current text below"
>>   If the xNAME chain terminated without error, it will be zero.
>> "

"Curtail the cname chain" can be regarded as a kind of "terminated without error".
So I agree that it is zero (no error).

Jiankang Yao

---

From: Kumar Ashutosh <[email-masked]>
Date: Tue, 31 Mar 2015 14:32:19 +0000

I agree with the 1st
What about ?
1.	If the CNAME chain points to a Qname for which the auth server is non-authoritative (and recursion is disabled on the auth server.) The server in this case cannot get the response. A direct query for this Qname will result in SERV_FAIL. Should the auth server return SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial response?

Thanks
Ashu
Program Manager | Windows Networking| DNS & SDN

-----Original Message-----
From: dnsext [mailto:[email-masked]] On Behalf Of Jiankang Yao
Sent: Tuesday, March 31, 2015 20:08
To: W.C.A. Wijngaards
Cc: [email-masked]
Subject: Re: [dnsext] RFC 6604 Clarification

>> 1.What would be the error code if the server decides to curtail the 
>> CNAME chain after a certain length (say 20). Is it still success or 
>> do we indicate in some other way.
> 

Jiankang Yao
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 31 Mar 2015 15:20:17 -0400

Kumar Ashutosh writes:
> 1.	If the CNAME chain points to a Qname for which the auth server
> is non-authoritative (and recursion is disabled on the auth server.)
> The server in this case cannot get the response. A direct query for
> this Qname will result in SERV_FAIL. Should the auth server return
> SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL
> in RCODE and cache the partial response? 

It's best to just send NOERROR if you put in a CNAME, even if you
tried to chase it and got your own failure.

While I can't speak for every implementation, I know at least a couple
of major resolvers that will not even bother looking for anything else
beyond the CNAME, even if the target is apparently in the same zone.
By a strict reading of RFC 1034 and RFC 1035, the resolver will
restart the query with the target name by sending a new query to the
relevant authority.

Without going to check the code, I'm honestly not sure what they'd do
with status of SERVFAIL from an authority but an answer section that
started with a CNAME.   RFC 1034 section 5.3.3 puts checking for the
server failure status after checking for the CNAME, and that does
superficially seem to have a certain robustness to it, but I would not
be surprised to discover that some implementers made a different choice.

---

From: Kumar Ashutosh <[email-masked]>
Date: Tue, 31 Mar 2015 19:23:53 +0000

Actually this RFC has created some sort of confusion regarding sending SERV_FAIL as error code.
Will submit for a clarification.

-----Original Message-----
From: Dave Lawrence [mailto:[email-masked]] 
Sent: Wednesday, April 1, 2015 00:50
To: Kumar Ashutosh
Cc: [email-masked]
Subject: Re: [dnsext] RFC 6604 Clarification

> in RCODE and cache the partial response?

It's best to just send NOERROR if you put in a CNAME, even if you tried to chase it and got your own failure.

While I can't speak for every implementation, I know at least a couple of major resolvers that will not even bother looking for anything else beyond the CNAME, even if the target is apparently in the same zone.
By a strict reading of RFC 1034 and RFC 1035, the resolver will restart the query with the target name by sending a new query to the relevant authority.

Without going to check the code, I'm honestly not sure what they'd do with status of SERVFAIL from an authority but an answer section that
started with a CNAME.   RFC 1034 section 5.3.3 puts checking for the
server failure status after checking for the CNAME, and that does superficially seem to have a certain robustness to it, but I would not be surprised to discover that some implementers made a different choice.

---

From: Kumar Ashutosh <[email-masked]>
Date: Tue, 31 Mar 2015 10:53:51 +0000

Thank You Wouter.

The first one seems to be a fair call.
The second case is a little confusing.

Also, I am a little skeptical about sending any partial response with SERV_FAIL as many resolvers may simply reject the data in Serv_fail responses and will cause resolution failures. 

Thanks
Ashu

-----Original Message-----
From: dnsext [mailto:[email-masked]] On Behalf Of W.C.A. Wijngaards
Sent: Tuesday, March 31, 2015 12:52
To: [email-masked]
Subject: Re: [dnsext] RFC 6604 Clarification

Hi Kumar,

I cannot answer on the RFC part, but I want to answer on what will make the resolver continue the lookup.

On 30/03/15 11:04, Kumar Ashutosh wrote:
> CNAME chain after a certain length (say 20). Is it still success or do 
> we indicate in some other way.

> 
> 2.If the CNAME chain points to a Qname for which the auth server is 
> non-authoritative (and recursion is disabled on the auth
> query for this Qname will result in SERV_FAIL. Should the auth server 
> return SERV_FAIL in this case? Will resolvers respect answers with 
> SERV_FAIL in RCODE and cache the partial response?

You must send the partial response with RCODE NOERROR(0).  Then, the resolver can retry after the CNAME.

Best regards,
   Wouter

> _______________________________________________ dnsext mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 31 Mar 2015 15:38:49 -0700

> 2. If the CNAME chain points to a Qname for which the auth server is
> non-authoritative (and recursion is disabled on the auth server.) The server
> in this case cannot get the response. A direct query for this Qname will
> result in SERV_FAIL. Should the auth server return SERV_FAIL in this case?
> Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial
> response?

Just to clarify your question further:

A CNAME chain is normally processed ENTIRELY by the iterative
(recursive) resolver.
In the case of a given authority server being authoritative for the
domain name found on the right-hand-side of a CNAME, as an
optimization, it MAY provide the results of a re-started query using
that RHS value.

It can ONLY do that so long as it is authoritative. If it is not, it
simply returns the data it is authoritative for, with a NOERROR RCODE.

Pointing to a domain name that it is not authoritative for, is not an
error condition.

The iterative resolver would need to continue processing the rewritten
QNAME, by sending the rewritten query to whatever authority server is
authoritative for that new QNAME.

Sending the query to the previous auth server would be the wrong thing
to do. Even if such a query were received, the correct behavior is
NOERRROR, NODATA, with AA unset (set to zero).

If you are not sure you understand this, please ask any clarifying
questions you may have.

Please tell us that MS DNS does NOT do SERV_FAIL, or if it does, that
you are going to fix it. :-)

Brian

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2015 01:17:49 +0100

> On 31 Mar 2015, at 23:38, Brian Dickson <[email-masked]> wrote:
> 

If you send a query to an authoritative-only server for a name for which it isn't authoritative, you should get a referral if the qname is a subdomain of one of the server's zones, or a referral to the root (traditional), or REFUSED. A referral is a bit more than just NOERROR NODATA AA=0 :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 1 Apr 2015 01:11:24 +0000

Hi 

" Sending the query to the previous auth server would be the wrong thing to do. Even if such a query were received, the correct behavior is NOERRROR, NODATA, with AA unset (set to zero).

If you are not sure you understand this, please ask any clarifying questions you may have.

Please tell us that MS DNS does NOT do SERV_FAIL, or if it does, that you are going to fix it. :-)"

For CNAME partial chains, MS DNS servers respond with NOERROR in all the cases till now. We were evaluating to see what RFC 6604 compliance would mean in terms of changes.

For your question above. If a query for A of x.example.com is received on an authoritative server, which does not have any idea of example.com or .com, then it will simply respond with serv_fail. NODATA will be returned only when there is a x.example.com of some other type. 

-----Original Message-----
From: Brian Dickson [mailto:[email-masked]] 
Sent: Wednesday, April 1, 2015 04:09
To: Kumar Ashutosh
Cc: DNSEXT Group Working
Subject: Re: [dnsext] RFC 6604 Clarification

> non-authoritative (and recursion is disabled on the auth server.) The 
> server in this case cannot get the response. A direct query for this 
> Qname will result in SERV_FAIL. Should the auth server return SERV_FAIL in this case?
> Will resolvers respect answers with SERV_FAIL in RCODE and cache the 
> partial response?

A CNAME chain is normally processed ENTIRELY by the iterative
(recursive) resolver.
In the case of a given authority server being authoritative for the domain name found on the right-hand-side of a CNAME, as an optimization, it MAY provide the results of a re-started query using that RHS value.

It can ONLY do that so long as it is authoritative. If it is not, it simply returns the data it is authoritative for, with a NOERROR RCODE.

Pointing to a domain name that it is not authoritative for, is not an error condition.

The iterative resolver would need to continue processing the rewritten QNAME, by sending the rewritten query to whatever authority server is authoritative for that new QNAME.

Sending the query to the previous auth server would be the wrong thing to do. Even if such a query were received, the correct behavior is NOERRROR, NODATA, with AA unset (set to zero).

If you are not sure you understand this, please ask any clarifying questions you may have.

Please tell us that MS DNS does NOT do SERV_FAIL, or if it does, that you are going to fix it. :-)

Brian