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

[Wes Hardaker]

FYI, we recently wrote a paper about measuring whether clients
preferred parent glue or child glue (and other things).  Here's a link to a
copy of it if anyone is interested in it:

https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf

On Fri, Jun 19, 2020 at 3:48 AM Mukund Sivaraman <muks at mukund.org> wrote:

> On Fri, Jun 19, 2020 at 10:39:37AM +0200, Petr Špaček wrote:
> > On 19. 06. 20 10:34, Mukund Sivaraman wrote:
> > > 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.
> >
> > Okay, let's continue our diagreement there.
>
> You are right actually Petr. While preparing an example to demonstrate
> what I was thinking of, it turned out that this is the same situation as
> when a NS serves both the parent and child zones of a cut, and it
> doesn't matter. I don't know why I couldn't wrap my mind around it for
> so long.
>
>                 Mukund
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.



-- 
Wes Hardaker
USC/ISI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200619/93148bdf/attachment.html>