Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

From: Jan Včelák <[email-masked]>
Date: Wed, 1 Jul 2020 11:41:49 +0200

> Abstract:
>    The DNS uses glue records to allow iterative clients to find the
>    addresses of nameservers that live within the delegated zone.  Glue
>    records are expected to be returned as part of a referral and if they
>    cannot be fitted into the UDP response, TC=1 MUST be set to inform
>    the client that the response is incomplete and that TCP SHOULD be
>    used to retrieve the full response.

Mark, thank you for writing the draft. I agree this document is needed.

It would be great if we resolved the discussion whether all existing
glue records are required or whether some number of glue records is
sufficient. I think it needs to be codified in the document.

I tend to agree with the second camp. The motivation is clear, the
resolvers need to be able to follow the delegation. However, with a
large number of NS records, I don't want to force the resolver to
retry if it already has enough information to follow the delegation.
It has been also demonstrated that resolvers are pretty bad at picking
the server with the best RTT if there are too many servers. The other
motivation is just that large responses are possible reflection attack
vectors so the DNS server operators may want to limit the number of
glue records returned.

We just opened this discussion internally at NS1 because we serve some
zones with more than 10 NS records where each NS requires glue and our
proprietary server by design adds glue only for the first four NS
records. We are discussing if this is correct behavior if it needs to
be revisited.

I also think there is another proprietary implementation of an
authoritative server in the wild which implements similar policy. It
picks a small random subset of the NS records and adds A/AAAA just for
these names. If the QNAME matches a name in the NS, A/AAAA for that NS
is always included. I find this pretty smart.

Kind regards,
Jan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 19:20:34 +0000

On Wednesday, 1 July 2020 09:41:49 UTC Jan Včelák wrote:
> ...

i think if you're using round robin or random selection, a subset is fine. if 
we had to codify this practice, i'd ask that at least two address records of 
each available kind be included (so, two AAAA's, two A's) or else set TC=1.

> is always included. I find this pretty smart.

RRsets shall not be divided. either send all the NS records, or none (TC=1).

-- 
Paul

---

From: Jan Včelák <[email-masked]>
Date: Wed, 1 Jul 2020 22:03:43 +0200

> RRsets shall not be divided. either send all the NS records, or none (TC=1).

Of course. The NS is always included in full. I meant that glue is
added only for a subset of these NS records.

I apologize for confusion.

--
Jan

---

From: "John Levine" <[email-masked]>
Date: 1 Jul 2020 21:18:16 -0400

>each available kind be included (so, two AAAA's, two A's) or else set TC=1.

I really don't like this. If you do that, you're going to have
failures when there are working servers but none of their addresses
happen to be in the glue subset in the response, and without TC=1
there's no hint that there's more glue if you retry.

If a response with TC=1 has at least one record in the additional
section, that tells the client that the missing records are all glue.
So I think it would be OK in that case for the client to use what it's
got, but remember that if it can't contact any of the NS with the
A/AAAA it's got, it can go back and get the rest.

Remember, if it's glue, there's no other way to get it. If it's worth
returning glue at all, it's worth providing all of it.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 2 Jul 2020 11:33:12 +1000

> On 2 Jul 2020, at 11:18, John Levine <[email-masked]> wrote:
> 

BIND sets TC=1 if a query for the address of a nameserver came in and
that was the only way to return the addresses after sorting to the start
of the additional section is to go to TCP.  This was done to reduce
fallback to TCP otherwise referrals to NET from the root servers would always
require TCP for non-EDNS clients.  That said it is much cleaner to just return
all the available glue.

Recursive servers need to be able to cope with glue expiring before referral
NS record.  The question is how complicated should that dance be.  BIND will
ask the parent for the addresses of every NS but it requires a lot of traffic.

Someone earlier asked about sibling vs required glue.  I would set TC=1 for
both.

Mark

> R's,
> John
> 
> _______________________________________________
> 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: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2020 07:47:36 +0000

