Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

IAB Executive Administrative Manager
This is an announcement of an IETF-wide Call for Comment on
draft-iab-arpa-authoritative-servers-00.

The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection at:
<https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>

The Call for Comment will last until 2021-06-03. Please send comments to
[hidden email] and [hidden email].

Abstract:

   This document describes revisions to operational practices to
   separate function of the "arpa" top-level domain in the DNS from its
   historical operation alongside the DNS root zone.

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Russ Housley
I have read this document, and this seems like a fine way to separate the .arpa servers from the root servers.

Russ


> On May 6, 2021, at 2:48 PM, IAB Executive Administrative Manager <[hidden email]> wrote:
>
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>
> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].
>
> Abstract:
>
>   This document describes revisions to operational practices to
>   separate function of the "arpa" top-level domain in the DNS from its
>   historical operation alongside the DNS root zone.
>

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Paul Wouters-4
In reply to this post by IAB Executive Administrative Manager
On Thu, 6 May 2021, IAB Executive Administrative Manager wrote:

> Subject: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00>
>     (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)
>
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>

This has come up a number of times in the past, and I'm happt to see
this moving forward. The suggested approach seems well thought out.

Paul

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Eliot Lear
In reply to this post by Russ Housley
+1.  I think it looks good.

One very minor comment (more a question): if I read between the lines, it seems that some thought went into the use of the term “name space” in Section 3.1 regarding there not being a zone cut for ns.arpa (not that it’s anyone’s business, I suppose).  Would it be reasonable to make more plain the logic for that decision?  I could envision at least two reasons, but my own logic could be faulty.

Eliot

> On 6 May 2021, at 20:52, Russ Housley <[hidden email]> wrote:
>
> I have read this document, and this seems like a fine way to separate the .arpa servers from the root servers.
>
> Russ
>
>
>> On May 6, 2021, at 2:48 PM, IAB Executive Administrative Manager <[hidden email]> wrote:
>>
>> This is an announcement of an IETF-wide Call for Comment on
>> draft-iab-arpa-authoritative-servers-00.
>>
>> The document is being considered for publication as an Informational RFC
>> within the IAB stream, and is available for inspection at:
>> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>>
>> The Call for Comment will last until 2021-06-03. Please send comments to
>> [hidden email] and [hidden email].
>>
>> Abstract:
>>
>>  This document describes revisions to operational practices to
>>  separate function of the "arpa" top-level domain in the DNS from its
>>  historical operation alongside the DNS root zone.
>>
>
> _______________________________________________
> Architecture-discuss mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Joe Abley-4
In reply to this post by IAB Executive Administrative Manager
On 6 May 2021, at 14:48, IAB Executive Administrative Manager <[hidden email]> wrote:

> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>
> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].

I have read this document. It is good to see this work proceeding. It has been in the fridge for a long time and it's good to get it on the stove.

I have a few minor suggestions that the authors might like to consider.

1. In various places the text refers variously to phrases like "root operations" and "root server operations". I think the terminology could use some consistency; there are differences between the management of the root zone as a data object, its provisioning through the IANA functions operator and the Root Zone Maintainer and serving it on nameservers operated by Root Server Operators. If the document has things to say about this, even at a high level, I don't think there is harm in being clear. The authors are more aware of these differences than most other people and I don't think they need my editorial suggestions in this regard, but if it seems like it would be helpful to be more explicit by way of illustration I'd be happy to.

2. RFC 5855 which the document cites uses a naming scheme for the IP6.ARPA servers of the form <letter>.IP6-SERVERS.ARPA, and <letter>.IN-ADDR-SERVERS.ARPA for the IN-ADDR.ARPA servers. It seems to me that it would do no harm to choose a scheme for ARPA of the form <letter>.ARPA-SERVERS.ARPA for the ARPA zone; response size differences are minimal thanks to label compression and I think the scheme is more consistent (also with the names of the root servers). It also helps, I think, to give the impression that these servers are intended for a single purpose and are not general-purpose nameservers intended also to host other zones in the future (which I think would be a mistake).

