[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency

[Peter Thomassen <[e-mail]>]

Hi Joe,

On 6/24/25 14:03, Joe Abley wrote:
>>> …the Parental Agent, knowing both the Child zone name and its NS hostnames, MUST ascertain that queries are made against all (reachable) nameservers listed in the Child's delegation from the Parent…
>>
>> You cannot send queries to hostnames, you have to query an IP address. So you have to somehow convert each NS hostname into a set of IP addresses.
> 
> I am also unsure about this, because it feels like it's not a very DNS way of doing things. (I have mentioned this to Peter before, I think, but I can't currently remember whether it was on this list or somewhere else).

Indeed, as you mentioned elsewhere, it was in this thread! :-) It's indeed an underspecified point; apologies that it somehow slipped.

I hope we have good resolution for this now, based on Oli's input (see my response to Ondřej).

> Usually we accept any response from any authoritative nameserver as authoritative and don't poll all possible authoritative nameservers. We understand that there might be reasons why the responses are different, because we know that the DNS is only loosely-coherent for various reasons.

That's correct. This practice assumes though that the delegation is set up cleanly (e.g., no rogue nameserver). Only because of that assumption is it safe to accept any nameserver's response. (And if you wanted, you could cross-check.)

As we're changing delegation information, automatically even, it is possible for one nameserver to quickly change whether the others can participate, by removing them from the NS RRset (including on the parent side via CSYNC), or by removing their DS records (via CDS/CDNSKEY). When that happens, it no longer easily possible to cross-check, even if you wanted.

What the parent-side processing really should do, therefore, is not to ask a random server and act on it. Instead, when delegation information is affected, it's important to ensure that the change is *really* what the zone owner wants -- in which case it should not be a problem for them to get it published on all auths.

If I had a multi-provider setup with two signers, I wouldn't want to have to trust one of them to not kick the other, intentionally or by accident.

Put differently: a single DNS operator in a multi-provider setup probably should not have the same authorizations as the registrant w.r.t. to delegation management.

> The parenthetical "reachable" also makes me wonder a bit. If it's ok not to consult some nameservers because they are not reachable from a particular vantage point, is not also ok to ignore them at other times?

My view is that this is a plausibility check: You use all the information you can reasonably easily obtain, and when it looks consistent, you proceed. If a nameserver is unreachable, it's sensible to not "wait" for it; however, if it's reachable, why not consider it?

Best,
Peter