Or we could just ask that zone adminstrators and in particular gTLD registry operators actually do what is required of them for operational stability. I don't see "except section 4 or 4.2 or 4.2.2 or 4.2.2 paragraph 3". I do see a exception to restrict the use of hypens in labels.
http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf 1. Standards Compliance 1.1. DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., âxn--ndk061nâ). RFC 1034, Section 4.2.2. Administrative considerations "As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so." Mark In message <20161105175842.ga26...@sources.org>, Stephane Bortzmeyer writes: > On Wed, Nov 02, 2016 at 03:10:18PM +0900, > fujiw...@jprs.co.jp <fujiw...@jprs.co.jp> wrote > a message of 61 lines which said: > > > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > > improve resolver algorithm. > > I see the point but I have two practical reservations: > > 1) Having two separate caches may be a big change for some > implementations. > > 2) It will make debugging more difficult. With your two-caches system, > "dig @myresolver NS foobar.example" will retrieve the data in > foobar.example, while the resolver will use, when iterating, the data > from .example, which is not showed and I don't see a standard way to > retrieve it from the "delegation cache". > > Apart from that, one detail: section 6 on implementations is too > short. You should expand it at least with the name of the > implementations (you mention two in your OARC talk, so it is not a > secret), and may be with RFC 7942 boilerplate. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
