Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Vixie]

John Levine wrote on 2022-08-01 15:22:

It appears that Paul Vixie   said:

i'm particularly interested in whether the root zone should have an NS
for the private-label tld(s) (.alt or ._alt or whatever) with an NS of
"localhost" and a dnssec "opt out" indicator so that these private tlds
can fit into the authenticity infrastructure.

Why?  If you're going to hack in your local names, why wouldn't you hack
in your local DNSSEC anchors at the same time?


that's the Yeti-DNS approach and it works but it doesn't support 
mobility with forwarders and is thus mostly a proof of concept. for 
scale, it's necessary to augment the namespace without a locally 
modified and signed root zone, and do it all in the resolver.


let's go back to the earlier part of the above-excerpted message:

+1. the namespace will be locally augmented. we should describe a way. 


dnssec is somewhat viral, in that the one true root zone will contain 
negative proofs for label ranges where nothing is known to exist. for 
local augmentation to scale, the one true root zone should admit that a 
few carve-out delegation points exist, and should specify that the 
content inside those delegations isn't signed.


if a mobile forwarding resolver is going to see content from the one 
true root and also content from its own local content, we should take 
pains to ensure that the assertions from the one true root do not 
conflict. while a recursive validator could possibly be educated in how 
to live with a foot in each world, an application validator (such as 
DANE) probably cannot be so educated.


"the namespace will be locally augmented. we should describe a way."

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Paul Hoffman]

On Aug 2, 2022, at 1:29 PM, Edward Lewis  wrote:
> 
> On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" 
>  wrote:
>> I would rather mention NSEC/NSEC3 so the reader gets an idea for the 
>> mechanism in RFC 8198. I left off NSEC3 because I thought that basically all 
>> use of NSEC3 was with opt-out, but if I'm wrong, I could put it in the text.
> 
> Just as a data point, there are two gTLDs over 1 million delegations that use 
> NSEC3 / no-opt out.
> 
> I have no data on ccTLDs, nor lower in the namespace.

This is useful info; thanks! I'll update the draft to say NSEC and NSEC3.

--Paul Hoffman




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Edward Lewis]

On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman"  wrote:
>I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism 
>in RFC 8198. I left off NSEC3 because I thought that basically all use of 
>NSEC3 was with opt-out, but if I'm wrong, I could put it in the text.

Just as a data point, there are two gTLDs over 1 million delegations that use 
NSEC3 / no-opt out.

I have no data on ccTLDs, nor lower in the namespace.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7068)

[John R. Levine]

Again RFC 7553 since they're transportts.


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _tcp  | [RFC6118] |
 | URI| _udp  | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of 
useful reference(s). Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7065)

[John R. Levine]

This looks correct, too.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.2.1

Original Text
-
 | URI| _iax  | [RFC6118] |

Corrected Text
--
 | URI| _iax  | [RFC6315] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Martin Schanzenbach]

I just read it and on page 5 it specifically excludes .onion and .gnu as
those do not use the DNS protocol (citing also the alt draft here).
So this is equivalent to the .alt draft only if the private-use TLD is
not limited to private-use DNS queries as investigated in the document.
I find this to be quite odd as I thought this is what .arpa was for
(RFC8375)!
.home is even listed in the table of the SAC document and one of the
motivations.

So, we would have to see what the actual proposed *use* of this private
TLD would be. If it is limited to DNS, then it is of no use for
alternative name systems and we would still need .alt.

Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400:
> Disclaimer: I work for the Internet Society but I am not speaking for them.
> 
> On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
> >
> >recommends that the ICANN board to pick a string that will never be put into 
> >the DNS root, and thus is usable for systems like GNS.
> 
> This was, of course, the whole point of the .alt draft in the first place, at 
> least when I was involved in preparing it.  I don't think any of us involved 
> then cared whether it was alt or one of thousands of other strings that it 
> could have been.  The main point was to come up with something that would not 
> pad total length too much and that could be a clear "protocol switch".  The 
> registration in the IANA sutld registry was suppossed to ensure the same 
> outcome as what is going through SSAC, but it makes no difference to me what 
> the characters are.  Note that because of the old-timey restriction, I 
> suspect the characters must all be alphabetic, though perhaps that rule has 
> been superseded by IDNA.
> 
> A
> 


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[John R. Levine]

