On Wed, Sep 28, 2016 at 09:26:38PM +0000, Stephane Bortzmeyer wrote:
> On Mon, Sep 26, 2016 at 12:33:39PM +0100,
> Ólafur Guðmundsson <[email protected]> wrote
> a message of 148 lines which said:
>
> > The RCODE applies to the RRSET pointed to by the last CNAME in answer
> > section (or the missing one).
>
> This specific case was settled in RFC 6604 and I did not intend to
> reopen it. My problem was with the definition of QNAME, not with the
> proper rcode for a chain of CNAME.
By the way, is it the case that CNAMEs in the answer section MUST
appear in their natural chaining order:
A. IN CNAME B.
B. IN CNAME C.
C. IN CNAME D.
D. IN CNAME E.
Which is to say can stub resolvers assume that this is always the
case, or would it prudent to reassemble the list by finding the
CNAME whose owner is the qname, and using the target alias to find
the name CNAME, ... recursively without making assumptions about
the order in which the records appear?
I am writing some code in Haskell that process DNS responses, and
made no assumptions about CNAME ordering in the response, because
Haskell is recursive anyway and finding the starting point rather
than using the first remaining response is easy enough. So this
code is more robust in the face of unexpected CNAME ordering,
irrelevant CNAME responses that are even part of the chain, ...
What I'm wondering about is whether this is just quaint pedantry,
encouraged by a language that makes it all too easy, or sensibly
defensive programming... :-)
Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034
imply that responses MUST contain any CNAMEs in the typically
expected order? And, if so, is it then the case that clients
(wether stub or iterative) need make no effort to deal with responses
that are not so ordered? Should clients take care to deal with
CNAMEs in the answer section that don't form a linear chain (out
of order, or not even possible to re-order as a linear chain).
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
