Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

[Andrew McConachie]

As this document’s shepherd, FWIW I think that if the document does 
proceed in the WG it needs significant love and attention. The document 
in its current state is not well written and it would require 
significant labor to resolve its numerous grammar and linguistic issues. 
It’s also very long and if the authors want to continue with it they 
should consider shortening it or breaking it up into multiple more 
targetted drafts.


My $0.02.

-Andrew

On 30 May 2023, at 0:58, Tim Wicinski wrote:


All,

The chairs want to thank everyone for the feedback on this document
recently.  We've been in discussions with Warren and the authors about 
this
document, and we have some questions we'd like the working group to 
help us

resolve.

While this work was relevant when it was first written and adopted, we 
feel
that over time the DNSSEC landscape has changed and this document may 
not

be as relevant as it once was.

Questions to consider:

Should this draft be removed from the WG?
Are there fundamental issues that need to be addressed in this 
document?
Are there items in the document that should be moved to another 
document?


The chairs are currently considering abandoning this document in its
current state.  We'd like to hear from others on this.

We're going to let comments run for two weeks, and wrap up June 12, 
2023.


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


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

Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps

[Andrew McConachie]

On 7 Mar 2023, at 18:48, Joe Abley wrote:

On Tue, Mar 7, 2023 at 15:56, David Conrad  
wrote:


4 weeks for ICANN (which? Organization, Board, Community, all 3?) to 
provide feedback? (That feels sort of like the ITU asking "the IETF" 
for feedback on an IP-related protocol document in 4 weeks.)


Did the IETF (also which?) provide feedback on this similar request 
for feedback?


https://www.icann.org/en/public-comment/proceeding/proposed-procedure-for-selecting-a-top-level-domain-string-for-private-use-13-01-2023

It seems like the answer is no. Perhaps it would be useful for someone 
to decide whether these ships are intentionally passing in the night 
or whether more attention to navigation is required.


Not drect input to the public comment, but folks should be aware of 
these correespondences between IAB and ICANN.






—Andrew

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Andrew McConachie]

On 22 Aug 2022, at 16:05, Paul Hoffman wrote:

On Aug 22, 2022, at 2:41 AM, Andrew McConachie  
wrote:

Why not allow unicode or at least some subset of it?


It already does. The DNS is a binary format with a common assumption 
(but not requirement!) of LDH characters.




This is the bit that confused me. Because when I read the draft Section 
3.2 says:


   The "Name" column lists each
   name in the non-DNS protocol that would appear immediately to the
   left of the .alt pseudo-TLD.

This sentence is talking about presentation, but I believe you’re 
saying the registry will hold the wire format. Wireformat is the better 
choice.


The only restriction that seems reasonable to me is prohibiting zero 
length strings. This list convinced me other restrictions would be a bad 
idea.


--Andrew

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[Andrew McConachie]

On 20 Aug 2022, at 2:55, Warren Kumari wrote:

On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell 


wrote:


Hiya,

On 19/08/2022 20:43, Warren Kumari wrote:

So, it is perfectly acceptable (in my view) for it to have:

Reference Name
-
a-cool-document foo.alt
another-document foo.alt
yet-another-doc bar.alt

I agree that such duplicate names are acceptable in this registry.

I scanned the draft quickly and think it's good. (I'll try do a 
closer

read in a few days.)

Only thing with which I'd argue for now is that I think RFC required 
is a

much simpler rule for the registry.



The draft doesn’t specify if this registry is restricted to ASCII LDH 
or not. Can I write an RFC and get #&^%&^%)(}{.alt?


How about ..alt? Or .alt? (My proposed string is NULL)

Why not allow unicode or at least some subset of it? If we want people 
to use this registry for their hip new naming system I think we should 
encourage developers to move away from ASCII LDH.


—Andrew

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Andrew McConachie]

On 31 Jul 2022, at 20:53, Paul Vixie wrote:


Andrew McConachie wrote on 2022-07-28 03:24:

Path MTU discovery remains widely undeployed due to
   security issues, and IP fragmentation has exposed weaknesses in
   application protocols.


PMTUD doesn’t work through NAT and that’s probably the main 
reason why it doesn’t work on the Internet. I think that’s less 
of a security issue than just a general issue with PMTUD not working 
on the modern Internet.
path mtu discovery has been significantly rethought in the modern 
internet:


https://www.rfc-editor.org/rfc/rfc8899.html

apparently, it sometimes works:

https://developers.redhat.com/articles/2022/05/23/plpmtud-delivers-better-path-mtu-discovery-sctp-linux

see also:

<>

