On 28 May 2014, at 21:43, David Conrad <drc@xxxxxxxxxxxxxxx> wrote: >> I would like every A-M.root-servers.net have an A and AAAA record. > [...] >> The root name service: >> ... >> MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS >> queries and responses. > > And if they don't? > > Just for clarity, the root server operators are under no obligation to do anything. The whole "MUST" bit is actually sort of misplaced since it isn't like people are going to wave a RFC (BCP or otherwise) at the root operators and change will magically happen. Root server operators will do what they want according to their own requirements/business drivers. In an ideal world, what the community wants and what the root server operators' requirements/business drivers are correspond, but people shouldn't be under any illusion that an RFC will make this happen. But that is not the problem of the IETF. If the IETF come to conclusion that root server services "must" support IPv4 and IPv6, so be it. It should be in the RFC. It is then up to whoever is policing the services (the root server operator themselves, their owner, the regulator in the jurisdiction they are within or whatever) to do the policing. Policing will not happen without a spec that services can be compared against. And lack of policing (which seems to be what you talk about) is I think a separate issue. I think IETF should do a darn good job here. As IETF can do. And then other open issues have to be taken care of elsewhere. Sure, it might be that some of the requirements are hard to enforce, and that IETF will be frustrated, but that is not worse than support for new RR Types, IPv6, DNSSEC and about a thousand other things IETF think is very important. IETF should lead. Not follow. I think personally a lot of the discussions for example in ICANN related to the new gTLDs would have been easier if IETF had had a clear lead on various issues related to the root zone. Like charset, strings etc that "are ok". Now a lot of that discussion has happened elsewhere, and even if of course some of that is more policy/business (and because of that fit in ICANN environment) it would have been easier if that discussion had a stable solid technical ground to stand on. Patrik
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail