In message <20150813133446.78c4228...@orac.inputplus.co.uk>, Ralph Corderoy wri
tes:
> Hi Paul,
>
> > >> "added" really does just mean "added" not "inserted".
> > >
> > > I don't know what that means. If you add something to an unordered
> > > set and then ask for the contents of the set, the order you'll get
> > > its contents is undefined.
> >
> > why do you call a section a "set"?
>
> Because it isn't stated anywhere that they're not just a bag of things
> that are added to, and `added' isn't `append'? It may seem pedantic,
> but it has helped allow different interpretations to spread over the
> years.
RFC 1034 says to add to the answer. Not added to a list that will
then be compiled into a answer with possible reordering once all
the records have been collected. OO programing has a lot to answer
for here.
The entire section is detailed instructions on how to construct the
wire response piece by piece.
Once the CNAME is found and added, the answer should be in the state
+---------------------------------------------------+
Header | OPCODE=QUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=EXAMPLE.NET., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | EXAMPLE.NET. TTL IN CNAME EXAMPLE.COM. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
and be ready to send. Now you can do it in other ways but you still
need to come out with the same result.
When the A RRset is found:
+---------------------------------------------------+
Header | OPCODE=QUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=EXAMPLE.NET., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | EXAMPLE.NET. TTL IN CNAME EXAMPLE.COM. |
| EXAMPLE.COM. TTL IN A <value> |
| EXAMPLE.COM. TTL IN A <value> |
| EXAMPLE.COM. TTL IN A <value> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
RFC 1034, 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A show a CNAME response
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
| C.ISI.EDU. 86400 IN A 10.0.0.52 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
> > within an rrset, order doesn't matter, because rrsets are "sets".
>
> Agreed, and even RFC 1034, pre-dating RRsets, says
>
> The set of resource information associated with a particular name is
> composed of separate resource records (RRs). The order of RRs in a
> set is not significant, and need not be preserved by name servers,
> resolvers, or other parts of the DNS.
>
> > within a section, one adds to the end, appending rrsets. order should
> > probably not matter, but it has mattered for a long time and any
> > sender who either scrambles the rr's so that sets are not contiguous
> > or places cname rrsets after the targets they point to is going to
> > lose.
>
> I agree. Unfortunately, the user is the loser who then has to debug
> what's been debugged before by others, followed by trying to get the
> server to change in the face of RFCs that allow ENOTABUG. :-)
>
> > > The question, for the purposes of the protocol definition, is
> > > whether a message section (or maybe just the answer section) is an
> > > ordered set of unordered RRsets. If so, we probably ought to write
> > > that down somewhere, and specify the order, because as near as I can
> > > see it never has been specified.
> >
> > i agree, this ought to be written down somewhere.
>
> Good. I came here not knowing if it was stated, seems consensus is it
> isn't...
>
> > both the contiguity of rrsets, and their ordering within sections,
> > should not have mattered, but now does, due to naive implementors
> > (like me-- i'm the author of the code jinmei posted that freebsd link
> > to a few hours ago.)
>
> ...though there's an obvious order that results from following the RFCs
> in the simple way, and that's allowed parsers to make matching
> assumptions. AFAICS it *should* be possible to state that order such
> that the majority of existing stub resolvers then comply.
>
> Cheers, Ralph.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