On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote:
> >i think if you're using round robin or random selection, a subset is fine.
> >if we had to codify this practice, i'd ask that at least two address
> >records of each available kind be included (so, two AAAA's, two A's) or
> >else set TC=1.

> there's no hint that there's more glue if you retry.

this is the draft where that issue would be decided, so it's good we're 
talking about it. there are subtleties to the proposal you quoted, such that:

1. it is not possible to fetch the glue directly from the server who sent you 
the silently truncated delegation, all you can get is another referral.

2. you'll get a different subset of the available glue each time you retry, 
due to random ordering or round-robin.

3. even without TC=1 you will know there's under-zonecut glue you didn't 
receive, because you saw the NS RR, and the only path to the address RR is 
through that NS RRset.

any full resolver who doesn't like the conditions detected in #3 above is free 
to either retry as in #2 above, or just fetch with TCP, since the silent 
truncation is unambiguously implied.

> section, that tells the client that the missing records are all glue.

true to form, BIND4/8 did that, and no harm came of it, but it's difficult to 
standardize, and is not an optimization, it's a definite signal pattern meant 
to convey meaning. while 1035 does describe response construction order, that 
would have to be reiterated in case some responder has been adding things 
column wise rather than row wise, and has never had a complaint from it until 
the day somebody starts to depend on actual 1035 RRset stuffing order. this 
feels like pushing on a rope, but i know we have to do that sometimes.

> A/AAAA it's got, it can go back and get the rest.

...with TCP, i hope you meant.

> returning glue at all, it's worth providing all of it.

until someone invents faster than light travel, round trips and remote state 
will be the second and third most expensive things on the internet. (the most 
expensive thing is complexity.) i think we can usefully discuss whether to set 
TC=1 if the only thing that won't fit is glue, but some glue did fit. but our 
goal should be to allow smart initiators to avoid retrying with TCP out of 
reflex. my recommendation of TC=0 is to suppress reflexive TCP retries.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2020 07:52:58 +0000

On Thursday, 2 July 2020 07:47:36 UTC Paul Vixie wrote:
> talking about it. ...

by the way, this is what kato and i, and later jabley, were trying to get at 
with

https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/

but it was like moving mud with a toothpick, so after eleven years (2003 to 
2014) we gave it up. there are probably some good ideas in there, even now.

-- 
Paul

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2020 10:50:24 -0400

> reflex. my recommendation of TC=0 is to suppress reflexive TCP retries.

I wouldn't disagree but it seems to me once again it's a tradeoff between 
performance and correctness.  I'd prefer correctness, particularly since 
it seems that the option to use what's in a truncated referral gets you 
both.

> receive, because you saw the NS RR, and the only path to the address RR is

Well, maybe.  Even if you got one A record there might be others.  Or if 
you got an AAAA record but no A record and you're on an IPv4 network, you 
can't tell whether there's a lurking A record or not, or vice-versa. 
(See the glue for j.zdnscloud.com in the root.)

If we do it your way, if any NS is in-zone and the lookups fail, you 
*always* need to do a TCP query just to see if if the UDP response left 
something out.

R's,
John

PS: I'm less worried about round-robin DNS, since then it's clearly a
deliberate decision by the parent to leave some of the answers out.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2020 15:29:01 +0000

On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote:
> > ... but our goal should be to allow smart initiators to avoid
> > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress
> > reflexive TCP retries.

TC=1 will, on several DNS initiators whose architecture i know, automatically 
trigger TCP fallback, without regard to what's in the various sections. that 
is often a layering constraint in the software, where "get the response" has 
the fallback logic, and "look at the response" comes after that's completed.

> Well, maybe.  Even if you got one A record there might be others. 

no. truncation is on RRset boundaries. even in a truncated response, RRsets 
are never broken up. if you have any A records for a name, you have them all.

> Or if

that's why my proposal was to only avoid setting TC=1 if some minimal amount 
of glue does fit, specifically two RRsets of each address type (AAAA and A).

> *always* need to do a TCP query just to see if if the UDP response left

