Subject: Re: [DNSOP] Order of CNAME and A in Authoritative Reply.

From: Ralph Corderoy <[email-masked]>
Date: Tue, 11 Aug 2015 17:00:05 +0100

Hi Viktor,

> > Go implements its own resolver rather than use the local libc's,
> > e.g.  glibc's.  All of them are stub resolvers, yes, but if asked to
> > look up foo.bar.local and /etc/resolv.conf has only the
> > authoritative bar.local server in it then they get an authoritative
> > response without a third-party recursive resolver being involved.
> 
> [ Perhaps [email-masked] is the wrong list for this discussion. ]

Agreed, it was pointed out to me off list that [email-masked] would be
better.  I'm happy for it to move, and suggest replies drop the ietf
list from the CC.

For cross-reference, the conversation on ietf starts
https://mailarchive.ietf.org/arch/search/?email_list=ietf&gbt=1&index=wdopuAP2ddLlQcdtX-iAWdUULZ8

> Best practice is to not conflate authoritative and recursive DNS
> servers.  If you put an authoritative rather than a recursive resolver
> in /etc/resolv.conf, that's a misconfiguration.

OK.

> I have a recursive resolver on 127.0.0.1:53 and an authoritative
> nameserver on <public-ip>:53.  The /etc/resolv.conf file lists only
> the recursive server on the loopback address.  The authoritative
> server refuses recursive queries.

That still leaves open the question of whether the stub resolvers can
assume, as many have apparently been doing for years, that they will be
given CNAME before A.

Cheers, Ralph.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Aug 2015 12:10:21 -0400

> assume, as many have apparently been doing for years, that they will be

In general, RRsets aren't ordered.  Now, I think a CNAME response that
also chases the CNAME (and there's a live question about whether the
authoritative-only server ought to do that anyway, but let's assume
it's all in-zone to make this simple) is not returning one RRset in
the answer section, but I don't think there's any promise anywhere
about what order the RRsets come in.  Therefore any client that is
depending on an order has made a mistake.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Tue, 11 Aug 2015 20:12:20 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] Order of CNAME and A in..." ]
>depending on an order has made a mistake.

So this discussion stems from this issue: https://github.com/skynetservices/skydns/issues/217

And apparently the glibc resolver assume this is ordering is in effect.

This btw, has nothing to with the Go language (as implied on the ietf@ thread),
but is just an issue in SkyDNS.

It is also true that (stub)resolvers directly talk to SkyDNS, any recursive
queries are proxied through to a real recursor, but it will authorative answer
for the (single) domain is has configured.

/Miek

--
Miek Gieben

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Aug 2015 20:48:59 -0400

> And apparently the glibc resolver assume this is ordering is in effect.

I wonder what it does if the RRSIG moves around.  (Sorry, I couldn't
resist.)

It seems to me that it would be nice to issue an update to something
(I seem to recall someone wanted to open up 2181, but that's not what
I had in mind) stating explicitly that, when an answer section
contains multiple RRsets, here's how you order them.  I suspect the
answer will be, "You don't," since I can't imagine a principle by
which we could determine this (what if there's a new special
processing case in the future?).  Putting the CNAME first doesn't even
respect alphabetical or numeric order, so that's no use either.  Boo.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Aug 2015 11:21:58 +1000

