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

[Petr Špaček]

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.

-- 
Petr Špaček  @  CZ.NIC