3. This document describes a naming scheme under NS.ARPA (but see 2, above) without specifying whether it should be provisioned within the ARPA zone, or in a separate zone as was specified in RFC 5855. If the practice established in RFC 5855 (and in the root zone before it) was continued, this would be a separate zone hosted on the same servers as ARPA. If this ambiguity is deliberate (if it's desirable to leave this up to the whim of the IANA functions operator) then it would be good to document why. I think there are operational advantages to having zone cuts in the namespace, e.g. to preserve the possibility of hosting the child zones elsewhere, perhaps because it becomes operationally useful to sign them differently, speaking of which:

4. There's no mention of whether NS.ARPA (again, see 2, above), if it is provisioned as a separate zone, should be signed. Given the ambiguity in (3) I think this is a gap that could usefully be filled. I think it should be signed.

5. The term "in-bailiwick" feels awkward to me in the context of section 3.1, since to me it's a term associated with response construction and what is being discussed in that paragraph is namespace. However, since every TLD requires glue in the root zone I think the whole of the last paragraph could be safely removed. It's sufficient that ARPA be delegated according to normal practices for handling TLDs, and I don't think it makes sense to give the appearance of including special requirements for ARPA in this document, even if today they match everything else.

Hope this is helpful, and once again I'm glad to see this work is moving forward.


Joe
_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Tim Wicinski
(no hats)

I'm glad this is moving forward.   Joe's point about 5855 is valid on the naming, and the zone cuts.

It's never mentioned the zone is signed, though I'm sure everyone here reading it expects it. 

Nit:   At the top, instead of "Updates: RFC3172" it should be "Updates: 3172". 

tim


On Thu, May 6, 2021 at 3:26 PM Joe Abley <[hidden email]> wrote:
On 6 May 2021, at 14:48, IAB Executive Administrative Manager <[hidden email]> wrote:

> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>
> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].

I have read this document. It is good to see this work proceeding. It has been in the fridge for a long time and it's good to get it on the stove.

I have a few minor suggestions that the authors might like to consider.

1. In various places the text refers variously to phrases like "root operations" and "root server operations". I think the terminology could use some consistency; there are differences between the management of the root zone as a data object, its provisioning through the IANA functions operator and the Root Zone Maintainer and serving it on nameservers operated by Root Server Operators. If the document has things to say about this, even at a high level, I don't think there is harm in being clear. The authors are more aware of these differences than most other people and I don't think they need my editorial suggestions in this regard, but if it seems like it would be helpful to be more explicit by way of illustration I'd be happy to.

2. RFC 5855 which the document cites uses a naming scheme for the IP6.ARPA servers of the form <letter>.IP6-SERVERS.ARPA, and <letter>.IN-ADDR-SERVERS.ARPA for the IN-ADDR.ARPA servers. It seems to me that it would do no harm to choose a scheme for ARPA of the form <letter>.ARPA-SERVERS.ARPA for the ARPA zone; response size differences are minimal thanks to label compression and I think the scheme is more consistent (also with the names of the root servers). It also helps, I think, to give the impression that these servers are intended for a single purpose and are not general-purpose nameservers intended also to host other zones in the future (which I think would be a mistake).

3. This document describes a naming scheme under NS.ARPA (but see 2, above) without specifying whether it should be provisioned within the ARPA zone, or in a separate zone as was specified in RFC 5855. If the practice established in RFC 5855 (and in the root zone before it) was continued, this would be a separate zone hosted on the same servers as ARPA. If this ambiguity is deliberate (if it's desirable to leave this up to the whim of the IANA functions operator) then it would be good to document why. I think there are operational advantages to having zone cuts in the namespace, e.g. to preserve the possibility of hosting the child zones elsewhere, perhaps because it becomes operationally useful to sign them differently, speaking of which:

4. There's no mention of whether NS.ARPA (again, see 2, above), if it is provisioned as a separate zone, should be signed. Given the ambiguity in (3) I think this is a gap that could usefully be filled. I think it should be signed.

5. The term "in-bailiwick" feels awkward to me in the context of section 3.1, since to me it's a term associated with response construction and what is being discussed in that paragraph is namespace. However, since every TLD requires glue in the root zone I think the whole of the last paragraph could be safely removed. It's sufficient that ARPA be delegated according to normal practices for handling TLDs, and I don't think it makes sense to give the appearance of including special requirements for ARPA in this document, even if today they match everything else.

Hope this is helpful, and once again I'm glad to see this work is moving forward.


Joe
_______________________________________________
DNSOP mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Warren Kumari


On Thu, May 6, 2021 at 3:43 PM Tim Wicinski <[hidden email]> wrote:
(no hats)

<aol>Me too!</aol>

I've previously reviewed this (somewhere!), and my views remain the same: 1: looks good to me and 2: this is legely an internal to IANA matter. Nice of 'em to ask, but whatever...

W

 

I'm glad this is moving forward.   Joe's point about 5855 is valid on the naming, and the zone cuts.

It's never mentioned the zone is signed, though I'm sure everyone here reading it expects it. 

Nit:   At the top, instead of "Updates: RFC3172" it should be "Updates: 3172". 

tim


On Thu, May 6, 2021 at 3:26 PM Joe Abley <[hidden email]> wrote:
On 6 May 2021, at 14:48, IAB Executive Administrative Manager <[hidden email]> wrote:

> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>
> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].

I have read this document. It is good to see this work proceeding. It has been in the fridge for a long time and it's good to get it on the stove.

I have a few minor suggestions that the authors might like to consider.