On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:


recommends that the ICANN board to pick a string that will never be put 
into the DNS root, and thus is usable for systems like GNS.


This was, of course, the whole point of the .alt draft in the first place, at 
least when I was involved in preparing it.


Indeed.  If you look at SAC113 and draft-ietf-dns-alt-tld, you'll see a 
lot of the same names.


 I don't think any of us involved then cared whether it was alt or one 
of thousands of other strings that it could have been.


The leadning candidates were .ALT or one of the ISO 3166 User-assigned 
codes like .QZ, but I agree that picking one is more important than which 
one gets picked.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7067)

[John R. Levine]

This should also be RFC 7553 since SCTP is a transport.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7067

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _sctp | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "sctp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7065)

[John R. Levine]

This also looke correct.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.2.1

Original Text
-
 | URI| _iax  | [RFC6118] |

Corrected Text
--
 | URI| _iax  | [RFC6315] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7066)

[John R. Levine]

I believe the correct reference is RFC 7553, where section 4.1 says the 
name of a URI record is _service._transport, just like SRV, and DCCP is a 
transport.


On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7066

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _dccp | [RFC7566] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

This looks correct to me.


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7064

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
| URI| _acct | [RFC6118] |

Corrected Text
--
| URI| _acct | [RFC7566] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Andrew Sullivan]

Disclaimer: I work for the Internet Society but I am not speaking for them.

On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:


recommends that the ICANN board to pick a string that will never be put into 
the DNS root, and thus is usable for systems like GNS.


This was, of course, the whole point of the .alt draft in the first place, at least when 
I was involved in preparing it.  I don't think any of us involved then cared whether it 
was alt or one of thousands of other strings that it could have been.  The main point was 
to come up with something that would not pad total length too much and that could be a 
clear "protocol switch".  The registration in the IANA sutld registry was 
suppossed to ensure the same outcome as what is going through SSAC, but it makes no 
difference to me what the characters are.  Note that because of the old-timey 
restriction, I suspect the characters must all be alphabetic, though perhaps that rule 
has been superseded by IDNA.

A

--
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Hoffman]

The ISE started this thread with a discussion that included "Whether that means 
using TLD labels that begin with _ or whether that means suffixing them with 
".ALT", I leave to you experts to sort." There is another forthcoming option 
that could be used in draft-schanzen-gns, namely the unallocated string that 
may be chosen as part of the process coming out of SAC113.

SAC113 , published 
by ICANN's Security and Stability Advisory Committee, recommends that the ICANN 
board to pick a string that will never be put into the DNS root, and thus is 
usable for systems like GNS. The recommendation is moving forward, as can be 
seen on the SAC113 line on page 10 of 
.
 A string that is guaranteed to never appear in the DNS root can be used as the 
basis of private-use names, even if that guarantee doesn't come from the DNSOP 
Working Group.

(I was not part of the SAC113 work, but am reporting here so that the ISE and 
GNS can see that they will have additional options.)

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[David Conrad]

Hi,

On Aug 2, 2022, at 8:00 AM, Geoff Huston  wrote:
>> I came to this group because of concerns that Warren raised, and because the 
>> draft sits before me.  I have reviewed what discussion I could find in the 
>> logs relating to Warren's draft, which amounts to either (a) this is ICANN's 
>> problem or (b) there is nobody willing to make use of the space.  Please 
>> feel free to inform me if I have missed something.
>> 
>> Regarding (a), that is not my interpretation of RFC 6761.  RFC 6761 drops 
>> special use domains firmly in the lap of the IETF, which is presumably why 
>> Warren brought his draft here and why I came here and didn't go to ICANN.  
>> Regarding (b), we have someone here willing to at least have the 
>> conversation.
> 
> ICANN was not created out of thin air. It was created in part as an admission 
> by the IETF at the time that the dimensions of the discussions relating to 
> name spaces, alternate roots, name space expansion and such was far broader 
> than the IETF at the time and the discussions on this topics necessitated a 
> host and a community that was not isomorphic to the IETF.
> 
> Regarding your interpretation of RFC6761 and your conclusion, as ISE, that 
> this is not matter for ICANN, I respectfully disagree with the ISE here, and 
> I believe that such matters are well beyond the more limited scope and remit 
> of the IETF and the considerations of some 20 years ago in this space remain 
> relevant today.

