On 9 Nov 2023, at 11:13, John R Levine <jo...@taugh.com> wrote: > On Wed, 8 Nov 2023, Brian Dickson wrote: >> The target for a NOTIFY would necessarily be found in the SOA record of the >> registrant's zone, not the parent's zone. I think that's where the >> confusion has arisen. > > There's definitely confusion here but I don't think it's mine.
I am always very happy to confirm I am confused :-) > The child (registrant) puts a CDS record in its zone, and then it wants the > parent (registry and/or registrar) to look at it and update the DS in the > parent (typically TLD zone) so it needs to notify the parent to tell it to > take a look. The child's SOA lists the child's own primary NS, not the > parent's, so notifying itself won't help. (The child's SOA.MNAME can list whatever makes sense for the child. It doesn't need to be an authoritative nameserver. Unless the child accepts UPDATE messages there's no actual general consumer for that data.) > Apropos Joe's message, the child could hypothetically try and send the > NOTIFTY to the parent SOA, e.g. a.gtld-servers.net for .com or .net. But > those are clouds of anycast servers and even if you can get that to work, > they belong to the registry while the notify needs go go to the registrar so > it can update the registry via EPP. I don't agree that it's impossible to use an anycast target for this, any more than it's impossible to distribute any service using anycast. Using the parent's SOA.MNAME also seems like an option. That might also be an anycast target. That also seems fine. > One might wave one's hands frantically and imagine there is some way to do > reverse anycast plus magic forwarding to the registrar, but I am not going to > go there. I don't know what you mean by "reverse anycast". A service that receives NOTIFY messages is not fundamentally different from a service that receives queries as far as the interaction with its clients goes or the options available for deploying it. As far as communication with registrars goes, the registry operator is actually ideally placed to relay general messages to registrars. I'm not sure why this is being discounted. They already do so for other purposes. >> BTW, this use of registrant's zone's SOA.MNAME supports both the non-hidden >> master/signer, and the hidden master/signer use cases, AFAICT. > > This makes no sense at all. Beyond the fact that it's the wrong SOA, the > point of a hidden primary is that it's hidden. Putting it in an SOA would > spill the beans. It's not very hidden if you want third parties to send messages to it. > ICANN's CZDS distributes copies of TLD zone files which they fetch via daily > AXFR from stealth zone primaries. For a while, they were just dumping the > AXFR output into the files including a comment that had the address of the > primary. They were very embarassed when I told them I knew where all the > stealth primaries were because they told me, and they promptly edited the > comments out. People care that stealth is stealthy. I'm not sure why anybody should think anything is hidden in there v4 internet when you can scan the whole number space from many vantage points in a matter of minutes, and people do. Aside from that, I think the concept of a "hidden primary" is borderline archaic at this point. Let's talk about a service that accepts messages of a particular type and imagine ways that it can be reliably located; let's not encumber the discussion with historical artefacts. Anyway, I don't feel more confused than usual, for the record :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
