Re: RFC 6604 Clarification

On Mon, Mar 30, 2015 at 2:04 AM, Kumar Ashutosh
<[email protected]> wrote:
> 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.

> 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

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