1. In various places the text refers variously to phrases like "root operations" and "root server operations". I think the terminology could use some consistency; there are differences between the management of the root zone as a data object, its provisioning through the IANA functions operator and the Root Zone Maintainer and serving it on nameservers operated by Root Server Operators. If the document has things to say about this, even at a high level, I don't think there is harm in being clear. The authors are more aware of these differences than most other people and I don't think they need my editorial suggestions in this regard, but if it seems like it would be helpful to be more explicit by way of illustration I'd be happy to.

2. RFC 5855 which the document cites uses a naming scheme for the IP6.ARPA servers of the form <letter>.IP6-SERVERS.ARPA, and <letter>.IN-ADDR-SERVERS.ARPA for the IN-ADDR.ARPA servers. It seems to me that it would do no harm to choose a scheme for ARPA of the form <letter>.ARPA-SERVERS.ARPA for the ARPA zone; response size differences are minimal thanks to label compression and I think the scheme is more consistent (also with the names of the root servers). It also helps, I think, to give the impression that these servers are intended for a single purpose and are not general-purpose nameservers intended also to host other zones in the future (which I think would be a mistake).

3. This document describes a naming scheme under NS.ARPA (but see 2, above) without specifying whether it should be provisioned within the ARPA zone, or in a separate zone as was specified in RFC 5855. If the practice established in RFC 5855 (and in the root zone before it) was continued, this would be a separate zone hosted on the same servers as ARPA. If this ambiguity is deliberate (if it's desirable to leave this up to the whim of the IANA functions operator) then it would be good to document why. I think there are operational advantages to having zone cuts in the namespace, e.g. to preserve the possibility of hosting the child zones elsewhere, perhaps because it becomes operationally useful to sign them differently, speaking of which:

4. There's no mention of whether NS.ARPA (again, see 2, above), if it is provisioned as a separate zone, should be signed. Given the ambiguity in (3) I think this is a gap that could usefully be filled. I think it should be signed.

5. The term "in-bailiwick" feels awkward to me in the context of section 3.1, since to me it's a term associated with response construction and what is being discussed in that paragraph is namespace. However, since every TLD requires glue in the root zone I think the whole of the last paragraph could be safely removed. It's sufficient that ARPA be delegated according to normal practices for handling TLDs, and I don't think it makes sense to give the appearance of including special requirements for ARPA in this document, even if today they match everything else.

Hope this is helpful, and once again I'm glad to see this work is moving forward.


Joe
_______________________________________________
DNSOP mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dnsop


--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

Yasuhiro Orange Morishita
In reply to this post by IAB Executive Administrative Manager
Hi, IAB;

> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].

I have a technical comment.  Section 3.1 of this describes as follows:

---
   Because these nameservers are completely in-bailiwick of the "arpa"
                                            ^^^^^^^^^^^^
   zone, they will require glue records in the root zone.  This is
   consistent with current practice and requires no operational changes
   to the root zone.
---

This "in-bailiwick" is must be "in-domain".
Section 7 of RFC 8499 (DNS Terminology) defines it as I quoted below:

---
   Bailiwick:  "In-bailiwick" is a modifier to describe a name server
      whose name is either a subdomain of or (rarely) the same as the
      origin of the zone that contains the delegation to the name
      server.  In-bailiwick name servers may have glue records in their
      parent zone (using the first of the definitions of "glue records"
      in the definition above).  (The word "bailiwick" means the
      district or territory where a bailiff or policeman has
      jurisdiction.)

      "In-bailiwick" names are divided into two types of names for name
      servers: "in-domain" names and "sibling domain" names.

      *  In-domain: a modifier to describe a name server whose name is
         either subordinate to or (rarely) the same as the owner name of
         the NS resource records.  An in-domain name server name needs
         to have glue records or name resolution fails.  For example, a
         delegation for "child.example.com" may have "in-domain" name
         server name "ns.child.example.com".

      *  Sibling domain: a name server's name that is either subordinate
         to or (rarely) the same as the zone origin and not subordinate
         to or the same as the owner name of the NS resource records.
         Glue records for sibling domains are allowed, but not
         necessary.  For example, a delegation for "child.example.com"
         in "example.com" zone may have "sibling" name server name
         "ns.another.example.com".
---

Rrgards,

--
Yasuhiro 'Orange' Morishita <[hidden email]>
URI: <http://jprs.co.jp/en/> | <http://www.dns.jp/>

From: IAB Executive Administrative Manager <[hidden email]>
Subject: Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)
Date: Thu, 06 May 2021 11:48:04 -0700

> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-arpa-authoritative-servers-00.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/>
>
> The Call for Comment will last until 2021-06-03. Please send comments to
> [hidden email] and [hidden email].
>
> Abstract:
>
>    This document describes revisions to operational practices to
>    separate function of the "arpa" top-level domain in the DNS from its
>    historical operation alongside the DNS root zone.
>
> _______________________________________________
> IETF-Announce mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

_______________________________________________
Architecture-discuss mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/architecture-discuss