[RSSAC Caucus] Curious difference in glue TTL for root servers

[Mukund Sivaraman]

On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:
> On 19. 06. 20 1:29, Mukund Sivaraman wrote:
> > On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:
> >> On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:
> >>> My guess is that some implementations take the glue from the root zone
> >>> and some take it from the root-servers.net zone (which has the 3600000
> >>> TTL).
> >>
> >> You are probably right. If this is the case, then there is the question
> >> of which is more correct for use as glue. Though the root servers also
> >> serve the root-servers.net zone and are authoritative for them, when
> >> glue exists as glue within the root zone, should the root namesevers not
> >> use the glue in preference?
> >>
> >> Ignoring the case of . and root-servers.net, assume a secondary
> >> authoritative NS is configured for a parent zone and child zone a couple
> >> of levels within the parent domain, which are transferred in from
> >> different primary NSs (under control of different entities).  The
> >> authoritiative NS does not know if the parent and/or slave are delegated
> > 
> > parent and/or *child zone* are delegated
> > 
> >> to it (as a resolver would) - it just serves zone data.  If one is to
> >> assume that the parent zone is delegated to the NS, and the child zone
> >> is delegated to some other nameserver (whereas a similarly named zone
> >> exists on this NS), it seems more correct that glue that exists as glue
> >> within the parent zone be used, and not address records from the child
> >> zone (even though the NS thinks it is configured as an authority for the
> >> child).
> 
> I would say it does not matter because glue and auth data are supposed
> to be the same [https://tools.ietf.org/html/rfc1034#section-4.2.2] so
> implementations should be free to chose either approach.

It does matter, because the entity controlling the glue records in the
parent zone and the entity controlling the auth data (which may not be
the correct entity matching the delegation in the DNS) can be different.

This is unlike the case for additional section entries added due to SRV
in the answer, and CNAME chains, which can be constructed from multiple
locally authoritative zones and even local cache. A resolver is free to
discard such data as untrustworthy. Resolvers such as BIND do so and
perform additional resolutions for the targets. But a resolver cannot
discard glue.

> Anyway this is probably material for dnsop WG.

It was sent here because this was observed on the root servers. I'll
follow up on dnsop.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200619/5efa34de/signature.asc>