> Pre-delegation checks add friction to the domain registration > process. They further complicate the commuications between > different actors in the commercial graph (registrars, registries, > resellers, DNS operators, hosting companies) and introduce delay > and manual intervention into what might otherwise be a fairly > automated or at least automatable process. That is to say, checks > have a cost, and that cost might well be difficult to sell in a > commercial environment, especially one where the policy depends on > a membership that is often quite commercially motivated. (I > appreciate not all TLDs are the same.)
Oh, yes, the sanctity of making a buck, "we can't let any technical obstacle get in it's way", and by extension "contributing to maintaining the good health of the public DNS doesn't really matter, as long as we get to collect the registration fees." I guess it depends on what service the registry is actually offering. One way to look at it is that it's offering a service to extend the public DNS name space to registrants. In that scenario it makes perfect sense to do a one-time check on initial registration or update, with the intention of preventing the domain owner from shooting himself in the foot. Another way would be to look at it as purely a name space administration issue, i.e. just ensure uniqueness, and let loose the commercial folks with their "product innovations" and "improved efficiency" aims, casting aside quite a few technical considerations for the public DNS. In case you haven't noticed, I have a distaste for the latter, and a number of registries operate with the former model. On the technical side, I don't think anyone has suggested to introduce repeated checks with de-registration either of a single NS or an entire domain on auto-polit. Does any public registry actually do that sort of thing? I've never heard of it. I call that a straw man. > On the technical side, I think arriving at a generalised approach > will be difficult. For example, > > 1. Repeated checks -- just because something is declared good at > registration time doesn't mean it might not go bad later. How > often do you need to check? You are assuming too much here, I think, in particular what the goal is and what the a reasonable mechanism to attain that goal could be. I've not argued to "outlaw inconsistencies or lameness", and it is true that such errors may be introduced over time outside of the interactions with the registry. What I have argued is that it's probably a good idea to check for consistency & service on the time of registration or update. > 2. The possibility of cascading failure -- a partial failure in a > delegation, if punished by a domain suspension, might result in > a complete failure. This is at worst an attack vector and at > best contrary to the interests of stability for users of the > Internet. Making automated changes to disable things that are > already demonstrably fragile seems a bit like form over > function. Again, here you're assuming that something doing a repeated check will automatically de-register a domain on auto-pilot. I certainly have not argued for such a thing, and would find the suggestion absurd. > 3. Deliberately-incoherent namespaces -- many of the most common > responses in the DNS are generated at response time according > to a variety of dynamic policy, and are subject to access > control. So vantage points matter. Any policy that is measuring > the health of a delegation needs to be able to interpret the > results of multiple measurements from different vantage points > and understand which of them correspond to a policy that is > acceptable, without any a priori understanding of what the > response generation policy is. In general I think this is > problematic. I don't think this is problematic at all. If a registrant wants to do "private stuff" with his domain, he'd do best in keeping that private, and the effects of that out of visibility for the registry. The registry should be checking the publically visible data, and is unlikely to have a probe for consistency checking within a "private DNS zone" of a registrant. And ... if you really insist on doing violence to the DNS standards and expectations of consistency, you're of course free to do whatever dirty deeds you have convinced yourself you need to do in a subdomain / sub-zone of your properly functioning public DNS domain. > 4. The fiction of a single namespace. The particular bits of > machinery that respond to particular names and particular > addresses (including nameserver names and nameserver addresses) > are not always the same. Private namespaces exist that avoid > collisions with the nominally-public namespace by making the > same companyname.com domain exist in both, but implementing > each very differently. This is valid and good advice, even > (e.g. compared to squatting on .HOME or .CORP). Should those > domains be suppressed simply because they are not intended for > use by the general public? I would actually argue that the name space is a single -- the public DNS name space is a single tree. Witness the rather long discussion thread in this group around the .ALT name space, and how normal DNS- using clients and servers are supposed to relate to it, and how we now need to carve out a blockage to prevent someone else coming along later and actually getting .ALT registered in the DNS. I will concede, though, that what is different is that certain parts of the name space are only available to a subset of the clients. So, you're arguing that it would be "causing too much work"(?) for the registry to insist on having the registrant stand up a couple of public name servers to register the publically visible version of a domain? Really? Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