> I wonder what it does if the RRSIG moves around.  (Sorry, I couldn't

RFC 3045 3.1.1.  Including RRSIG RRs in a Response

> respect alphabetical or numeric order, so that's no use either.  Boo.

In the processing order as described in RFC 1034 Section ?.?.? Algorithm

s/Add/Append/ and there is no dispute.  I doubt anyone thought "Add"
meant insert before records already in the answer and adjust
compression pointers in the existing records.

Mark

> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Wed, 12 Aug 2015 07:27:53 +0100

>I wonder what it does if the RRSIG moves around.  (Sorry, I couldn't

I don't think anyone using SkyDNS has enabled DNSSEC (yet), but yeah.

So we are in agreement that glibc's stub resolver is acting really dumb here?

/Miek

--
Miek Gieben

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Aug 2015 18:53:04 +1000

> So we are in agreement that glibc's stub resolver is acting really dumb here?

No.  Skydns is broken.  glibc could be more robust but it isn't
broken.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Aug 2015 07:17:49 -0400

> RFC 3045 3.1.1.  Including RRSIG RRs in a Response

I assume you meant 4035, but that section says absolutely nothing
about where in the section the RRSIG needs to go.

> compression pointers in the existing records.

"Add" does not mean "add somewhere in particular".  Just because you
interpreted "add" to mean "add at the end" doesn't mean that's what
the words in the text say.

This is another of those dusty corners of the DNS where things have
not been written down clearly.  An RRset is clearly an unordered set.
But I don't see anything (I could well be overlooking something, and
I'd be delighted if I am) about the order of RRsets in a single
section of a message.  RRSIGs are themselves tricky in that respect,
because they're formally not part of the RRset but an RRSIG covers the
RRset and therefore has to travel with it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Aug 2015 07:23:59 -0400

> So we are in agreement that glibc's stub resolver is acting really dumb here?

I think that's overstating it.  It appears that glibc implemented the
protocol according to a widely-held but (at least mostly) undocumented
feature of the protocol.  I think my reading of the documents is more
in line with your interpretation, but as you can see in the thread
Mark thought "add" meant something obvious.  Given the wide deployment
of glibc, it's rather hard to call it "wrong" -- it's got a running
code argument, after all.  I think this is probably a gap in the
specification.  It's hardly the first one in the DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 12 Aug 2015 10:12:34 -0400

> On Aug 12, 2015, at 7:23 AM, Andrew Sullivan <[email-masked]> wrote:
> 

I suspect that it may also have to do, in part, with how the stub resolver performs its bailiwick checks. A cname target may be out of bailiwick if the alias has not come into view yet. Expecting the cname to precede the target could be an implementation short-cut (not saying anything about whether it is right or wrong).

Suresh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Aug 2015 08:45:08 -0700

Suresh Krishnaswamy wrote:
>> ...

i've written plenty of code, some of which you are all running in your
smart phones, that has an expectation of ordering of rrsets within a
section. "added" really does just mean "added" not "inserted".

-- 
Paul Vixie

---

From: Chris Thompson <[email-masked]>
Date: 12 Aug 2015 16:51:38 +0100

>about where in the section the RRSIG needs to go.

It is subliminally suggested by the use of "together", though.

-- 
Chris Thompson
Email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Aug 2015 09:59:19 -0700

At Wed, 12 Aug 2015 07:23:59 -0400,

> specification.  It's hardly the first one in the DNS.

FWIW the stub resolver library in BSD variants derived from a very old
version of BIND (ver 4?) has been behaving that way for more than (in
my understanding) several decades:
https://github.com/freebsd/freebsd/blob/master/lib/libc/net/gethostbydns.c
it goes through the answer section in gethostanswer() as a one-pass
operation, replacing the search name with CNAME target as it sees
CNAMEs.  I suspect it was implemented way before the first stub
resolver of glibc, and I wouldn't even be surprised if the glibc
implementation referred to the BSD behavior.

--
JINMEI, Tatuya

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Aug 2015 13:59:55 -0400

> section. "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.  Indeed, people used to make this mistake with
RRsets.  I remember a particular registrar when we were bringing up
.info trying very hard to get "ns1" to appear "first".  They'd delete
a host object and reinsert it, check the DNS, and it worked.  Then
they'd check again, and the order changed!  So they'd do the same
dance.

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'm not suggesting we try to invalidate lots of deployed software.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Aug 2015 18:17:39 +0000

> I'm not suggesting we try to invalidate lots of deployed software.

As another datapoint, separate from glibc, the Postfix DNS library
assumes that CNAME records in a response from recursive resolver
are ordered so that in any chain of CNAMEs such as:

	A. IN CNAME B.
	B. IN CNAME C.
	...
	L. IN CNAME M.	; logically *and* positionally last

the last CNAME RR in the response is also the logically last link
in the portion of the chain returned by the resolver.  So, while
the resolver may return only an initial segment of the chain, the
last CNAME RR returned is expected to be the last in the alias
chain segment.

There is however no dependence on CNAMEs preceding the final answer
if both are returned.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Aug 2015 11:23:22 -0700

Andrew Sullivan wrote:
> contents is undefined.

why do you call a section a "set"?

within an rrset, order doesn't matter, because rrsets are "sets".

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.

> never has been specified.

i agree, this ought to be written down somewhere. 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.)

-- 
Paul Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Aug 2015 14:25:01 -0400

On Wed, Aug 12, 2015 at 06:17:39PM +0000, Viktor Dukhovni wrote:
> in the portion of the chain returned by the resolver.

This requirement is also interesting, because it's slightly different:
an ordering of different RRsets _of the same RRTYPE_, not of all the
RRsets.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Aug 2015 14:31:37 -0400

> why do you call a section a "set"?

I didn't mean to say that it _is_ one.  I meant that nowhere is this
particularly clear, and there is a natural sense in which they are
sets because they hang together in some way relevant to what was
asked.  (This is the general reason why data from the additional
section can't be promoted to be used as answers, for example.)

So if people want it to be clear that RRsets are sets but message
sections are not sets, it would be a responsible thing to write that
down.  That's all I'm trying to say.  I think we agree about this
(since that's what you also said).

A

-- 
Andrew Sullivan
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Aug 2015 15:32:08 -0300

How specific is the ordering dependency by resolver code variant? by
version?

If this becomes a candidate for typing specific resolvers, its useful
knowledge

-G

---

From: Ralph Corderoy <[email-masked]>
Date: Wed, 12 Aug 2015 19:54:31 +0100

Hi Andrew,

Andrew Sullivan wrote:
> > That still leaves open the question of whether the stub resolvers
> > can assume, as many have apparently been doing for years, that they
> > will be given CNAME before A.
...
> but I don't think there's any promise anywhere about what order the
> RRsets come in.  Therefore any client that is depending on an order
> has made a mistake.

I don't know if you went back to the ieft list and read this thread's
conversation there, but my stance is I also don't think it's stated
anywhere, but stub resolvers seem to vary in the assumptions they make
and it should therefore be stated more precisely.  Further, given the
large number of stub resolvers that won't get fixed, but continue to be
in service, the statement should perhaps legitimise their assumptions so
as many as possible of them become compliant.  They've effectively gone
and created a de facto bit of the standard.

Cheers, Ralph.

---

From: Ralph Corderoy <[email-masked]>
Date: Wed, 12 Aug 2015 19:59:11 +0100

Hi Miek,

> So this discussion stems from this issue:
> https://github.com/skynetservices/skydns/issues/217

I deliberately didn't mention that so as to avoid getting into specifics
of one case when it clearly seems to be a more general issue.  :-)

> And apparently the glibc resolver assume this is ordering is in

Amongst others.

> This btw, has nothing to with the Go language (as implied on the ietf@
> thread), but is just an issue in SkyDNS.

I did not imply it had anything to do with Go, I merely sampled Go's
stub resolver in my potted survey.  It's actually the one that comes out
best since it re-starts parsing the whole packet, as I stated.

> It is also true that (stub)resolvers directly talk to SkyDNS, any
> recursive queries are proxied through to a real recursor, but it will
> authorative answer for the (single) domain is has configured.

AIUI, forgetting SkyDNS exists, it's allowable for a stub resolver to be
configured to talk to a server that can answer authoritatively for the
CNAME and the A, thus some clarification may be needed.

Cheers, Ralph.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Aug 2015 08:12:31 +1000

> CNAME and the A, thus some clarification may be needed.

Stub resolvers are written as if they are talking to recursive
*servers*.  A lot of assumption break when that is not met.  Whether
those servers have authoritative zones on not is irrelevent.  The
question is do they build a response that is consistent with a RA=1
response (for when the server contains the entire DNS universe for
that stub client otherwise I would be saying it require RA=1).

DiG warns about non RA=1 answers for RD=1 queries because this
usually indicates a error either in resolv.conf pointing a non
recursive server or failure to clear RD=1 when talking to a
authoritative only server.

---

From: Ralph Corderoy <[email-masked]>
Date: Thu, 13 Aug 2015 12:26:55 +0100

Hi G,

> If this becomes a candidate for typing specific resolvers, its useful

It varies quite a bit with the few I looked at, see
https://mailarchive.ietf.org/arch/msg/ietf/wdopuAP2ddLlQcdtX-iAWdUULZ8
for the ones we surveyed.

    So an (A foo?) query greeted with an (A bar=1, CNAME foo=bar, A
    bar=2) reply would have 4.3BSD, glibc, and dietlibc think foo was 2,
    uclibc would see 1 and 2 in the next reply, and Go sees 1 and 2 now.

Cheers, Ralph.

---

From: Ralph Corderoy <[email-masked]>
Date: Thu, 13 Aug 2015 13:22:19 +0100

Hi Mark,

> > http://tools.ietf.org/html/rfc1034#section-4.3.2 says
> > 
> >        If the data at the node is a CNAME, and QTYPE doesn't match
> >        CNAME, copy the CNAME RR into the answer section of the
> >        response, change QNAME to the canonical name in the CNAME RR,
> >        and go back to step 1.
> 
> Actually the order of the RRsets in the answer section is defined by
> that.  The order of the RRsets in the other sections isn't.

You're right, just the answer section.

> > but copying doesn't state an order, strictly, and 4.3.2 starts by
> > saying
> >
> >     The actual algorithm used by the name server will depend on the
> >     local OS and data structures used to store RRs.
> 
> Which allows you to use a hash table instead of a tree.  Or a hash
> table and a tree.
...
> The answers that are generated need to match those that would be
> generate by processing the data in the tree structure defined
> following the defined algorithm.

That was my reading too, but others can and are interpreting it
differently and there seems to be sufficient wriggle room to do so.

Cheers, Ralph.

---

From: Ralph Corderoy <[email-masked]>
Date: Thu, 13 Aug 2015 14:34:46 +0100

Hi Paul,

> >> "added" really does just mean "added" not "inserted".
> >
> > set and then ask for the contents of the set, the order you'll get
> > its contents is undefined.
> 

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.

> 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.

> 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.

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 13 Aug 2015 11:59:15 -0400

> implementation referred to the BSD behavior.

The glibc resolver ("libresolv" plus the "nss_dns" module) is a stripped
down fork of libbind.  It looks like it was first imported into the
glibc source tree in May 1993 from BIND 4.9.1 and synchronized
periodically with subsequent BIND releases.  The last merge was with
BIND 8.2.3-T5B in July 2000.

Compare

    https://github.com/freebsd/freebsd/blob/69d8a7bbb6/lib/libc/net/gethostbydns.c#L143

with

    https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/nss_dns/dns-host.c;h=357ac046932b4e991cd729363a97a3522313b7cc;hb=HEAD#l594

The BSD and glibc stub resolvers behave similarly because they're
substantially the same code.

-- 
Robert Edmonds

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Aug 2015 07:45:09 +1000

In message <[email-masked]>, Ralph Corderoy wri
> but it has helped allow different interpretations to spread over the

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>                                           |
               +---------------------------------------------------+

---

From: Ralph Corderoy <[email-masked]>
Date: Fri, 14 Aug 2015 15:38:01 +0100

Hi Mark,

> > 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.
>
> 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.

Isn't this old ground?  Yes, the RFC can be read with, to me, the
"obvious" interpretation that answers are appended.  But "add" is not
"append".  And it's nothing to do with OO, which I dislike.  Just
imprecise language that has allowed variation in implementations over
time.  I don't suppose the RFC would be written that imprecisely today
because their quality has improved in the light of experience of
(mis)interpretation.

> RFC 1034, 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A show a CNAME response

Yes, but it's not the only possible one from a wider, not ruled out,
interpretation that exists in practice.

I'm not arguing for a change in the vast majority of software, but a
clarification that will make their assumptions, given the add != append
interpretation, valid.  It will also give future implementations more
guidance, and allow bug reports to have something concrete to reference.

What's the downside?

Cheers, Ralph.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Aug 2015 22:28:09 -0400

On Fri, Aug 14, 2015 at 07:45:09AM +1000, Mark Andrews wrote:
> the records have been collected.

But as I already pointed out upthread, Mark, "add" does not mean "add
at the end".

That is, if I say "add 2 to 3", you can do "2+3" or "3+2".  They're
both equally right, and I don't see where in 1034 or 1035 there is
evidence to the contrary.

Your very invocation of an example from 1034 gives a nice illustration

> RFC 1034, 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A show a CNAME response
[…]

The very same section also has this example, but from another server:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
               |                           NS      A.ISI.EDU.      |
               |                           NS      VENERA.ISI.EDU. |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
               |                 172800    A       128.9.0.33      |
               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
               |                 172800    A       128.9.0.32      |
               | A.ISI.EDU.      172800    A       26.3.0.103      |
               +---------------------------------------------------+

Do you want to say that the data in the Authority section is ordered?
Presumably not.  You might argue there that the RRs there are part of
an RRset (though of course 1024 doesn't make that clear) and therefore
are necessarily unordered.  But what about the different RRsets in the
Additional section?  Why are they in that order?

IMO There is just an ambiguity in the RFCs, and I think it should be
fixed.  I understand that you think it's clear (and even why you do),
but I think your understanding stems from what you think is the
natural way to implement that specification.  If you had different
background or other things were more natual to you, you might come to
a different conclusion.  And if you think it's perfectly clear,
anyway, what is your possible objection to someone writing down the
clarification you don't need?  Especially when it's someone who hasn't
historically participated a lot here and who appears to be offering to
do free work?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Aug 2015 19:53:58 -0700

this is "selling past the close", an error we are all here oft guilty
of, but here i go anyway:

Andrew Sullivan wrote:
> fixed.

yes. fundamentally, rrset ordering within answer sections needs
clarification. noone disagrees.

>   I understand that you think it's clear (and even why you do),
> natural way to implement that specification.

i disagree. i do not think that you understand why mark and i both think
it's clear. all DNS implementations for the three years before RFC 882
was published until ten years after RFC 1034 was published worked this
way. even the ones written in LISP worked this way, and i think the data
structures and philosophy of LISP would have made set-like behaviour
very easy to do, if there was any reason to consider doing it that way.
there was no such reason, as i'll explain.

it's rare to quote from an obsolete RFC, but since it's highly
illuminative here, i will:

[RFC 883, Page 12, Query and response transport]

            Hence datagram messages are limited to 512 octets.  If a
            datagram message would exceed 512 octets, it is truncated
            and a truncation flag is set in its header.

[ibid, Page 27, Header section format]

      TC      - TrunCation - specifies that this message was truncated
                         due to length greater than 512 characters.
                         This bit is valid in datagram messages but not
                         in messages sent over virtual circuits.

[ibid, page 51, RESOLVER ALGORYTHMS]

            ...  The resolver may also find that a datagram reply was
      truncated, and open a virtual circuit so that the complete reply
      can be recovered.

none of these descriptions of truncation, nor indeed the truncation
descriptions in later RFCs, make any sense if "add" doesn't mean "to the
end of the response you are constructing". in order to impute ambiguity
about what "add" might have meant, these RFCs would have had to contain
text giving relative priorities for each possible datum in the message,
so that when truncation occurred there would be some idea of how to
construct the truncated message.

furthermore, the algorithms describing what to "add" are given in
section order. that is, everything you need to know when constructing
the authority section is present in the answer section, and everything
you need to know when constructing the additional section is present in
the answer and authority sections.

this doesn't matter. the document is unclear and requires clarification.
however, until that occurs, there is ample support in context for "add"
meaning "to the end". in fact, there's ample support in the existing
unclear document for "add" meaning "to the end of the message" rather
than "to the end of the section".

>                                              ... If you had different
> a different conclusion.

no. honestly, no background that included implementing DNS between 1980
and 1995 could lead to any different conclusion, and nor did it so lead.

>                     ... And if you think it's perfectly clear,
> clarification you don't need?

noone is objecting to clarifying it. the objection is to saying it's
ambiguous as written. it's absolutely unambiguous. it's also unclear.

>                                ... Especially when it's someone who hasn't

bring that on, by all means.

-- 
Paul Vixie