Re: RFC 6604 Clarification

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 protected]] 
Sent: Wednesday, April 1, 2015 00:50
To: Kumar Ashutosh
Cc: [email protected]
Subject: Re: [dnsext] RFC 6604 Clarification

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.

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