They communicated with an AD who overrode specific instructions which have IETF consensus to add the delegations 6 years ago. See IANA considerations paragraph 3.
The point of the instructions was to prevent DNSSEC validation failures like where shown here. I had to fight to get ULA prefixes added later on. The ADs don’t see the reports from users when DNSSEC breaks. ISC does see the reports. I suspect other resolver vendors do as well. Mark -- Mark Andrews > On 24 Jun 2023, at 08:16, David Conrad <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >
signature.asc
Description: Binary data
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
