Firstly they are HOME.ARPA servers. Just because they are the same physical servers it doesn’t mean that policy for the root zone content has to apply to other zones on that server. Maintaining that distinction is important.
Secondly a otherwise empty zone on these servers will fulfil the requirements to provide a insecure delegation. Just drop the DNAME from the zone contents below. All the servers involved can serve SOA and NS records and return NXDOMAIN for names under HOME.ARPA. If you need to delegate to a different set of servers create a seperate constellation of servers that you control directly or by contract. Trying to re-use AS112 servers will never work reliably as you don’t have agreements with *all* the operators. This also applies to the operators of EMPTY.AS112.ARPA. As for DNAME, that is a requirement of DNSSEC which, in theory, all the root servers support fully. Mark > On 12 Dec 2017, at 10:16 am, Kim Davies <kim.dav...@iana.org> wrote: > > Hi Mark, > > Quoting Mark Andrews on Tuesday December 12, 2017: >> >> HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 >> 1800 900 604800 86400 >> HOME.ARPA. NS A.ROOT-SERVERS.NET. > .. >> HOME.ARPA. DNAME EMPTY.AS112.ARPA. > > It is unclear to me how this avoids having root servers process DNAME > records. Given the process of consultation, coordination and testing > support for DNAME records in the root servers (or relocating the .arpa > authorities) is likely to take longer than is desirable to have home.arpa > insecurely delegated, the delegation to AS112 was considered as the best > short-term approach even if it is not without its own difficulties. > > kim -- 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