https://datatracker.ietf.org/wg/plpmtud/about/

i suggest further reading and perhaps reconsideration. we've got to 
break out of the MTU 1500 jail some day or the internet will end in 
header processing related heat death. some work is being done and some 
results are already known. we should be open to the possibility of 
improvement.




I apologize for derailing this conversation by bringing up NAT. My point 
was that the document makes a claim that PMTUD ‘remains widely 
undeployed due to security issues’. Yet it makes no reference to 
anything that might back up that claim. I would suggest the document not 
make any claim as to why PMTUD remains widely undeployed. If it must 
make such a claim then there should be some supporting evidence for it.


—Andrew

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Andrew McConachie]

On 28 Jul 2022, at 13:19, Joe Abley wrote:


On Jul 28, 2022, at 12:24, Andrew McConachie  wrote:


PMTUD doesn’t work through NAT


That's a very definitive statement considering that there's no useful 
standard for NAT.


If there's actual research on this to demonstrate that, pragmatically 
speaking, no implementations use the payload of a type 3 code 4 ICMP 
message to identify a translated target for the packet I would like to 
read it, because that sounds interesting.




The document makes the claim that PMTUD “remains widely undeployed due 
to security issues.” My contention is that it has little to do with 
security and more to do with the current structure of the Internet. We 
don’t need a useful standard for NAT to recognize that most 
implementations break PMTUD, and that those implementations of NAT are 
deployed enough to make PMTUD significantly broken. Firewalls break 
PMTUD as well, and I guess that’s a security thing, but currently the 
sentence reads like operators don’t deploy PMTUD  in favor of security 
and I don’t think that’s true.



Currently, DNS is known to be the largest
  user of IP fragmentation.


Compared to what? I would just drop this sentence because it 
doesn’t add anything to the document and it’s trying to make a 
point that doesn’t need to be made.


I'd also like to see a citation for this one if there has been a 
study. I agree that it's probably the most familiar example of 
fragmentation for an audience mainly preoccupied with the DNS, but 
that's probably not a helpful observation :-)


Before I was interested in the DNS I worked for an ethernet switch 
vendor for 8 years, and I often find the way MTU gets talked about in 
IETF documents simply weird.


RFC 791 introduces the term "maximum transmission unit" to be the 
maximum size of a datagram, not the maximum size of a frame whose 
payload is a datagram.


The maximum sized datagram that can be transmitted through the
  next network is called the maximum transmission unit (MTU).

MTU is a measurement of maximum frame size for a network segment 
starting at Layer 2.


I have also heard MTU used in that way. I have always assumed it was 
just sloppy writing.


There may be prior use of the phrase that I'm not aware of (prior to 
1981) but even if that's the case I think it's reasonable to use the 
IETF definition of the phrase in the IETF.


I think Ethernet was not standardised until the publication of IEEE 
802.3 in 1983. I also think the original specification did not 
anticipate switches but described a multi-access network with a 
broader collision domain.


So perhaps it's reasonable to say that the IETF use of MTU pre-dates 
Ethernet switch vendors' usage, since it pre-dates Ethernet switches, 
since it pre-dates Ethernet.


Ok. But the text still isn’t clear on how many bytes are assumed to be 
consumed by layer-2 protocols. We don’t need to have a super tight 
definition of MTU to progress this document. Implementors just need to 
know how big of packets they can transmit.




Joe



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

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Andrew McConachie]

Path MTU discovery remains widely undeployed due to
   security issues, and IP fragmentation has exposed weaknesses in
   application protocols.


PMTUD doesn’t work through NAT and that’s probably the main reason 
why it doesn’t work on the Internet. I think that’s less of a 
security issue than just a general issue with PMTUD not working on the 
modern Internet.



Currently, DNS is known to be the largest
   user of IP fragmentation.


Compared to what? I would just drop this sentence because it doesn’t 
add anything to the document and it’s trying to make a point that 
doesn’t need to be made.



 Most of the Internet and especially the inner core has an MTU of
 at least 1500 octets.  Maximum DNS/UDP payload size for IPv6 on
 MTU 1500 ethernet is 1452 (1500 minus 40 (IPv6 header size) minus
 8 (UDP header size)).  To allow for possible IP options and
 distant tunnel overhead, authors' recommendation of default
 maximum DNS/UDP payload size is 1400.


Before I was interested in the DNS I worked for an ethernet switch 
vendor for 8 years, and I often find the way MTU gets talked about in 
IETF documents simply weird. MTU is a measurement of maximum frame size 
for a network segment starting at Layer 2. Yet there’s no discussion 
of layer 2 here. The discussion starts at layer 3 and because of that 
the math doesn’t make any sense to me.