I agree with Geoff.

I’ll be a bit more blunt: RFC 6761 was a mistake in a number of different ways 
that I won’t bother going into here. There is a reason its application has been 
halted. The idea that it “drops special use domains firmly in the lap of the 
IETF” presupposes a clear definition of “special use domains” that can be 
distinguished at a namespace as opposed to a protocol level. Unfortunately, 
distinguishing at the namespace level is unappealing as it would necessarily 
impact users (e.g, force them to use a “_”). That leaves partitioning the 
namespace. However, partitioning the singular domain name space involves 
non-technical policy considerations which is exactly why ICANN was created.

There are many reasons why the ICANN gTLD process is so Byzantine and painful. 
One of those reasons is because trying to distinguish why one group should get 
a chunk of the namespace and another shouldn’t is a very hard, almost always 
non-technical problem. The IETF has not shown a whole lot of interest or skill 
in dealing with those sorts of problems, something I believe RFC 2860 
recognized.

To me, the right answer here is as obvious as it is painful: requests for 
namespace partitioning (i.e., creation of top-level domains) should be punted 
over to ICANN (regardless of the protocol underlying the implementation of that 
namespace).  If a particular usage of the namespace doesn’t fit the model ICANN 
has come up with, it’s indicative a brokenness/failure within ICANN, not 
justification for bypassing the clear intent of RFC 2860. There has been a 
reluctance/inability on the part of both ICANN and the IETF to deal with this 
for more than 20 years. Given the proliferation of “alternative roots”, I don’t 
think this is desirable or even tenable.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [Editorial Errata Reported] RFC8552 (7068)

[RFC Errata System]

The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
  | URI| _tcp  | [RFC6118] |
  | URI| _udp  | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of 
useful reference(s). Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [Editorial Errata Reported] RFC8552 (7067)

[RFC Errata System]

The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7067

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
  | URI| _sctp | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "sctp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [Editorial Errata Reported] RFC8552 (7066)

[RFC Errata System]

The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7066

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
  | URI| _dccp | [RFC7566] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [Editorial Errata Reported] RFC8552 (7065)

[RFC Errata System]

The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.2.1

Original Text
-
  | URI| _iax  | [RFC6118] |

Corrected Text
--
  | URI| _iax  | [RFC6315] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[RFC Errata System]

The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7064

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _acct | [RFC6118] |

Corrected Text
--
 | URI| _acct | [RFC7566] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Paul Hoffman]

On Aug 2, 2022, at 7:57 AM, Vladimír Čunát 
 wrote:
> 
> Hello.
> 
> This line is misleading, I believe:
> 
> 
>> - RFC8198 describes how a validating resolver can emit fewer queries in 
>> signed zones that
>> use NSEC for negative caching.
> 
> That RFC describes aggressive caching also for NSEC3 and (positive) 
> wildcards.  (Of course, opt-out NSEC3 records are basically useless, but many 
> zones are without opt-out.)
> 
> For example, the formulation could be simply truncated as:
> > RFC8198 describes how a validating resolver can emit fewer queries in 
> > signed zones.

I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism 
in RFC 8198. I left off NSEC3 because I thought that basically all use of NSEC3 
was with opt-out, but if I'm wrong, I could put it in the text.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Geoff Huston]

> On 2 Aug 2022, at 2:15 am, Independent Submissions Editor (Eliot Lear) 
>  wrote:
> 
> 
> On 02.08.22 10:35, Joe Abley wrote:
>> 
>>> Had I wanted to do so, I would not have approached dnsop in the first place.
>> Had you wanted to which? I'm confused.
> 
> I came to this group because of concerns that Warren raised, and because the 
> draft sits before me.  I have reviewed what discussion I could find in the 
> logs relating to Warren's draft, which amounts to either (a) this is ICANN's 
> problem or (b) there is nobody willing to make use of the space.  Please feel 
> free to inform me if I have missed something.
> 
> Regarding (a), that is not my interpretation of RFC 6761.  RFC 6761 drops 
> special use domains firmly in the lap of the IETF, which is presumably why 
> Warren brought his draft here and why I came here and didn't go to ICANN.  
> Regarding (b), we have someone here willing to at least have the conversation.

