<div dir="ltr">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:<div><br></div><div><a href="https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf">https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 3:48 AM Mukund Sivaraman <<a href="mailto:muks@mukund.org">muks@mukund.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 19, 2020 at 10:39:37AM +0200, Petr Špaček wrote:<br>
> On 19. 06. 20 10:34, Mukund Sivaraman wrote:<br>
> > On Fri, Jun 19, 2020 at 10:10:43AM +0200, Petr Špaček wrote:<br>
> >> On 19. 06. 20 1:29, Mukund Sivaraman wrote:<br>
> >>> On Fri, Jun 19, 2020 at 04:55:52AM +0530, Mukund Sivaraman wrote:<br>
> >>>> On Thu, Jun 18, 2020 at 10:34:40PM +0000, Wessels, Duane wrote:<br>
> >>>>> My guess is that some implementations take the glue from the root zone<br>
> >>>>> and some take it from the <a href="http://root-servers.net" rel="noreferrer" target="_blank">root-servers.net</a> zone (which has the 3600000<br>
> >>>>> TTL).<br>
> >>>><br>
> >>>> You are probably right. If this is the case, then there is the question<br>
> >>>> of which is more correct for use as glue. Though the root servers also<br>
> >>>> serve the <a href="http://root-servers.net" rel="noreferrer" target="_blank">root-servers.net</a> zone and are authoritative for them, when<br>
> >>>> glue exists as glue within the root zone, should the root namesevers not<br>
> >>>> use the glue in preference?<br>
> >>>><br>
> >>>> Ignoring the case of . and <a href="http://root-servers.net" rel="noreferrer" target="_blank">root-servers.net</a>, assume a secondary<br>
> >>>> authoritative NS is configured for a parent zone and child zone a couple<br>
> >>>> of levels within the parent domain, which are transferred in from<br>
> >>>> different primary NSs (under control of different entities).  The<br>
> >>>> authoritiative NS does not know if the parent and/or slave are delegated<br>
> >>><br>
> >>> parent and/or *child zone* are delegated<br>
> >>><br>
> >>>> to it (as a resolver would) - it just serves zone data.  If one is to<br>
> >>>> assume that the parent zone is delegated to the NS, and the child zone<br>
> >>>> is delegated to some other nameserver (whereas a similarly named zone<br>
> >>>> exists on this NS), it seems more correct that glue that exists as glue<br>
> >>>> within the parent zone be used, and not address records from the child<br>
> >>>> zone (even though the NS thinks it is configured as an authority for the<br>
> >>>> child).<br>
> >><br>
> >> I would say it does not matter because glue and auth data are supposed<br>
> >> to be the same [<a href="https://tools.ietf.org/html/rfc1034#section-4.2.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc1034#section-4.2.2</a>] so<br>
> >> implementations should be free to chose either approach.<br>
> > <br>
> > It does matter, because the entity controlling the glue records in the<br>
> > parent zone and the entity controlling the auth data (which may not be<br>
> > the correct entity matching the delegation in the DNS) can be different.<br>
> > <br>
> > This is unlike the case for additional section entries added due to SRV<br>
> > in the answer, and CNAME chains, which can be constructed from multiple<br>
> > locally authoritative zones and even local cache. A resolver is free to<br>
> > discard such data as untrustworthy. Resolvers such as BIND do so and<br>
> > perform additional resolutions for the targets. But a resolver cannot<br>
> > discard glue.<br>
> > <br>
> >> Anyway this is probably material for dnsop WG.<br>
> > <br>
> > It was sent here because this was observed on the root servers. I'll<br>
> > follow up on dnsop.<br>
> <br>
> Okay, let's continue our diagreement there.<br>
<br>
You are right actually Petr. While preparing an example to demonstrate<br>
what I was thinking of, it turned out that this is the same situation as<br>
when a NS serves both the parent and child zones of a cut, and it<br>
doesn't matter. I don't know why I couldn't wrap my mind around it for<br>
so long.<br>
<br>
                Mukund<br>
_______________________________________________<br>
rssac-caucus mailing list<br>
<a href="mailto:rssac-caucus@icann.org" target="_blank">rssac-caucus@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/rssac-caucus" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/rssac-caucus</a><br>
<br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). 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.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Wes Hardaker<div>USC/ISI</div></div></div>