Is there just an assumption that layer 2 will consume 18 bytes? 
(6+6+2+4) (DA+SA+ET+FCS) Can we state this assumption in the document? 
As I read it now it’s not clear how many bytes are assumed to be 
consumed by layer 2 headers.


I said many of these same things in a mail to this list on August 12, 
2020 but never received a response.


Thanks,
Andrew

On 26 Jul 2022, at 23:13, Suzanne Woolf wrote:


Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-avoid-fragmentation 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). 
The requested status is BCP.


Since we're starting the Last Call during the IETF week, and many 
folks are on holidays in the next few weeks, the WGLC will end in 
three weeks (instead of the usual two), on August 16.


Substantive comments to the list, please. It’s fine for minor edits 
to go direct to the authors. We need to hear positive support to 
advance it, or your comments on what still needs to be done.




Thanks,
Suzanne
For the chairs


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


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[Andrew McConachie]

Hi Warren,

I find the terminology in this document somewhat self-contradicting and 
confusing.


*  pseudo-TLD: A label that appears in a fully-qualified domain name
   in the position of a TLD, but which is not registered in the
   global DNS.  This term is not intended to be pejorative.

*  TLD: The last visible label in either a fully-qualified domain
   name or a name that is qualified relative to the root.

These definitions tell me that a pseudo top-level domain appears in a 
fully-qualified domain name in the top-level position. So is a 
pseudo-TLD something that appears in a *real* domain name? Or is a 
domain name that has a pseudo-TLD a pseudo-domain name? Is foo.alt a 
pseudo-domain name, or a *real* domain name with a pseudo-TLD? It’s 
not clear.


The draft makes a distinction between 'DNS names' and 'domain names’, 
and I understand 'DNS names' to be a subset of 'domain names'. Yet when 
I read the definition of 'domain name' in RFC 7719 I don't see this 
distinction being made. Is the DNS namespace supposed to be a subset of 
the domain namespace? I can't figure it out from the terminology 
sections of this draft and RFC 7719.


"The ALT label MAY be used in any domain name as a pseudo-TLD to signify 
that this is an alternative (non-DNS) namespace, and should not be 
looked up in a DNS context."


*  DNS context: The namespace anchored at the globally-unique DNS
   root.  This is the namespace or context that "normal" DNS uses.

According to the definitions given ‘DNS namespace' and 'DNS context' 
are synonyms, and the antonym of 'DNS namespace' is 'alternative 
namespace'.


So how about we change the sentence to:
"The ALT label MAY be used in any domain name as a pseudo-TLD to signify 
that this is an alternative (non-DNS) namespace, and should not be 
looked up in the DNS namespace."


And change the definition to:

*  DNS namespace: The namespace anchored at the globally-unique DNS
   root.  This is the namespace that the DNS protocol uses.

It's easier to understand if we eliminate the word context entirely and 
just talk about namespaces.


Thanks,
Andrew



On 21 Jun 2021, at 19:48, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Name System Operations WG of 
the IETF.


Title   : The ALT Special Use Top Level Domain
Authors : Warren Kumari
  Andrew Sullivan
Filename: draft-ietf-dnsop-alt-tld-13.txt
Pages   : 11
Date: 2021-06-21

Abstract:
   This document reserves a string (ALT) to be used as a TLD label in
   non-DNS contexts.  It also provides advice and guidance to 
developers

   developing alternative namespaces.

   [Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general 
musings,

   etc.  They will be removed before publication.  This document is
   being collaborated on in Github at: 
https://github.com/wkumari/draft-
   wkumari-dnsop-alt-tld.  The most recent version of the document, 
open

   issues, etc should all be available here.  The authors (gratefully)
   accept pull requests. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Andrew McConachie]

On 16 Apr 2021, at 17:18, Paul Hoffman wrote:

On Apr 16, 2021, at 5:31 AM, Andrew McConachie  
wrote:


If I understand section 4.3 correctly, DNSSEC validating stub 
resolvers SHOULD NOT resolve these names. Is that the intention of 
Section 4.3?


No, definitely not. The text says:
   3.  Name resolution APIs and libraries SHOULD NOT recognise these
   names as special and SHOULD NOT treat them differently.  Name
   resolution APIs SHOULD send queries for these names to their
   configured caching DNS server(s).
Not recognizing them as special means to treat them like any other 
name. There is no mention of DNSSEC.




I realize now my question was unclear. My understanding is that a DNSSEC 
validating stub SHOULD attempt to validate these names, which will fail. 
Therefore a DNSSEC validating stub cannot use these names.