ICANN was not created out of thin air. It was created in part as an admission 
by the IETF at the time that the dimensions of the discussions relating to name 
spaces, alternate roots, name space expansion and such was far broader than the 
IETF at the time and the discussions on this topics necessitated a host and a 
community that was not isomorphic to the IETF. 

Regarding your interpretation of RFC6761 and your conclusion, as ISE, that this 
is not matter for ICANN, I respectfully disagree with the ISE here, and I 
believe that such matters are well beyond the more limited scope and remit of 
the IETF and the considerations of some 20 years ago in this space remain 
relevant today.

   Geoff



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Vladimír Čunát]

Hello.

This line is misleading, I believe:

- RFC8198 describes how a validating resolver can emit fewer queries 
in signed zones that

use NSEC for negative caching.


That RFC describes aggressive caching also for NSEC3 and (positive) 
wildcards.  (Of course, opt-out NSEC3 records are basically useless, but 
many zones are without opt-out.)


For example, the formulation could be simply truncated as:
> RFC8198 describes how a validating resolver can emit fewer queries in 
signed zones.



--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 2. Aug 2022, at 14:39, Vladimír Čunát  wrote:
> 
> On 02/08/2022 13.53, Martin Schanzenbach wrote:
>> This is not an oversight (altough I have to admin it did not occur to me
>> that this a valid DNS TLD at the time of writing).  [...]
>> 
> Oh, I understood that this DNSOP thread - notably the first post - originated 
> as an attempt to reduce collisions between GNS pet names and DNS names.  
> Probably by standardizing .alt (or similar) as special in DNS and encouraging 
> that GNS pet names nest under it.
> 
> If I got this wrong, I suspect it might be helpful to restate the 
> DNSOP-related intentions more clearly.
> 

You understand correctly and maybe my comments are a bit too exaggerated at 
times.

The draft as it exists now has obvious collisions with the DNS namespace. A 
direct result from our previous efforts wrt RFC6761; there is just no 
sub-namespace to use for us. (See discussions years ago)
So, we mostly separated the technical protocol design from the namespace issue.
This (understandably) lead to discussions with the ISE (and others) and now 
also to (possible) issues in the IESG conflict review as part of our 
independent submission.
The idea was to connect with dnsop in order to establish if the ".alt"-draft 
could help here.
If there was a consensus over the ".alt" draft or other guidance on how to 
specify alternate name systems (and their namespaces), then I would assume this 
would affect the considerations of the conflict review and potentially require 
us to modify the draft accordingly.
Which is why we consulted with ISE whether it makes sense to participate in 
this discussion and possibly offer draft-schanzen-gns as a possible first 
"customer" of a potential new ".alt"-RFC.
So, you probably need to differentiate between the GNS draft as it is defined 
now and how it could potentially look like.
I think this is also why ISE said in another post that it may be wise to 
consider this as an opportunity to settle this issue. However, it seems quite 
entrenched.

BR
Martin

> --Vladimir | knot-resolver.cz
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Vladimír Čunát]

On 02/08/2022 13.53, Martin Schanzenbach wrote:

This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing).  [...]


Oh, I understood that this DNSOP thread - notably the first post - 
originated as an attempt to reduce collisions between GNS pet names and 
DNS names.  Probably by standardizing .alt (or similar) as special in 
DNS and encouraging that GNS pet names nest under it.


If I got this wrong, I suspect it might be helpful to restate the 
DNSOP-related intentions more clearly.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Martin Schanzenbach]

This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing).
You can see in Section 7.1 that we also use "www.example.org" in the
draft.
We address the namespace topic in Section 9.9.
As mentioned, the draft currently goes all-in with respect to namespace
squatting/shadowing.
The argument is this:
GNS-aware applications will likely ONLY want to resolve through GNS OR
prefer GNS over DNS OR have their own logic to decide what to do with a
given name.

GNS-unaware application always assume DNS. In that case, IF the system
admin or user configured local overrides (e.g. for .pet or example.org)
in GNS then it is the expected behaviour that those names are resolved
through GNS. It is the same as users messing with /etc/hosts or NSS.
In fact, NSS is one method of configuring this for GNS, see Appendix
A.4.

BR
Martin

Excerpts from Vladimír Čunát's message of 2022-08-02 13:32:47 +0200:
> Interesting bit: the current -gns draft even uses the .pet TLD in an 
> example, which is a TLD that actually exists in the official global DNS.


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Vladimír Čunát]

