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

[David Conrad]

Mark,

Kim indicated the relevant IETF Area Director advised that no action be taken.  I suspect instead of reiterating what the changes are that you believe should be made, a more useful course of action would be to understand why the relevant IETF Area Director provided the advise that they did and whether the circumstances have changed after 6 years to change that advice.

Regards,
-drc

> On Jun 23, 2023, at 2:38 PM, Mark Andrews <marka at isc.org> wrote:
> 
> 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
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230623/aeb289f2/attachment.sig>