[as112-ops] [Ext] Request to add service.arpa to AS112

Thu May 2 15:00:38 UTC 2024

Hi Aleksi, Hi all,

I don't think we can assume root servers all have proven DNAME support and that it can just be deployed into action today. We know that some root servers are operated on custom software and they have not needed to support DNAME until now. To implement ZONEMD there was a deliberative process of consultation, review and testing prior to its introduction.

I've reverted Joe's suggestion on stalling service.arpa implementation back to the group that oversees operation of .arpa, but unless we hear otherwise plan to introduce a delegation for service.arpa. 

That said, I am very sympathetic to the desire and will also explore further implementing RFC 9120 so we can have greater separation of concerns between root operations and the .arpa zone.

kim

On 5/2/24, 00:48, "Aleksi Suhonen" <as112-ops at trex.fi <mailto:as112-ops at trex.fi>> wrote:

Hello Kim,

Hear hear Joe.

IPv6 and DNAME are roughly the same age, and even share some history 
through A6 records. There should be no valid excuse in 2024 to avoid 
using DNAMEs, on root servers or otherwise. Same goes for IPv6.

Furthermore, if more real world experiments are needed, anything new 
pointing at AS112 is the perfect vehicle for such experiments.

While we all do our best at running a reliable service, AS112 by its 
very nature is not a reliable service. As an example: a major fraction 
of queries coming in to these servers originate from RFC1918 address 
space, where there is little hope that the responses will find their way 
back to the original device that made the query.

As Joe mentioned, there are unregistered AS112 nodes out there, and we 
have no way of reaching the maintainers of those nodes. Besides, I 
suspect that some of the registered AS112 nodes are running on automatic 
as well. Whoever set them up and registered them has moved on, and 
nobody now knows they're there or how they work anymore... let alone 
adding a new zone in there...

If there is going to be a problem with DNAMEs, I'm pretty sure it will 
be caused by AS112 nodes that never added {empty,hostname}.as112.arpa in 
the first place, and which won't be adding any other new zones either.

Kind Regards,

On 29/04/2024 18:19, jabley at strandkip.nl <mailto:jabley at strandkip.nl> wrote:
> Hi Kim,
> 
> HOME.ARPA was another mistake, I think, but that one was implemented 
> before anybody complained about it.
> 
> I appreciate there is conservatism about the contents of the root zone, 
> but to to put this particular question in context, DNAME was first 
> specified in August 1999. I seem to remember ICANN paying for a 
> consultant to prepare a report back around 2010 or so to determine 
> whether there were any concerns about using DNAME in the root zone (at 
> that time, related to various discussions about IDN variants) and there 
> were none. APNIC did a survey that concluded that there was no 
> discernible lack of support for DNAME in the public Internet (see RFC 
> 7535 section 6 and appendix A). To give another illustrative example of 
> what degree of conservatism exists in practice, ZONEMD was specified in 
> 2021 and a ZONEMD record was added to the root zone last September. So 
> I guess we are not that afraid of new records.
> 
> As to whether DNAME is too new to be added to the ARPA zone because it 
> is served by root servers, this is the first time I have heard anybody 
> ever say that. While there has been concern over records present in the 
> root zone expressed over the years, I have never heard anybody say 
> anything similar about the ARPA zone. We didn't hear that concern in 
> 2015 when RFC 7535 was published.
> 
> I would say that the RFC you're looking at here is not ready to be 
> published until IANA has confirmed that the operational aspects it 
> relies upon are finished. There's no way to confirm that every AS112 
> operator has added this zone to their configuration, which is why the 
> plan was not to do new delegations to the AS112 servers. If you want to 
> avoid lame delegations the expedient path is actually to push back as 
> appropriate so that you can use DNAME.
> 
> 
> Joe
> 
>> On Apr 29, 2024, at 16:54, Kim Davies <kim.davies at iana.org <mailto:kim.davies at iana.org>> wrote:
>>
>> Hi Joe,
>>
>> I wasn't a party to the discussions to lead to this specific 
>> construction that it be done in the same manner as home.arpa, so I am 
>> not sure what factors went into it.
>>
>> With that said, while we haven't had discussions recently, my 
>> understanding is there is a reluctance to add new RR types or modes of 
>> behaviour to the root servers without specific research, testing and 
>> outreach first. Because the .ARPA zone is served directly by the root 
>> servers it is subject to this conservative approach used for the root 
>> zone. The long term plan to address this is to separate .ARPA 
>> infrastructure from the root zone per RFC 9120, but there is no 
>> timeline to complete that work.
>>
>> Where we find ourselves is we need to delegate service.arpa relatively 
>> expediently given the associated RFC is ready to be published, and 
>> therefore we don't think it can wait to be predicated on either (a) 
>> doing the necessary exploration for adding it to root infrastructure; 
>> or (b) migrating .ARPA infrastructure off the root severs first. I 
>> think should either of those subsequently happen we could reprovision 
>> the delegation to a DNAME down the road.
>>
>> kim
>>
>> On 4/29/24, 07:40, "jabley at strandkip.nl <mailto:jabley at strandkip.nl> 
>> <mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl>><mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl> 
>> <mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl>>>" <jabley at strandkip.nl <mailto:jabley at strandkip.nl> 
>> <mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl>><mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl> 
>> <mailto:jabley at strandkip.nl <mailto:jabley at strandkip.nl>>>> wrote:
>>
>>
>> Hi Kim,
>>
>>
>> Part of the motivation for RFC 7535 was to avoid the need for 
>> reconfiguration of AS112 servers for sinking DNS traffic to new parts 
>> of the namespace, recognising that this is almost guaranteed to cause 
>> lame delegations.
>>
>>
>> Do we know why the requirements for SERVICE.ARPA is not being 
>> implemented using DNAME? Is it too late to ask, or perhaps to suggest 
>> that DNAME is the preferred way to do this?
>>
>>
>>
>>
>> Joe
>>
>>
>>> On Apr 29, 2024, at 16:25, Kim Davies <kim.davies at iana.org <mailto:kim.davies at iana.org> 
>>> <mailto:kim.davies at iana.org <mailto:kim.davies at iana.org>><mailto:kim.davies at iana.org <mailto:kim.davies at iana.org> 
>>> <mailto:kim.davies at iana.org <mailto:kim.davies at iana.org>>>> wrote:
>>>
>>> Dear AS112 operators:
>>>
>>> IANA is being being asked to implement the IANA considerations of a
>>> new RFC-to-be, draft-ietf-dnssd-srp-25, which requires delegation of
>>> "service.arpa" to black hole servers as follows:
>>>
>>> In order to be fully functional, the owner of the 'arpa.' zone must
>>> add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172].
>>> This delegation is to be set up as was done for 'home.arpa', as a
>>> result of the specification in Section 7 of [RFC8375]. This is
>>> currently the responsibility of the IAB [IAB-ARPA]
>>>
>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25><https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25><https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25>>>*delegation__;Iw!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR84FqaPtg$ [datatracker[.]ietf[.]org]>
>>>
>>> Therefore, just as with home.arpa we are requesting AS112 operators to
>>> configure their AS112 nodes as soon as practical to answer queries for
>>> this new zone on blackhole-[12].iana.org <http://iana.org/> <http://iana.org/>>, so that 
>>> we may delegate it in
>>> the .arpa zone with those two NS records. The zone should be configured
>>> with the "db.dd-empty" zone content described in RFC 7534.
>>>
>>> I suspect one of the questions will be whether we can use DNAME as
>>> described in RFC 7535. While we have made some progress in separating
>>> root server infrastructure from .ARPA infrastructure (see RFC 9120),
>>> that work has not concluded and today they are still served through
>>> common infrastructure.
>>>
>>> Our intention is to add the delegation to the .ARPA zone around mid-May,
>>> to provide AS112 operators time to make this configuration update.
>>>
>>> Thank you in advance, and if you have any questions please let me know,
>>> or respond back to this group.
>>>
>>> Kindest regards,
>>>
>>> Kim Davies
>>> Internet Assigned Numbers Authority
>>> _______________________________________________
>>> as112-ops mailing list
>>> as112-ops at lists.dns-oarc.net <mailto:as112-ops at lists.dns-oarc.net> 
>>> <mailto:as112-ops at lists.dns-oarc.net <mailto:as112-ops at lists.dns-oarc.net>><mailto:as112-ops at lists.dns-oarc.net <mailto:as112-ops at lists.dns-oarc.net> <mailto:as112-ops at lists.dns-oarc.net <mailto:as112-ops at lists.dns-oarc.net>>>
>>> https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$ <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$> <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$ <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$>><https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$ <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$> <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$ <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!7R6yIbZW1rYpC8Z3nClCZ1CQVIOqaA5Q7wVmbTNDXglFMYXPytvM1XIOmrP94Dp3JkeBmROz6F3n6jrXSR-wCQThlg$>>> [lists[.]dns-oarc[.]net]
>>> as112.net <https://urldefense.com/v3/__http://as112.net/__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3qkmJA6U$ <https://urldefense.com/v3/__http://as112.net/__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3qkmJA6U$> [as112[.]net]>administrative requests
>>> ops at as112.net <mailto:ops at as112.net> <mailto:ops at as112.net <mailto:ops at as112.net>><mailto:ops at as112.net <mailto:ops at as112.net> 
>>> <mailto:ops at as112.net <mailto:ops at as112.net>>>
> 
> 
> _______________________________________________
> as112-ops mailing list
> as112-ops at lists.dns-oarc.net <mailto:as112-ops at lists.dns-oarc.net>
> https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3aFpvFwo$ <https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/as112-ops__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3aFpvFwo$> [lists[.]dns-oarc[.]net]
> as112.net administrative requests
> ops at as112.net <mailto:ops at as112.net>

-- 
+358 44 9756548 / https://urldefense.com/v3/__http://www.trex.fi/__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3rqVfd1o$ <https://urldefense.com/v3/__http://www.trex.fi/__;!!PtGJab4!5BfPNcMNcprBnsN_6xxZxMhKsPLcT3BYmR8UPdBRZdYsdF8Rct-P7GgNrNR1WUkC1cLXmd7q_ngl4HuunhA3rqVfd1o$> [trex[.]fi]
Aleksi Suhonen / TREX Regional Exchanges Oy

You say "potato", I say "closest-exit."