Interesting bit: the current -gns draft even uses the .pet TLD in an 
example, which is a TLD that actually exists in the official global DNS.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Independent Submissions Editor (Eliot Lear)]

On 02.08.22 10:35, Joe Abley wrote:



Had I wanted to do so, I would not have approached dnsop in the first place.

Had you wanted to which? I'm confused.


I came to this group because of concerns that Warren raised, and because 
the draft sits before me.  I have reviewed what discussion I could find 
in the logs relating to Warren's draft, which amounts to either (a) this 
is ICANN's problem or (b) there is nobody willing to make use of the 
space.  Please feel free to inform me if I have missed something.


Regarding (a), that is not my interpretation of RFC 6761.  RFC 6761 
drops special use domains firmly in the lap of the IETF, which is 
presumably why Warren brought his draft here and why I came here and 
didn't go to ICANN.  Regarding (b), we have someone here willing to at 
least have the conversation.



By approaching dnsop in the first place with a box of freshly lit matches you 
seem precisely to be ignoring the prior discussion.


I didn't light the matches.  That, I'm afraid, is the nature of the 
publication request.  From an ISE perspective, my intent is to take 
quite seriously concerns that the IESG raises, with an eye toward safety 
in this case.



If you don't intend to publish the drafts on your table then I don't understand 
what you're saying in the context of the hat you're wearing.


I have not made a publication decision.  That decision would be far 
EASIER to make if this group provided guidance, which is why I am here.  
Absent that guidance, I will... muddle along and make the best decision 
I can, again taking into account the IESG's forthcoming 5742 review.


I could have denied this publication request at its outset, but that 
would have sent a message to namespace researchers and developers that 
their work is not welcome, and that they should just ignore the IETF and 
the RFC series.  Is that what you would advocate?  Does that make the 
Internet safer?



Perhaps more fundamentally the idea of the ISE promoting work to be done in a 
working group apparently without the involvement of the chairs itself seems 
confusing. You know more about the job than I do, but in the past when I have 
published documents through the independent stream, the ISE's consultation was 
limited to an IESG conflict review.


The ISE may consult whoever is necessary to consult to achieve the best 
outcome.  Let's please not attempt to make this a process argument.


Eliot

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Joe Abley]

On Aug 2, 2022, at 10:26, Independent Submissions Editor (Eliot Lear) 
 wrote:

> On 02.08.22 09:56, Joe Abley wrote:
>> 
>> If the position of the ISE is to ignore the prior discussion and publish one 
>> set of opinions regardless then perhaps it would be more straightforward 
>> just to say so.
> 
> Had I wanted to do so, I would not have approached dnsop in the first place.

Had you wanted to which? I'm confused.

By approaching dnsop in the first place with a box of freshly lit matches you 
seem precisely to be ignoring the prior discussion. 

If you don't intend to publish the drafts on your table then I don't understand 
what you're saying in the context of the hat you're wearing. 

Perhaps more fundamentally the idea of the ISE promoting work to be done in a 
working group apparently without the involvement of the chairs itself seems 
confusing. You know more about the job than I do, but in the past when I have 
published documents through the independent stream, the ISE's consultation was 
limited to an IESG conflict review.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Aaaagain

On 02.08.22 09:56, Joe Abley wrote:


If the position of the ISE is to ignore the prior discussion and publish one 
set of opinions regardless then perhaps it would be more straightforward just 
to say so.


Had I wanted to do so, I would not have approached dnsop in the first place.

Eliot


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Joe Abley]

Hi Eliot,

On Aug 2, 2022, at 07:59, Independent Submissions Editor (Eliot Lear) 
 wrote:

> But what is not reasonable to expect researchers to attempt to enter the 
> ICANN arena in order to facilitate a the safe use of a new naming system that 
> doesn't require use of the DNS.

This argument (and others) have been discussed extensively in the past. There 
are many counter-arguments. Again, I have my doubts that rehashing then again 
will lead to a different outcome. 

(To this particular point, just for illustration and not intended for 
discussion, for which see mail archives: suitable anchors for private 
namespaces can be acquired through the icann system for roughly $10/year, or in 
the opinions of some for $0/year by using one of the two-letter ISO-3165 code 
points that are reserved for private use.)

