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

[Paul Vixie <[e-mail]>]

On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote:
> In article <9056955.dJ39pTEj9z@linux-9daj> you write:
> >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.

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

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.

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

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.

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

...with TCP, i hope you meant.

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

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