On Tue, Feb 21, 2023 at 5:50 AM Ralf Weber <d...@fl1ger.de> wrote:
>
> These “rare” cases where the domain is not resolvable when a glue is not
> present are the ones this draft is done for. So did you look how rare
> they were in your dataset? Being able to resolve instead of not resolving
> IMHO has value even if the number is not big.
>
> We all know that a lot of data in the DNS is garbage, that should not
> stop us from using the good data.
>
> So long
> -Ralf
>
The cyclic dependency based sibling glue (Section 2.3) is arguably
a bit of a corner case, and in past discussions some folks have expressed
the view that we shouldn't make accommodations to support it. I
think I can agree with that, but there were opposing views that we also
shouldn't break configurations that currently work. So it was left in.
The case of normal (non-circular) sibling glue, described in Section
2.2 is in my opinion useful though, and also extremely common - where
it isn't necessarily required for resolution but allows resolvers to obviate
additional follow-on queries (to the same servers) to obtain the sibling
glue.
Previous lengthy discussions on this topic indicate a consensus to
retain them, but not mandate their inclusion (or set TC=1 if message
size limits are exceeded).
Note that this document does not place any requirements on DNS
resolvers, so if a resolver implementer chooses to, they can ignore
sibling glue in referral responses, and/or explicitly fetch them.
As far as bad data, I agree with Ralph. It shouldn't prevent us from
being able to use the good data. My employer has tons of domains that
use (working) sibling glue.
There was extensive discussion previously about incorrect glue,
and other types of issues ("orphaned glue"), and what could be
said to get registries/registrants to cleanup referral data in
zones. But we were strongly advised by folks deeply familiar with
TLD operations to not try to tackle that can of worms here. The
draft does make the following suggestion though: "The IETF may
want to consider a separate update to the requirements for including
glue in zone data, beyond those given in [RFC1034] and [RFC1035]."
Shumon.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