If the position of the ISE is to ignore the prior discussion and publish one 
set of opinions regardless then perhaps it would be more straightforward just 
to say so. 

If the position is rather that dnsop should pick this up again, perhaps that's 
a question for the dnsop chairs to manage?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Martin Schanzenbach]

Hi,

Excerpts from Peter Thomassen's message of 2022-08-01 16:57:45 -0400:
> 
> On 8/1/22 12:01, Paul Vixie wrote:
> >>
> >> I agree and I think publication of these drafts would be a good idea
> >> (may be with status Experimental since, as Joe Abley said, there is
> >> clearly no IETF consensus). Note that I am skeptical about their use:
> >> most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
> >> not read the RFC and, if they do, won't follow it. But at least we
> >> will be able to say that we tried and we have a solution (and not a
> >> ridiculous one such as "pay ICANN 185 000 US $").
> > 
> > +1. the namespace will be locally augmented. we should describe a way.
> 
> I agree, too.
> 
> > i'm particularly interested in whether the root zone should have an NS for 
> > the private-label tld(s) (.alt or ._alt or whatever)
> 
> Not sure if ._alt vs .alt has been discussed (in that case I've missed it.)
> 
> I'd like to use the opportunity to refer to using _* labels (such as 
> ._myownprotocol): 
> https://mailarchive.ietf.org/arch/msg/dnsop/vQCi5ibTXw6Vfr2gbTnk-D5jcW0/ It 
> addresses some (not all) of Martin's concerns.
> 
> The OP wrote:
> > TLD labels that begin with _
> 
> (Note the plural.) Perhaps that was intended to mean those _*-style TLDs.
> 
> > with an NS of "localhost" and a dnssec "opt out" indicator so that these 
> > private tlds can fit into the authenticity infrastructure.
> 
> That's one way. OTOH, if we specify _* as non-DNS use, resolver could just 
> "know". (That does not preclude also doing what you're suggesting.)
> 

While _* is _a_ solution to the problem resulting in shorter suffixes,
it is also much worse in another aspect: usability.
1. "_" is not very legible and easily confused with a space or faulty
rendering of a character.
2. "_" is (on most keyboards) a lot more effort to input as it requires
the shift key. This is why ".", "#" and "/" are chosen so often.

A usable suffix should support the user in understanding it.
Which is also why (as pointed by in this thread) ".alt" is problematic
because of the "alternative" implications.

Apart from dedicated TLD for name systems (e.g. ".ens", ".eth", ".gns"
etc etc) the next best thing would be a subdomain/TLD combination such
as:

g.ns (.ns is already taken I know)
e.ns
onio.ns
OR
g.ads (.ads is already taken for a very useful purpose I know)
e.ads

(GADS was the name of GNS in the very beginning and stood for "GNU
Alternative Domain System)

Maybe a nicer alternative could be found. ".nrs" for "Name Resolution
System"? Or ".dns"?

g.nrs?
e.nrs?

Anyway. You should also take into account that effectively ".alt" or
whatever it would become is effectively also giving GNS a special-use
TLD for now as we do not see any other systems standing in line at any
IETF WG/ISE and GNS could simply squat "*.alt".
So the question would also be: If ".alt" can be done, why not ".gns".

IMO, IF the ".alt" TLD exists, I would really apprectiate an IANA
registry for the subdomains limited to name systems that can demonstrate
either specifications or large scale deployments.
"Anything goes under .alt" makes any suffix even more unattractive.

Finally, draft-schanzen-gns will likely still allow to "squat" DNS
names.
Just like "/etc/hosts"/NSS  will always allow to squat any DNS name. It is just
something that cannot be avoided by design and this reality should be
acknowledged.
Saying "www.example.com" MUST always resolve to whatever it is in DNS
does not map to OS capabilities in practice. Probably not even to all DNS
deployments.
So, is "squatting" actually the problem here? And if it is, is it a
problem of alternative name systems or a general problem with how name
resolution is implemented on common OSes?

I have also read [1] and quite agree with it. So if a general statement on 
namespaces
should be pursued maybe this can be used as a starting point.
It does, however, IMO reinforce the notion that RFC6761 should (can?) be
used for non-DNS name systems.

[1] 
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/

BR
Martin

> ~Peter
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop