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