> On 4 May 2018, at 10:13 am, Bill Woodcock <wo...@pch.net> wrote: > > > >> On May 3, 2018, at 4:28 PM, David Huberman <david.huber...@icann.org> wrote: >> >>>> On May 3, 2018, at 3:27 PM, David Huberman <david.huber...@icann.org> >>>> wrote: >>>> In practical terms, when any type of registry strips away a lame delegation >>>> attached to a real, operating network with users behind it, and things >>>> break >>>> as a result… >> >> Woody replied: >>> But isn’t that, by definition, impossible? What could break as a result of >>> a _lame_ delegation >>> being removed? >> >> Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS >> example: >> >> You are the registrant of 192.168.0.0/17. >> You setup a single SOA record for 168.192.in-addr.arpa instead of properly >> defining 128 records >> for each /24 reverse zone. >> >> PTR queries to the NSes will work (for the /17). >> >> But you’ll fail the lameness checking at an RIR because the RIR checks all >> zones in the >> SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you >> really meant >> to claim authority over the /16. > > Errrr, but that’s a special RIR alternate understanding of what lameness > means, specific to CIDR, no?
No. That is one form of basic DNS lameness. The server delegated to doesn’t server the delegated zone. > In the general DNS sense, if the NS can answer PTR queries for the thing > delegated to it, it’s not lame. And we’re talking about forward here, not > in-addr, and more specifically, not the special CIDR in-addr. DNS servers need to produce VALID negative answers as well as VALID positive answers for the name space delegated to them. You need to test for BOTH types of answers. Failure to produce VALID negative answers causes problems when new types are introduced. Look at the history of AAAA, SPF, and TLSA records. All of these are/were issued by clients to see if the records existed at given names. While these are mostly forward zone issues the same issues could arise in the IN-ADDR.ARPA and IP6.ARPA name spaces. We don’t know what is coming in the future. We have however defined how those queries should be answered. We can test to ensure that correct behaviour occurs. > -Bill -- 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
