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