in the statement, "if in-zone and failures then TCP" does not warrant the use 
of the word "always" which is either redundant (that's what if/then means) or 
misleading (failures aren't the norm). i am ok with having to use TCP when not 
all glue fits, and the part that does fit, refers to currently-unreachable 
servers. a zone for whom two of its servers, on all of their address types, 
are down is going to see serious slowdown due to timeouts. so, already a bad 
day well worth avoiding. getting additional TCP fallback is additive not 
multiplicative to the badness costs in that non-normal situation.

> deliberate decision by the parent to leave some of the answers out.

here, round-robin is an access method used for populating a section, and in 
this case the section is additional-data not answer. so, round-robin and 
random-robin should behave similarly in the truncation path we're discussing, 
where i'm saying the truncation would be better off silent (TC=0).

-- 
Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 2 Jul 2020 21:18:41 +0530

> are never broken up. if you have any A records for a name, you have them all.

IIRC truncation on RRset boundaries is not defined. This is usually why
initiators abandon the whole message when TC=1.

E.g., from RFC 1035 section 7.4:

> When a response is truncated, and a resolver doesn't know whether it
> has a complete set, it should not cache a possibly partial set of RRs.

implying that it may not be a complete set, and RFC 2181 section 9:

>   Where TC is set, the partial RRSet that would not completely fit may
>   be left in the response.  When a DNS client receives a reply with TC
>   set, it should ignore that response, and query again, using a
>   mechanism, such as a TCP connection, that will permit larger replies.

		Mukund

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jul 2020 16:14:30 +0000

The interpretation of whether a partial RRset is allowed by 1035/2181 made by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035 and RFC 2181 are unclear about whether an RRset that is required in a reply can be partial.

draft-ietf-dnsop-glue-is-not-optional as it stands is probably not the best place to update the understanding of the standards-level relationship between partial RRsets, the TC bit, and what parts of a response are required. Doing so is adventurous, time-consuming, and will almost certainly cause multiple current implementations to be out of compliance.

It is probably still worth doing, albeit carefully. A bad outcome would be finishing the document due to exhaustion instead of consensus.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Thu, 2 Jul 2020 10:16:48 -0700

On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman <[email-masked]> wrote:

> The interpretation of whether a partial RRset is allowed by 1035/2181 made
> by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035
> and RFC 2181 are unclear about whether an RRset that is required in a reply
> can be partial.
>
> draft-ietf-dnsop-glue-is-not-optional as it stands is probably not the
> best place to update the understanding of the standards-level relationship
> between partial RRsets, the TC bit, and what parts of a response are
> required. Doing so is adventurous, time-consuming, and will almost
> certainly cause multiple current implementations to be out of compliance.
>
> It is probably still worth doing, albeit carefully. A bad outcome would be
> finishing the document due to exhaustion instead of consensus.
>

I agree with Paul H in this regard.

Here's how I see it: the update to 1035 is necessary, but not sufficient
(probably).

Note that 1035 itself predates EDNS, so advice on TC alone is good, but for
the population of DNS implementations doing EDNS, perhaps we could take
advantage of its existence?

There are a whole bunch of unused bits in the core element of the OPT RR
(the place where the DO bit exists). That would be an excellent (IMHO)
place to signal the situation here (partial glue truncation).

Such a bit would hopefully disambiguate the cases where TC=1 is set,
allowing for graceful handling (try to use the available glue, prepare for
the failure case and retry over TCP if it does fail).

Thoughts?

Brian

---

From: Shane Kerr <[email-masked]>
Date: Fri, 3 Jul 2020 10:17:27 +0200

Brian,

Thanks for the interesting idea. Apologies for the rambling response below.

On 02/07/2020 19.16, Brian Dickson wrote:
> 
> 
> On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     The interpretation of whether a partial RRset is allowed by
>     1035/2181 made by JohnL, PaulV, and MukundS are all plausible and
>     conflicting. RFC 1035 and RFC 2181 are unclear about whether an
>     RRset that is required in a reply can be partial.
> 
>     draft-ietf-dnsop-glue-is-not-optional as it stands is probably not
>     the best place to update the understanding of the standards-level
>     relationship between partial RRsets, the TC bit, and what parts of a
>     response are required. Doing so is adventurous, time-consuming, and
>     will almost certainly cause multiple current implementations to be
>     out of compliance.
> 
>     It is probably still worth doing, albeit carefully. A bad outcome
>     would be finishing the document due to exhaustion instead of consensus.
> 
> 
> Note that 1035 itself predates EDNS, so advice on TC alone is good, but 
> for the population of DNS implementations doing EDNS, perhaps we could 
> take advantage of its existence?
> 
> allowing for graceful handling (try to use the available glue, prepare 
> for the failure case and retry over TCP if it does fail).
> 
> Thoughts?

I guess a resolver can infer that it has a full set of glue if there are 
A and AAAA records for every NS, otherwise the glue _might_ be 
truncated. This is kind of suckful because many servers (most?) don't 
have IPv6, and some (I run a few, .biz used to have one) don't have IPv4.

Anyway the basic approach of a resolver would be:

1. If I get back a response that has what appears to be a full set of 
glue (A and AAAA for every in-bailiwick NS) then I don't have to worry 
about missing glue.

2. If I get back a response that might be missing glue and there is an 
EDNS option "I support glue TC" that is not set, then I don't have to 
worry about missing glue.

3. If I get back a response that might be missing glue and there is an 
EDNS option "I support glue TC" that is set, then:
3.a. I can optionally try the servers that are in the glue that I did 
get first.
3.b. At some point I can try to get more glue using TCP.

4. If I get back a response that might be missing glue and there is no 
"I support glue TC" EDNS option, then you are basically in the same 
place as #3, except you might be wasting that TCP re-try because it 
might not return additional glue.

Because it is so hard for a server to know if there is actually glue 
missing, I think there _might_ be benefit. It could _potentially_ save a 
lot of wasted queries, mostly looking for non-existent AAAA records.

OTOH since this is about an EDNS option, it seems simpler to just 
realize that you've got at least 1280 bytes in the reply and that it 
will mostly not need truncation. It takes a lot of NS/A/AAAA records to 
fill up even a 1280 byte response (the root servers have 13 NS with A & 
AAAA for each, and is between 811 and 1103 bytes, depending on who you 
ask and which of their servers instances you get at any given time):

a -> 811
b -> 839
c -> 839
d -> 811
e -> 811
f -> 839
g -> 839
h -> 811
i -> 851
j -> 811
k -> 823
l -> 1003
m -> 811

I suppose it is possible that someone uses something like:

foo.example NS really-long-name.foo.example
             NS different-but-still-long.foo.example
             NS filling-up-dat-packet-tho.foo.example
                  .
                  .
                  .

And exceeds the space for glue.

Or maybe dnscurve:

bar.example NS 
uz5bcx1nh80x1r17q653jf3guywz7cmyh5jv0qjz0unm56lq7rpj8l.bar.example
             NS 
kxmvjtvks4rr576myswk7c6hdyedarthudoorz673crgktq5n6nmaq.bar.example
             NS 
tn2krco3pfhogkgwgswvrvp6dkuawmezyplgnu4f7wlajqv2gppp5t.bar.example
                  .
                  .
                  .

Even in those cases you need a lot of NS though.

Anyway, I guess this is basically all to convince myself that:

1. We probably don't need an EDNS option to signal just glue truncation
2. We should probably set TC when we do truncate glue

Cheers,

--
Shane

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 3 Jul 2020 18:33:59 +0900

Paul Hoffman wrote:

> RFC 1035 and RFC 2181 are unclear about whether an RRset that is
> required in a reply can be partial.

1035 is clear:

    - When several RRs of the same type are available for a
      particular owner name, the resolver should either cache them
      all or none at all.  When a response is truncated, and a
      resolver doesn't know whether it has a complete set, it should
      not cache a possibly partial set of RRs.

						Masataka Ohta

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2020 13:59:42 -0400

>the failure case and retry over TCP if it does fail).

I think it would be easier to clarify the existing rules and encourage
people to follow them rather than inventing new flags that are
unlikely ever to be implemented.

For the particular case of partial glue on referrals, so long as the
packet has all of the answer records, it's never wrong to go ahead and
use the glue it's got. What would a flag do?

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Jul 2020 13:39:24 -0700

On Fri, Jul 3, 2020 at 10:59 AM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:

It makes clear the difference between implied and inferred.
The flag clearly indicates that some glue which would otherwise be
considered necessary has not been sent.
It simplifies the implementation on the receiver's side: no flag, all glue
was sent; flag, some glue is missing.
The recipient never has to determine whether there should be glue or not,
including whether the sender is a busted implementation or zone.
The recipient has a clear path of action, if it is unable to contact any of
the name servers from the referral due to missing glue: ask again (over
TCP).

Additionally, the flag would signal compliance with updated 1035, for
starters. The uptake on the clarified 1035 won't be instantaneous or
universal, so it makes it possible to correctly infer whether a server is
doing things the new way or not.
Also, it would facilitate lower effort in figuring out if a TC is referral
related or not, which could be important for implementers/operators doing
large scale stuff.
And lastly, it would strongly encourage anyone not currently doing the
partial glue usage thing, to do so.

Most importantly, this is all about interoperability, including not just
the wire format but the operational signaling.
Not everyone will implement things the same way, but at least they will
have a signal about how the other party is doing what they are doing.

Brian

---

From: "John R Levine" <[email-masked]>
Date: 3 Jul 2020 18:04:00 -0400

> considered necessary has not been sent.

That sounds a lot like the TC flag.  I realize that some people have 
interpreted the TC flag to mean something else, but I think its actual 
meaning is pretty clear.

> starters.

This would in effect be a version number.  Our experience with version 
numbers in old protocols has not been great.

> related or not, which could be important for implementers/operators doing

I don't understand this.  Caches surely already know when a response is a 
referral.  If a referral response has TC set, in what way could that not 
be referral related?

> the wire format but the operational signaling.

Turning on bits that have been zero for 35 years doesn't have a great 
history of interop, either.  Look at the history of queries with EDNS0 
never getting a response.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Jul 2020 17:55:16 -0700

> interpreted the TC flag to mean something else, but I think its actual

Uh, no. The TC flag means "something didn't fit".
It is not restricted to glue, which is only in the additional section.
TC can also be set if something from the authority section didn't fit, or
if something didn't fit in the answer section.
(Obviously it would be the first section where something didn't fit that
matters.)

I'm suggesting this new "flag" (possibly an OPT TLV rather than actual flag
bit) only be used if TC is set for referral-not-optional glue.

