[dns-operations] [Ext] Re: in-addr.arpa. "A" server "loopback network" misconfiguration

[Mark Andrews]

Thanks   

All the zones listed in RFC6303 (as well as any added to the registry subsequently) need to have insecure delegations. At the moment some do and some don’t. The simplest way to do this is to delegate to the same servers as those of the parent zone.  This keeps the traffic going to the same place and you have a known set of machines to touch (unlike AS112). 

e.g.

127.in-addr.arpa NS a.in-addr-servers.arpa.
…
127.in-addr.arpa NS f.in-addr-servers.arpa.

Where the zone contents are just the SOA record and the NS RRset.  This is also the minimalist change that needs to be made. 
-- 
Mark Andrews

> On 24 Jun 2023, at 02:38, Kim Davies <kim.davies at iana.org> wrote:
> 
> Hi Mark, Hi all,
> 
> Quoting Mark Andrews on Friday June 23, 2023:
>> There should be an insecure delegation for 127.in-addr.arpa. In the in-addr.arpa zone. IANA have instructions from the IETF to do this in RFC 6303.
>> There has been a ticket open for years with IANA to correct the missing insecure delegations. 
> 
> I looked into this in our ticketing system. Our practice is to review
> all open tickets at least weekly until they are resolved, so there are
> no tickets that are left open indefinitely without activity.
> 
> In this case, it looks like we communicated with the relevant IETF Area
> Director and were advised to take no further action. Since it is now
> almost 6 years later, happy to take a fresh look at this and see what
> may need to be done.
> 
> kim