Thanks,
Andrew

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-01.txt

[Andrew McConachie]

Dear Roy, Joe, and Eberhard,

If I understand section 4.3 correctly, DNSSEC validating stub resolvers 
SHOULD NOT resolve these names. Is that the intention of Section 4.3?


Why reserve so many names for a singular purpose? If human semantics are 
irrelevant then why not just pick a name at random and reserve that one? 
There may come a time in the future where one of these names might be 
useful for something else.


Section 4.4 has a typo. “attempt to look up NS records for the,” 
should be “attempt to look up NS records for them,”.


—Andrew

On 10 Apr 2021, at 14:45, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Name System Operations WG of 
the IETF.


Title   : Top-level Domains for Private Internets
Authors : Roy Arends
  Joe Abley
  Eberhard W. Lisse
Filename: draft-ietf-dnsop-private-use-tld-01.txt
Pages   : 14
Date: 2021-04-10

Abstract:
   There are no defined private-use namespaces in the Domain Name 
System

   (DNS).  For a domain name to be considered private-use, it needs to
   be future-proof in that its top-level domain will never be 
delegated

   from the root zone.  The lack of a private-use namespace has led to
   locally configured namespaces with a top-level domain that is not
   future proof.

   The DNS needs an equivalent of the facilities provided by BCP 5 
(RFC

   1918) for private internets, i.e. a range of short, semantic-free
   top-level domains that can be used in private internets without the
   risk of being globally delegated from the root zone.

   This document describes a particular set of code points which, by
   virtue of the way they have been designated in the ISO 3166 
standard,
   are thought to be plausible choices for the implementation of 
private

   namespaces that are anchored in top-level domains.

   The ISO 3166 standard is used for the definition of eligible
   designations for country-code top-level Domains.  This standard is
   maintained by the ISO 3166 Maintenance Agency.  The ISO 3166 
standard

   includes a set of user-assigned code elements that can be used by
   those who need to add further names to their local applications.

   Because of the rules set out by ISO in their standard, it is
   extremely unlikely that these user-assigned code elements would 
ever

   conflict with delegations in the root zone under current practices.

   In order to avoid the operational and security consequences of
   collisions between private and global use of these code elements as
   top-level domains, this document specifies that such top-level
   domains should never be deployed in the global namespace, and
   reserves them accordingly in the Special-Use Names Registry
   [RFC6761].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-private-use-tld-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-private-use-tld-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-private-use-tld-01


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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

Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options

[Andrew McConachie]

On 4 Nov 2020, at 17:47, Wes Hardaker wrote:


"Andrew McConachie"  writes:

 1. Is a special-use domain per [RFC6761], and does not (and will 
never) exist in the GID.
In this document, we refer to this as ".internal" for discussion 
purposes only following

conventions in [draft-wkumari-dnsop-internal].

I read the above text as telling me that .internal will never exist 
in

the GID.


Ahh...  thanks for the precise reference.

Yes, those two bullets are backwards in their examples. Ugh.  
.internal

and .zz should be switched there.

(fixed in the source)


Thanks Wes. That makes sense.

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

Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options

[Andrew McConachie]

On 4 Nov 2020, at 2:11, Wes Hardaker wrote:


"Andrew McConachie"  writes:

I’m having a hard time understanding the two proposed deployments 
in

this document.


It's not as clean as I'd like, certainly.  I was pushing up against 
the

draft submission deadlines and didn't get all the wording into place.


In 2.2.1 it states that .internal does not exist in the GID. Yet in
the Summary section immediately after it states that .internal is an
unsigned TLD. Which is it?


.internal is an unsigned TLD and is the GID.


1.  Is a special-use domain per [RFC6761], and does not (and will
   never) exist in the GID.  In this document, we refer to this as
   ".internal" for discussion purposes only following conventions 
in

   [draft-wkumari-dnsop-internal].

I read the above text as telling me that .internal will never exist in 
the GID.




I don't see where in 2.2.1 it says that though.

In 2.2.2 it states that .zz is an unsigned delegation in the GID’s 
DNS

root. Yet in the summary section it states that “.zz is a
special-use-like TLD that MUST never be assigned”. Which is it?


