> On 9 Nov 2023, at 13:17, John R Levine <jo...@taugh.com> wrote: > > On Thu, 9 Nov 2023, Joe Abley wrote: >>> If we can get the registrars and registries to go for it, registry >>> forwarding is fine with me, but I don't think it would be a good idea to >>> specify it unless we are confident that people are willing to do it. >> >> To be honest I have my doubts that any of this is worth doing at all; I >> think it would be far better to forget about DNS-centric approaches and put >> effort instead into broadening the provisioning channels around domain >> registrations and management to incorporate DNS operators. If I'm right and >> none of this is going anywhere anyway, then we might as well be expansive in >> our design :-) > > I have a lot of sympathy for that position. It's come up in the Other Place > too.
Much as it may surprise people I also have sympathy for that position. However, the catch with that argument seems to be that it aims at the part of the namespace where there is a provisioning channel to widen. Eg. the part of the universe where there is a registrar and an EPP channel. Incidentally that’s exactly the part of the universe that I am not focusing on for the UPDATE-based document (which is one of the consumers of this target location mechanism). But, as the saying goes, “perfect is the enemy of timely”. What we have here are two essentially trivial mechanisms that can improve, in some cases vastly improve, things that are in use today. So, while waiting for "perfect" I advocate not dismissing simple things that are “timely” if they are considered to be useful. My view is that for either the NOTIFY or the UPDATE mechanism to be workable it has to be “simple”. And “simple” means something that doesn’t require changes in the child end for potentially very large numbers of child zones. Any configuration has to be in the parent end only. That rules out any kind of manual configuration of NOTIFY targets, etc. On the issue of “reverse anycast” my view is that it isn’t a protocol issue (UPDATE forwarding works, NOTIFY forwarding can be made to work). Rather it is a question of how the DNS industry works. I used to be responsible for a rather large anycast network and I will say that supporting UPDATE (or NOTIFY) forwarding through that infrastructure back to the individual customers is not a service that would come for free. So any argument that it would be better to be dependent on such forwarding than to add one or two records in the parent that specify where the target is so that the child can send it to the right place from the start is simply trying to ignore market reality. And then we get to SOA.MNAME. The SOA.MNAME is just one target. And no port number. So there is no way of separating things like the CDS scanner, the CSYNC scanner and the potential DNS UPDATE receiver. Those things are not the same and a design that assumes that they are and that they all must listen on port 53 at the same address is not a realistic alternative IMHO. Another problem with the SOA.MNAME alternative is that the EXISTENCE of the record indicating the target of the NOTIFY/UPDATE/etc is the signal that such a service exists, so acts as an “OPT IN” safeguard. Therefore any parent that doesn’t support generalised NOTIFY or UPDATE or... will be fine by just not publishing that information. SOA.MNAME on the other hand is not something we can turn on or off. Same thing goes for the suggestion of just sending NOTIFY / UPDATE to all secondaries listed in the NS RRset of the parent. Again, a non-starter. To keep this simple but still sufficiently flexible, my view is still that the target location mechanism for generalised NOTIFY and UPDATE must use something new published in the parent zone. Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