This is a very distinct subset of ways that TC can be set.

> referral.  If a referral response has TC set, in what way could that not

See the words "large scale".
At large scale, the amount of work per referral matters a great deal.
(There are lots and lots of domains, and lots of places other than TLD->2LD
where referrals can and do occur.)

Just because a cache can figure out if a response is a referral, doesn't
mean doing so is currently trivial.
(Especially with all of the oddball implementations out there, plus older
versions of not-quite-oddball implementations.)

Having an easy way to identify a significant subset (the opposite of the
long tail) which make it easy to figure this out, seems like a win.

> never getting a response.

Good point.

s/EDNS bit/EDNS OPT TLV/, and it should be good.

Or am I missing something else there?

Brian

---

From: "John R Levine" <[email-masked]>
Date: 3 Jul 2020 21:19:48 -0400

> (Obviously it would be the first section where something didn't fit that

Well there's a question.  Is there any DNS software that will keeps adding 
new sections to a truncated answer, e.g., a partial authority section but 
it has some additional records anyway.  Seems unlikely but I honestly 
don't know.

In any event this whols plan still seems way overcomplicated.  In my 
simple world, you can tell that an answer is a referral because it has an 
empty answer section and an non-empty authority section.  A useful 
referral has some NS records in the authority section.

Let's see what other people think.

Regards,

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 4 Jul 2020 07:13:51 +0530

On Fri, Jul 03, 2020 at 09:19:48PM -0400, John R Levine wrote:
> new sections to a truncated answer, e.g., a partial authority section but it
> has some additional records anyway.  Seems unlikely but I honestly don't
> know.

Pedantically, yes. OPT and TSIG RRs are added by some implementations
when TC=1, and they may delete answer and authority sections (fully or
in part) if necessary to make room for OPT and TSIG.

> In any event this whols plan still seems way overcomplicated.  In my simple
> world, you can tell that an answer is a referral because it has an empty
> answer section and an non-empty authority section.  A useful referral has some
> NS records in the authority section.

The DNS protocol seems to have jumped the shark. It's becoming more and
more of a rat's nest.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Jul 2020 22:58:39 +0000

-- 
Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Jul 2020 02:11:22 +0000

> are never broken up. if you have any A records for a name, you have them all.

This draft only quotes from RFC 1034, an RFC in which the word "truncation" does not appear. In fact, the word "fit" doesn't appear in this sense either.

RFCs 1035 and 2181 give mixed messages about incomplete RRsets. That is, it is easy to quote one part and say "see, this proves what I said" for different values of "what I said".

As I said earlier in this thread, this seems like to be the wrong draft in which to fix the vagueness about full RRsets.

--Paul Hoffman

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 07 Jul 2020 18:57:57 +0200 (CEST)

>> this is the draft where that issue would be decided, so it's
>> good we're talking about it. ...
>
> by the way, this is what kato and i, and later jabley, were
> trying to get at with
>
> but it was like moving mud with a toothpick, so after eleven
> years (2003 to 2014) we gave it up. there are probably some
> good ideas in there, even now.

I've read it, and most of it makes perfect sense to me (I think I
have one paragraph I'd like to discuss).

When you say it was like "moving mud with a toothpick", was there
any active opposition to the draft, or was it just a lack of
engagement?

Regards,

- Håvard

---

From: Joe Abley <[email-masked]>
Date: Tue, 7 Jul 2020 12:01:35 -0500

> any active opposition to the draft, or was it just a lack of

I think there was a general lack of interest. I still think this is a
good document and would be happy to continue working on it if the
pendulum has swung the other way.

Joe

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 07 Jul 2020 19:08:15 +0200 (CEST)

>> have one paragraph I'd like to discuss).

BTW, the paragraph I found hard to decipher is this one:

   Anycast [RFC3258] [RFC4786] is a useful technique for improving
   performance and below the zone cut being described by a delegation is
   responses.

It looks like there is some missing text?

Regards,

- Håvard

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Jul 2020 05:32:15 +0900

Paul Hoffman wrote:

> RFCs 1035 and 2181 give mixed messages about incomplete RRsets.

They don't.

You should misunderstand 2181. Putting glue is not additional
section processing.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Tue, 7 Jul 2020 15:03:13 -0700

> pendulum has swung the other way.

+1.

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2020 21:23:51 -0400

>You should misunderstand 2181. Putting glue is not additional

Uh, what?

   Searching for either NS or MX records causes "additional section
   processing" in which address records associated with the value of the
   record sought are appended to the answer.  This helps avoid needless
   extra queries that are easily anticipated when the first was made.

(RFC 2181, page 13]

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 8 Jul 2020 11:59:18 +1000

> On 8 Jul 2020, at 11:23, John Levine <[email-masked]> wrote:
> 

See RFC 1034, Section 4.3.2. Algorithm.

Glue is added at step 3b.

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

Additional section processing (for everything other than NS) happens
at step 6 which is what was being referred to.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Jul 2020 17:44:13 +0900

> See RFC 1034, Section 4.3.2. Algorithm.

More explicit explanation on difference is in 1035:

    NS records cause both the usual additional section processing to locate
    a type A record, and, when used in a referral, a special search of the
    zone in which they reside for glue information.

						Masataka Ohta

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2020 22:22:25 -0400

>2014) we gave it up. there are probably some good ideas in there, even now.

Perhaps the mud has dried out enough to make progress now.

I agree it's a reasonable draft that says useful stuff. With minimal
polishing we should be able to publish it.