The later.  .zz is not delegated.  Again I'm not sure which sentence
you're referring to though.


 2.  Is an unsigned delegation within the (GID's) DNS root, with NS
   records likely pointing eventually to something like 
127.0.53.53.

   In this document, we refer to this as ".zz" following convention
   in [draft-ietf-dnsop-private-use-tld].  We note that 
[draft-ietf-

   dnsop-alt-tld] also proposed a private namespace (".alt") that
   also fits into this category.

This seems to be saying that .zz is an unsigned delegation. Am I missing 
something obvious here?


[someone did note that one of my section names is incorrect as well 
and

referred to the wrong one]


My understanding of an unsigned TLD is that it is delegated in the
root zone unsigned. And I take it that GID is simply a synonym for
what many call The Public DNS.


Yep.  It's "Global Internet's DNS (GID)", per the document.

There are, unfortunately, more than one naming environments.  We've
known this for years with even /etc/hosts being different from the 
DNS,

and NIS coming along later, etc.  Nowdays, there are so many
split-systems with both internal and externally differing naming sets 
I

was trying to use something that included the world "global" to be
super-clear this is the "big one".
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options

[Andrew McConachie]

Hi Wes,

I’m having a hard time understanding the two proposed deployments in 
this document.


In 2.2.1 it states that .internal does not exist in the GID. Yet in the 
Summary section immediately after it states that .internal is an 
unsigned TLD. Which is it?


In 2.2.2 it states that .zz is an unsigned delegation in the GID’s DNS 
root. Yet in the summary section it states that “.zz is a 
special-use-like TLD that MUST never be assigned”. Which is it?


My understanding of an unsigned TLD is that it is delegated in the root 
zone unsigned. And I take it that GID is simply a synonym for what many 
call The Public DNS.


Thanks,
Andrew

On 2 Nov 2020, at 23:50, Wes Hardaker wrote:


I've been thinking for a while what approach to take with respect to
private name spaces.  This document summarizes some of my thinking, 
and
draws some conclusions (that will likely poke some bears and beehives 
at

the same time).

--


A new version of I-D, 
draft-hardaker-dnsop-private-namespace-options-00.txt

has been successfully submitted by Wes Hardaker and posted to the
IETF repository.

Name:   draft-hardaker-dnsop-private-namespace-options
Revision:   00
Title:  DNS Private Namespace Options
Document date:  2020-11-02
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-hardaker-dnsop-private-namespace-options-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-private-namespace-options/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-private-namespace-options
Htmlized:   
https://tools.ietf.org/html/draft-hardaker-dnsop-private-namespace-options-00



Abstract:
   This document discusses the trade-offs between various options 
about
   creating a private namespace within top level domains within the 
root

   zone.




Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
Wes Hardaker
USC/ISI

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


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt

[Andrew McConachie]

On 9 Oct 2020, at 11:58, Roy Arends wrote:


> On 9 Oct 2020, at 10:38, Andrew McConachie  wrote:

Hi Roy and Joe,

It’s not clear to me whether the document is advising to only use 
this facility when a sub-domain of a public domain name is 
unavailable, or to optionally use this facility based on the user’s 
preference. What I would like the document to say is that only when a 
sub-domain of a public domain is unavailable should this facility be 
considered. The reader should get the impression that they should try 
really really hard to not use the ISO-3166 reserved string if they 
can.


This is marked as a BCP and so I would expect to see this advice 
prominent in the document. Since, IMO at least, that is the best 
current practice. Only when a user cannot use a sub-domain of a 
domain they control should they even consider using the ISO-3166 
reserved string. Ideally there could be a new section discussing this 
advice between the current sections 1 and 2. That way the reader will 
encounter the best practice before encountering the work around.


Thanks for your comment Andrew,

The next version will contain more text directed to this.

IMHO, the mere availability of a subdomain (of an existing domain) 
should not automatically preclude the use of a private top-level 
domain. That is, I disagree with the notion that “they should try 
really really hard to not use the ISO-3166 reserved string”.


Note that a domain may not always be tied to the same legal entity. 
When software or devices are shipped with a default configuration that 
is meant to work only locally (there are a few scenarios that include 
home use or corporate use), using a public domain is problematic. 
Queries will leak to the authoritative servers of that public domain, 
long after the public domain has changed hands.


It is also not desirable from a legal and even operational standpoint 
if software that is shipped with a default public domain will be 
“phoning home” all the time.


There are likely to be many different use cases, some where a public 
domain is useful, some where a private-use domain is useful.


Hi Roy,

Thanks for the response. I think we’re basically in agreement here.

If the mere availability of a sub-domain (of an existing domain) 
precluded ever using this ISO-3166 reserved string then there would 
never be a valid use case for the ISO-3166 string. If only because one 
can always register a new domain and delegate a sub-domain. We can 
quibble over what “try really really hard” means, but it would not 
improve the document to enumerate every possible use case and proscribe 
which route the user should take for each one.


I look forward to your next version with more text on this topic.

Thanks,
Andrew

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt

[Andrew McConachie]

On 8 Oct 2020, at 11:54, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Name System Operations WG of 
the IETF.


Title   : Top-level Domains for Private Internets
Authors : Roy Arends
  Joe Abley
Filename: draft-ietf-dnsop-private-use-tld-00.txt
Pages   : 10
Date: 2020-10-08

Abstract:
   There are no defined private-use namespaces in the Domain Name 
System

   (DNS).  For a domain name to be considered private-use, it needs to
   be future-proof in that its top-level domain will never be 
delegated

   from the root zone.  The lack of a private-use namespace has led to
   locally configured namespaces with a top-level domain that is not
   future proof.

   The DNS needs an equivalent of the facilities provided by BCP 5 
(RFC

   1918) for private internets, i.e. a range of short, semantic-free
   top-level domains that can be used in private internets without the
   risk of being globally delegated from the root zone.

   The ISO 3166 standard is used for the definition of eligible
   designations for country-code top-level Domains.  This standard is
   maintained by the ISO 3166 Maintenance Agency.  The ISO 3166 
standard

   includes a set of user-assigned code elements that can be used by
   those who need to add further names to their local applications.

   Because of the rules set out by ISO in their standard, it is
   extremely unlikely that these user-assigned code elements would 
ever

   conflict with delegations in the root zone under current practices.
   This document explicitly reserves these code elements to be safely
   used as top-level domains for private DNS resolution.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-private-use-tld-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-private-use-tld-00


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


Hi Roy and Joe,

It’s not clear to me whether the document is advising to only use this 
facility when a sub-domain of a public domain name is unavailable, or to 
optionally use this facility based on the user’s preference. What I 
would like the document to say is that only when a sub-domain of a 
public domain is unavailable should this facility be considered. The 
reader should get the impression that they should try really really hard 
to not use the ISO-3166 reserved string if they can.


This is marked as a BCP and so I would expect to see this advice 
prominent in the document. Since, IMO at least, that is the best current 
practice. Only when a user cannot use a sub-domain of a domain they 
control should they even consider using the ISO-3166 reserved string. 
Ideally there could be a new section discussing this advice between the 
current sections 1 and 2. That way the reader will encounter the best 
practice before encountering the work around.


Thanks,
Andrew

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

[Andrew McConachie]

Dear Mr Vixie and Mr Fujiwara,

I’m a relative noob to DNS and the IETF, and I’m often confused in 
how the term MTU is used when discussing DNS. Essentially it is a 
layer-2 term, and outside of layer-2 it can be difficult to understand 
what is meant by it. It’s a term that’s become overloaded.


For example this sentence, “In practice, the smallest MTU witnessed in 
the operational DNS community is 1500 octets, the Ethernet maximum 
payload size.” Does this imply an Ethernet overhead of 18 bytes 
(6+6+2+4) (DA+SA+ET+FCS)? And what precisely is meant by Ethernet here? 
Contemporary layer-2 technologies that we call ethernet do not have this 
1500 byte limit. The problem is that as a reader it’s not clear to me 
how many bytes are left over for layer-3 and above.


Perhaps it’s too late in the game to limit the use of ‘MTU’ to 
layer-2 discussions. But it would be a lot clearer to me if we used a 
term like ‘packet size’ when discussing layer-3 and above, and kept 
the MTU term for use only when discussing layer-2 segment maximum 
datagram sizes.


Also, it seems odd to not mention NAT in the second sentence, “Path 
MTU discovery remains widely undeployed due to security issues”. NAT 
breaks PMTUD when ICMP is used as the discovery mechanism. This should 
get mentioned in the document somewhere. There are likely many 
technologies deployed that break PMTUD that I’m not even aware of, 
it’s not just ‘security issues’.


—Andrew

On 30 Jun 2020, at 12:36, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Name System Operations WG of 
the IETF.


Title   : Fragmentation Avoidance in DNS
Authors : Kazunori Fujiwara
  Paul Vixie
Filename: draft-ietf-dnsop-avoid-fragmentation-00.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   Path MTU discovery remains widely undeployed due to security 
issues,
   and IP fragmentation has exposed weaknesses in application 
protocols.

   Currently, DNS is known to be the largest user of IP fragmentation.
   It is possible to avoid IP fragmentation in DNS by limiting 
response

   size where possible, and signaling the need to upgrade from UDP to
   TCP transport where necessary.  This document proposes to avoid IP
   fragmentation in DNS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-00


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

[Andrew McConachie]

On 6 Aug 2020, at 16:41, Paul Hoffman wrote:

On Aug 6, 2020, at 4:08 AM, Andrew McConachie  
wrote:


What does it mean for a resolver to be primed, or for a resolver to 
not be primed? For example, is a resolver considered primed only if 
it has all root server names and IP addresses? 50%? At least 1?


Excellent questions, two that the WG can certainly consider. Note that 
it *is* two questions, the root server names and the associated 
addresses.


From the text you quote:


  Priming is the act of finding the list of root servers from a
  configuration that lists some or all of the purported IP addresses 
of
  some or all of those root servers.  A recursive resolver starts 
with

  no information about the root servers, and ends up with a list of
  their names and their addresses.


RFC 8109 indicates that priming means knowing the full set of names 
and the full set of addresses.
It would be good if this document said that without having to refer back 
to RFC 8109.




If that were true it would be impossible for the resolver to find 
anything. It definitely starts with some information about the root 
servers. Maybe change "no information" to "this information".


This distinction is important. A resolver starts with no actual 
information, but only meta-information: where to get the actual names 
and addresses for the root server. Is there a better way to say this 
in the -bis document?


Meta-information is information, just like meta-data is data. The 
distinction only depends on context.


How about this for the last sentence, “A recursive resolver starts 
with no cached information about the root servers, and finishes with a 
full list of their names and their addresses in its cache.”


—Andrew

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

Re: [DNSOP] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

[Andrew McConachie]

Dear Peter, Matt and Paul,

What does it mean for a resolver to be primed, or for a resolver to not 
be primed? For example, is a resolver considered primed only if it has 
all root server names and IP addresses? 50%? At least 1?



   Priming is the act of finding the list of root servers from a
   configuration that lists some or all of the purported IP addresses 
of

   some or all of those root servers.  A recursive resolver starts with
   no information about the root servers, and ends up with a list of
   their names and their addresses.

If that were true it would be impossible for the resolver to find 
anything. It definitely starts with some information about the root 
servers. Maybe change "no information" to "this information".


Thanks,
Andrew

On 1 Jul 2020, at 1:39, Paul Hoffman wrote:

Greetings again. Since RFC 8109 has been published, there has been 
more discussion of what DNS priming means. This has caused the 
document authors to see a few places where RFC 8109 could be clarified 
and improved. Please see:

   https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/

Comments are welcome. If the WG wants to adopt this work, that would 
be grand as well.


--Paul Hoffman___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

Re: [DNSOP] [Editorial Errata Reported] RFC8490 (5804)

[Andrew McConachie]

This looks to be a bug with the data tracker. I've sent mail to 
datatracker-proj...@ietf.org asking them to open a bug.


I believe this errata can be closed.

--Andrew

On 8/9/19 11:10, John Dickinson wrote:

Hi,

After a quick look, I can see that the data tracker is incorrectly saying 
Updated by RFC7766 but the document does not say that.

regards
John

On 9 Aug 2019, at 9:47, RFC Errata System wrote:


The following errata report has been submitted for RFC8490,
"DNS Stateful Operations".

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

--
Type: Editorial
Reported by: Andrew McConachie 

Section: GLOBAL

Original Text
-
RFC8490 states that it is both 'Updated By' and 'Updates' RFC7766.

Corrected Text
--
I believe RFC8490 is not updated by RFC7766.

Notes
-
I'm not sure if this actually errata, but it should be fixed regardless. The 
data tracker page for RFC8490 state that it is both 'Updated By' and 'Updates' 
RFC7766.

https://datatracker.ietf.org/doc/rfc8490/
https://datatracker.ietf.org/doc/html/rfc8490

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.

--
RFC8490 (draft-ietf-dnsop-session-signal-20)
--
Title   : DNS Stateful Operations
Publication Date: March 2019
Author(s)   : R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. 
Lemon, T. Pusateri
Category: PROPOSED STANDARD
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG


John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt

[Andrew McConachie]

On 5/16/17 17:42, Ted Lemon wrote:

Would the following change address your concerns?

Section 4.1.1., paragraph 3:
OLD:

 o  The Internet requires a globally unique namespace

NEW:

 o  The Internet requires a globally unique namespace: a namespace in
which any given name refers to the same information (has the same
meaning) no matter who requests that information and no matter
from which specific name server they request it.


Section 4.1.1., paragraph 4:
OLD:

 o  Private networks may operate private namespaces, but still require
that names in the public namespace be globally unique.

NEW:

 o  Private networks may operate private namespaces, with names that
have meanings only locally (within the private network) but still
require that names in the public namespace be globally unique.


This is to the paragraphs preceding the one you commented on, but I think it 
does a good job of introducing the concepts used in the paragraphs you 
commented on, in a fairly natural way.
Yes. I think it makes clear to the reader what is _meant_ by 'meaning' 
throughout the document.


Thanks,
Andrew

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt

[Andrew McConachie]

On 5/15/17 10:57, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

 Title   : Special-Use Domain Names Problem Statement
 Authors : Ted Lemon
   Ralph Droms
   Warren Kumari
Filename: draft-ietf-dnsop-sutld-ps-04.txt
Pages   : 27
Date: 2017-05-15

Abstract:
The Special-Use Domain Names IANA registry policy defined in RFC 6761
has been shown through experience to present unanticipated
challenges.  This memo presents a list, intended to be comprehensive,
of the problems that have been identified.  In addition it reviews
the history of Domain Names and summarizes current IETF publications
and some publications from other organizations relating to Special-
Use Domain Names.


The use of the term 'meaning' in this document is problematic. Meaning 
is something that humans do, not machines. What I believe we're actually 
interested in is scoping and binding. How a name is scoped and what 
object it gets bound to, not what it means.


For example the text:
"Domain Names with unambiguous global meaning are preferable to
 Domain Names with local meaning which will be ambiguous.
 Nevertheless both globally-meaningful and locally-special names
 are in use and must be supported."

Should probably be changed to:
"Domain Names with unambiguous global bindings are preferable to
 Domain Names with local bindings which will be ambiguous.
 Nevertheless both globally-scoped and locally-scoped names
 are in use and must be supported."

This is more akin to how programming language designers discuss this 
subject.[1] I don't want to delve into the usage of 'meaning' in RFC 
2826 itself, but there are a couple other uses of 'meaning' in this I-D 
that I believe should be removed, and I am happy to send text if people 
agree.


I'm also worried that some readers of this document might interpret its 
use of 'global' or 'local' in a geographic sense, and not a scoping 
sense. But I don't know how to deal with this. Perhaps it's just a risk.


Thank you for all your hard work on this,
Andrew

[1] https://www.python.org/dev/peps/pep-0227/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt

[Andrew McConachie]

On 4/7/17 20:39, Paul Hoffman wrote:
(I'm surprised our philosophy-minded folks didn't answer this. I'll 
take a stab, acknowledging that I'm only a philosophy tourist.)


On 30 Mar 2017, at 13:41, Andrew McConachie wrote:

If a domain name is made up of labels, and labels are made up of 
octets, then can there be non-digital representations of domain names?


Yes. The octets in the labels can be encoded into writing systems, and 
there can be a commonly-recognized display format for the 
representation of a group of labels.


For example, if I spray paint 'www.example' on the side of a bus, is 
it not a domain name because it is made up of paint instead of octets?


It is a rendering (in paint, on a bus) a domain name in a 
commonly-accepted display format. Neither the paint nor the bus is the 
domain name.


Some history related to representation versus essence: 
https://essenceofbuddhism.wordpress.com/2016/04/19/what-the-finger-pointing-to-the-moon-analogy-really-means-from-zen-buddhism-the-buddha-in-the-shurangama-sutra/

/Ceci n'est pas une pipe./

If I understand correctly this definition of domain name incorporates 
actual pipes and explicitly not paintings of pipes. Since the draft says 
a domain name is essentially octets, and only octets, any representation 
of domain names not composed of octets is just a representation, not an 
actual domain name.


I don't believe that's how the term is used in common parlance, but I 
can see how that definition works for this document. Thanks for the 
clarification!


--Andrew

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt

[Andrew McConachie]

On 3/13/17 10:59, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

 Title   : DNS Terminology
 Authors : Paul Hoffman
   Andrew Sullivan
   Kazunori Fujiwara
Filename: draft-ietf-dnsop-terminology-bis-05.txt
Pages   : 35
Date: 2017-03-13

Abstract:
The DNS is defined in literally dozens of different RFCs.  The
terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined.  This document gives current
definitions for many of the terms used in the DNS in a single
document.

This document will be the successor to RFC 7719.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-05


If a domain name is made up of labels, and labels are made up of octets, 
then can there be non-digital representations of domain names? For 
example, if I spray paint 'www.example' on the side of a bus, is it not 
a domain name because it is made up of paint instead of octets?


I don't see anything in this document restricting the terms to 'on the 
wire' definitions. So I assume that the scope of 'domain name' includes 
non-digital instantiations. Perhaps what's needed isn't so much a new 
definition for label, but clarification on the scope of these terms and 
their definitions.


Thanks,
Andrew


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