Re: [DNSOP] [Ext] QNAME minimization is bad

[David Conrad]

Paul,

On Nov 10, 2023, at 11:06 PM, Paul Hoffman  wrote:
>> On Nov 10, 2023, at 11:55 AM, John Levine  wrote:
>>> DNSBLs have been around a lot longer than QNAME minimization.
>> Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a 
>> predominant use of the DNS.
> DNSBLs are one of the biggest use cases for the DNS outside of "find me the 
> host". They are one of the primary reasons your inbox is not drowning worse 
> in spam.

It’s odd that you feel a need to explain DNSBLs or their uses. I’d be surprised 
if anyone on this list is unaware of them.

Deployment of QNAME minimization had known impact on certain use cases that 
have been around even longer than DNSBLs but the desire for privacy overrode 
those concerns.  As such, I’m unsure why the age of DNSBLs as a technology is 
relevant.

>>> They work(ed) fine without minimization and I don't think it is reasonable
>>> to expect every mail system in the world to change their configuration
>>> to work around our performance bug.
>> I thought the point of QNAME minimization was to improve privacy.
> It is. Nothing in the John's proposal would reduce that, would it?

John characterized QNAME minimization as a way to “work around our performance 
bug”, which as you know was not the prime driver for the work. I said nothing 
about his proposal.

Regards,
-drc



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

Re: [DNSOP] QNAME minimization is bad

[David Conrad]

John,

On Nov 10, 2023, at 11:55 AM, John Levine  wrote:
> DNSBLs have been around a lot longer than QNAME minimization.

Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a 
predominant use of the DNS.

> They
> work(ed) fine without minimization and I don't think it is reasonable
> to expect every mail system in the world to change their configuration
> to work around our performance bug.

I thought the point of QNAME minimization was to improve privacy.

Regards,
-drc



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

Re: [DNSOP] New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[David Conrad]

On Oct 9, 2023, at 5:34 PM, Paul Wouters  wrote:
> On Oct 9, 2023, at 10:02, Ben Schwartz  > wrote:
>> 
>> 
>> This is fun to think about, but it seems to me that these networks should 
>> avoid any reliance on the ICANN DNS tree.  I doubt that any network of space 
>> probes on Io can accept the risk of a technical or governance issue on .io.
>> 
>> Regardless, I think the draft would more helpful if drawn from real-world(s) 
>> systems, rather than speculating about architectures that might apply in 
>> some distant hypothetical scenario.
> 
> I agree. UUCP seems a better fit here, with DNS resolving happening on the 
> earthly receiver side 

I’m reminded of https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep...

Regards,
-drc



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

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[David Conrad]

Joe,

On Sep 19, 2023, at 2:45 PM, Joe Abley  wrote:
>>> Domain names existed before the DNS
>> Well, hostnames did.  Not sure domain names did, at least using that term.
> All hostnames are domain names, right?

Well yes, in the sense that domain names were a scalability extension of 
hostnames. However, in reviewing the ancient tomes (specifically, 
https://datatracker.ietf.org/doc/html/rfc805), I was wrong: it looks like 
domain names did, in fact, precede the specification/implementation of the DNS 
protocol, at least in concept. Mea culpa.

>>> I am not convinced that the term "domain name space" has any real currency,
>> Not sure what you mean by this.
> The word "namespace" is used in a general sense all the time. The phrase 
> "domain name" is used all the time. I don't remember hearing anybody use the 
> phrase "domain name space" ever, never mind recently, so I wonder whether it 
> is a term that is really in common usage. That's what I meant by "has real 
> currency".

Googling ‘domain “name space”’ resulted in 318,000 results, ‘domain namespace’ 
resulted in 33,100,000. YMMV.

>>> or that there's a useful distinction between that and "domain names”.
>> The distinction is that names resolvable via the DNS is a subset of all 
>> possible names within the domain namespace.
> I can see how it could mean that, it we decided to define it to mean 
> something.

My (likely faulty) recollection was that the term “domain namespace” was used 
during the discussions of SUDNs, i.e., SUDNs were names within the domain 
namespace that were NOT resolvable via the DNS protocol.

Regards,
-drc



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

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[David Conrad]

Joe,

On Sep 19, 2023, at 8:32 AM, Joe Abley  wrote:
>> I think we need to clearly separate the definition of a domain name with
>> the 'domain name space'. A domain name is just a sequence of labels,
>> and is a concept that exists independent of the tree structured namespace
>> of the global DNS (or any private DNS namespace for that matter).
> 
> Domain names existed before the DNS

Well, hostnames did.  Not sure domain names did, at least using that term.

> and are also used by other name resolution protocols than the DNS.

Yes.

> I am not convinced that the term "domain name space" has any real currency,

Not sure what you mean by this.

> or that there's a useful distinction between that and "domain names”.

The distinction is that names resolvable via the DNS is a subset of all 
possible names within the domain namespace.

> Some domain names are resolvable using the DNS protocol. Others are not. I'm 
> not sure it needs to be more complicated than that.

I agree that there’s no need to make it overly complicated, but it seems clear 
(e.g., the existence of the SUDN registry) that the distinction is both useful 
and necessary.

> I agree that a definition of a domain name as an ordered sequence of labels 
> is probably better than references to graph theory, which I think most people 
> (including me) think they know more about than they actually do.

+1.

Regards,
-drc



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[David Conrad]

Mark,

On Jul 17, 2023, at 4:23 PM, Mark Andrews  wrote:
>> Joe is (correctly, IMHO) pointing out that given there is a need to support 
>> TCP-based DNS queries (see RFC 7766), prudent engineering would suggest you 
>> need to prepare for attacks against that infrastructure. As such arguing 
>> “state has mass” appears to miss the point.
> And most servers will never see a DoS attack.

And most servers (particularly the ones that wouldn’t see a DoS attack) 
wouldn’t notice the strain of TCP-based DNS requests. So?

> TCP also puts much more load on recursive servers.  It slows down the 
> resolution process.  DOT and DOH put even more load on recursive and 
> authoritative servers.

Again, missing the point, unless you believe there are going to be fewer 
TCP-based DNS queries over time and RFC 7766 should be deprecated.

Engineering to how the Internet was in the past may not be an optimal strategy.

Regards,
-drc



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[David Conrad]

Paul,

On Jul 17, 2023, at 12:52 PM, Paul Vixie  
wrote:
>> If the stability of anybody's infrastructure depends on people choosing a 
>> particular transport, I would suggest they might have reason to be worried. 
>> Simply hoping that people don't start using TCP in a significant way is 
>> putting your stability in a lot of other peoples' hands.
> also -1. state has mass. avoiding it will remain worthwhile.


“Please Friendly Malicious Actor, do not send too many TCP DNS requests as it 
might overwhelm my infrastructure”?

Joe is (correctly, IMHO) pointing out that given there is a need to support 
TCP-based DNS queries (see RFC 7766), prudent engineering would suggest you 
need to prepare for attacks against that infrastructure. As such arguing “state 
has mass” appears to miss the point.

Regards,
-drc



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

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

[David Conrad]

Rob,

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.)

As I’m sure both Harald and Warren can attest, ICANN processes, particularly 
those for which a public consensus statement is the desired outcome, tend to 
take a teensy bit longer than 4 weeks. Also, given how long it has taken to get 
the -alt-tld draft out the door of IETF processes, 4 weeks might be seen as a 
bit hypocritical.

What’s the desired outcome here? The only possible outcome I can imagine that 
could come from a 4 week notice period would be for individual entities who 
happen to participate in/around ICANN to provide feedback, not for “ICANN” 
(whichever facet you might be envisioning) to comment. Is that sufficient?

Regards,
-drc

> On Mar 7, 2023, at 10:09 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> Hi,
> 
> I wanted to thank the WG, chairs, and authors, for their work and patience 
> with me on the alt-tld draft and to let the WG know of the next steps.
> 
> Warren and Paul have posted an updated -22 version that addresses my AD 
> review comments, and hence I will start a 4-week IETF LC on this version 
> shortly (i.e., hopefully in the next couple of days - as soon as the liaison 
> statement is good to go).
> 
> Wes, Mirja, and the DNSOP chairs, and Harald have helped me craft a liaison 
> statement to send to ICANN once the LC has started (which will be sent from 
> OPS Area) informing them of the progress of this document, hence also 
> providing an opportunity for comments via the standard IETF LC process.  The 
> extended 4-week IETF LC is to ensure that ICANN have enough time to review 
> the document and provide any feedback that they may have.
> 
> My hope, and expectation, is that the document will then following the 
> standard IETF document approval and publication process.
> 
> Regards,
> Rob
> 
> ___
> 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-19

[David Conrad]

Hi,

On Dec 14, 2022, at 9:33 AM, Jim Reid  wrote:
> If these principles apply, why is the IETF bothering with .alt at all?

My impression has been the primary intent is to ensure .ALT is not allocated 
for DNS use and secondarily, to try to curtail future discussions of this topic.

FWIW, if my impression is accurate, I’m confident the former will be successful 
(I’m sure the next round of gTLDs will disallow any strings the IETF comes up 
with, among others) but am less confident about the latter.

Regards,
-drc



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

[DNSOP] "Moving .INT" (was Re: [Ext] root crud, Possible alt-tld last call?)

[David Conrad]

George,

This is unrelated to alt-tld, but just as a point of clarification:

On Oct 25, 2022, at 5:17 PM, George Michaelson  wrote:
> Just because we're punting ALT into their process, and moving .INT into their 
> process […]

I presume you’re talking about 
https://datatracker.ietf.org/doc/draft-davies-int-historic/ 
.  I’m unsure why 
you think .INT is moving. Kim can correct me if I’m wrong, but to clarify, the 
processing of .INT is not moving: it is and always has been handled by the IANA 
team and it will continue that way.  The only thing that is changing is 
removing the historical “international databases” delegations created when .INT 
was (according to RFC 1591) for “organizations established by international 
treaties, _or international databases_” (Emphasis added). The IAB doc from 
2000(!) 
https://web.archive.org/web/20090822012543/http://www.iab.org/documents/docs/iab-arpa-stmt.txt
 

 (didn’t bother trying to find it on the IAB website — the link on Wikipedia is 
wrong) might be illuminating.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Wes,

Mumble. I said I wasn’t going to argue the politics further, but…

On Oct 24, 2022, at 10:49 AM, Wes Hardaker  wrote:
> David Conrad  writes:
>>whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> So, the
> decision made at the time was: once the WG has concluded that something
> is a good idea (a draft passes WG last call), *then* it seems like the
> right time to send a message to ICANN about our plans.

There are really 2 questions here, the second dependent on the first:

1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory; and 
(if not)
2) whether .alt is a good label to reserve.

It makes perfect sense to me to ask the second question after WG LC.  Not 
getting resolution on the first question means the risk of wasting everybody’s 
time if the answer to that question turns out to be “yes.”  Another formulation 
for the first question could be “How or by what process can the IETF and ICANN 
work together to further partition the domain name namespace to meet bona fide 
technical use cases that weren’t envisioned under the ICANN generic TLD model?” 
 The IETF/IAB “sending a message” stating “we’re going to do this, do you have 
any comment” never stuck me as a particularly healthy way to interact.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Libor,

On Oct 24, 2022, at 9:11 AM, libor.peltan  wrote:
>> The root of the DNS is a commons, supported by volunteers who are paying out 
>> of their own pocket to provision a global infrastructure. I’m personally not 
>> comfortable recommending techniques that can add undefined (could be 
>> minimal, might not be: no one knows for sure) load to that infrastructure.
> Well, the modern and well-configured resolvers will protect Root servers by 
> employing Aggresive Negative Caching or Root Zone Prefetch (and eventually 
> Query Name Minimisation for the sake of querier's privacy); outdated and 
> broken resolvers will keep bombing the root's auths with junk queries even if 
> we declare they MUST NOT. As a consequence, those arguments for this "MUST 
> NOT" are moot.

We appear to be arguing about wording/capitalization.

Obviously, simply saying “MUST NOT” in an RFC will have (and has always had) 
zero effect on code behaviors. What matters is what people actually implement. 
If a modern/well-configured iterative resolver/forwarder implements according 
to (the potential future) spec (either “MUST NOT” or “should not”), then all 
queries for .alt sent by outdated/broken stub resolvers will not bomb the root 
as soon as the modern code is deployed.  As applications/operating systems get 
updated over time, even the stub resolvers could behave better.  However, 
implementation of code is all about priorities. I personally believe that, in 
general, a spec that says “MUST NOT” has a slightly higher likelihood of being 
prioritized over a spec that says “should not” but maybe that’s just me.

The real point here is #3 in the list I provided earlier:

"3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues."

Using the AS112 project approach could help address the leakage to the root 
issue (even for outdated/broken resolvers), although it wouldn’t generally 
address the privacy leakage issue. It also has its own implications (e.g., 
delegating an explicitly non-DNS TLD in the DNS). Given the AS112 approach 
doesn’t result in code change, would you be ok with using it with .alt?

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 24, 2022, at 2:13 AM, Rob Wilton (rwilton)  wrote:
>> whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison 
> discuss this.  My current expectation is that we probably will send ICANN a 
> liaison to politely let them know what we are doing, so that they have the 
> opportunity to comment, and we would consider any feedback that they give, 
> returning the document back to the WG, if needed.

I guess that’s marginally better than what the IETF did with RFC 6762 (i.e., 
publish the RFC ‘reserving’ a TLD then, a year and a half later, issue the 
liaison statement to invite discussion). The reluctance to ask the question 
still seems silly to me, particularly if one wishes to maintain good relations, 
but this is clearly deep into the political sphere so I won’t bother arguing 
further.

> If [identifying/dealing with leakage] is a general problem for “special use” 
> TLDs then it would be better to have a separate document that handles those 
> consistently and generically rather than creating a new rule specifically for 
> .alt domains.

I personally believe it is (and maybe Paul Vixie’s idea of using the 
prisoner.iana.org  approach is worth exploring).

> This is a reasonable point to consider, even though it also feels like the 
> world may end up moving to DoH, or DoQ fairly quickly.

I’ll admit skepticism.

> Personally, I think that it is somewhat hard for users to have that general 
> expectation if the name resolution is using a combination of name resolution 
> protocols (including unencrypted DNS).

I agree, however I thought the point of the Security Considerations section was 
to make implementors aware of potential security “gotchas” they or their users 
may experience as a result of implementation. Pointing out that regardless of 
what security/privacy assertions a new non-DNS name resolution system may make, 
unless both parties in communication are participating in that new system, 
security/privacy may be compromised seems like a useful “gotcha” to note.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 23, 2022, at 1:27 PM, Paul Hoffman  wrote:
>> 1) Ask the stupid question.
> Again? It has already been answered many times in the negative. There are 
> even RFCs about it. Asking it again is a waste of people's time.

I’m unaware. Could you point me to the ICANN Board resolution, statement from 
the GNSO, and/or a position from the ICANN CEO on the issue?

>> 2) A voluntary, lightweight registry operated by IANA can help developers 
>> avoid collision.
> True, if we care about collision in namespaces we don't control. I certainly 
> don't care about those namespaces.

OK, but others may. As a precedent: https://www.iana.org/time-zones 
.

>> 3) Identifying leakage to the DNS as a protocol violation can, over time, 
>> help reduce that leakage.
> True, but so what? It is leakage from namespaces we don't control, and 
> many/most of us don't care about them.

I would’ve thought we'd care about (and try to discourage) the leakage into the 
DNS as a result of IETF action.

>> The root of the DNS is a commons, supported by volunteers who are paying out 
>> of their own pocket to provision a global infrastructure. I’m personally not 
>> comfortable recommending techniques that can add undefined (could be 
>> minimal, might not be: no one knows for sure) load to that infrastructure.
> I'm personally happy to defer this to those volunteers instead of speaking 
> for them.

OK. Could you point me to the statement by the RSOs on the topic?

> In the past, they have said that the amount of leakage is not of concern to 
> them, and there is no indication that .alt will increase it perceptibly.

Given the root server infrastructure is shared across the entire Internet 
globally, in the past, the DNS operational community has gone to significant 
efforts in relation to proposed changes that could conceivably affect the load 
on the root servers, e.g., deploying IPv6 or DURZ, even when there was no 
assurance or even a common belief that there would be a perceptible negative 
impact.

But this is somewhat irrelevant: what we’re talking about here is specific 
wording that tries to more strongly discourage traffic going to the root, i.e., 
'MUST NOT’ instead of ‘should not’. I’m confused why such wording would be 
considered controversial.

> I can't tell from this paragraph if you realize that the example you gave 
> (.local) already has a SHOULD NOT for resolvers.

Yep, I’m aware.  I don’t think repeating mistakes is a good idea.

> Are you saying that updating RFC 6762 to make it a MUST NOT would have any 
> noticeable effect?

Are you saying you think it would hurt?  I’m hopeful in the long term, it would 
have a positive impact.

>> It seems obvious to me that if a namespace is explicitly defined to not be 
>> in the DNS, embedding a reliance on the DNS would be a protocol violation.  
>> I am actually surprised that this would be controversial.
> Can you say what you mean by "reliance on the DNS"? Defining .alt as a name 
> that won't appear in the root zone does not have any reliance on the DNS.

For applications that are misconfigured, instead of blocking at the resolver, 
you appear to be arguing queries should use the DNS protocol to query the root 
servers to (presumably) return an NXDOMAIN. I consider this a protocol 
violation, and as such, I think it appropriate to use language that suggests 
implementors must not do that.

>>> And as for the eavesdropping concern, doesn't this equally apply for all 
>>> domain lookups, particularly invalid ones?
>> As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
>> resolution protocol is specified to not be plain text (presumably any new 
>> protocol would be encrypted), then users of that protocol have an 
>> expectation that their queries are protected.
> Why on earth would those users think that?

E.g., "GNS is a decentralized and censorship-resistant domain name resolution 
protocol that provides a *privacy-enhancing* alternative to the Domain Name 
System (DNS) protocols.” (second sentence of the abstract of 
https://lsd.gnunet.org/lsd0001/ , emphasis 
added).  Now, what happens on a machine that is unaware of GNS responds to 
(say) an email from paul@secret_name.alt  (and if 
you don’t think that’s a privacy violation, then what’s the point of DoH/DoT)?

> If the proponents of the non-DNS name resolution protocol suggest that to 
> them, then those proponents are simply lying.


Or, more charitably, they are making an assumption about the environment in 
which the non-DNS name resolution protocol operates.  Pointing this out in the 
Security Considerations section seems like a no-brainer to me.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton)  wrote:
> As I read it, the partitioning of the domain name namespace is really to 
> achieve two aims:


On this mailing list, I think there is a pretty good understanding of the 
intent of .alt and I don’t think there is much in the way of disagreement on 
that intent. As far as I can tell, the points of contention are:

1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name resolution 
systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues.

FWIW, my views:

1) Ask the stupid question.
2) A voluntary, lightweight registry operated by IANA can help developers avoid 
collision.
3) Identifying leakage to the DNS as a protocol violation can, over time, help 
reduce that leakage.

> This is outside my area of expertise, but I'm not convinced that the global 
> DNS would see any significant increase in load, because the stub resolver 
> would generally not be sending the requests to the DNS assuming that they are 
> valid domains, and if they are not valid domains then that would seem to be 
> the same as what DNS already handles today.

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

If you look at the ICANN OCTO web page Paul referenced earlier 
(https://magnitude.research.icann.org ) 
and filter for “special use” TLDs, you’ll see data related to the number of 
queries received.  Some of those (e.g., .local) are non-trivial and, in my 
opinion, are indications of brokenness that should be fixed — the root 
shouldn’t be seeing those queries. My suggestion of using RFC 2119 “MUST NOT” 
language (i.e., queries for names in .alt MUST NOT be sent to the root server 
system supported by IANA) is in an effort to discourage an increase in that 
query volume over time.

It seems obvious to me that if a namespace is explicitly defined to not be in 
the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
actually surprised that this would be controversial.

> And as for the eavesdropping concern, doesn't this equally apply for all 
> domain lookups, particularly invalid ones?

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
resolution protocol is specified to not be plain text (presumably any new 
protocol would be encrypted), then users of that protocol have an expectation 
that their queries are protected.  By falling back to DNS, that expectation is 
silently violated.

Regards,
-drc



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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[David Conrad]

Suzanne,

On Oct 23, 2022, at 3:50 AM, Suzanne Woolf  wrote:
> We've been told repeatedly that no one wants to engage legal analysis or 
> liaison communications on a document that doesn't have WG consensus.

This appears broken.

In this specific case, the way forward appears to be predicated on the response 
to the analysis/communication.  That is, if ICANN is asked “would ‘reserving’ 
.alt (or any other TLD) represent an intrusion into ICANN’s bailiwick” and the 
answer from ICANN is yes, then moving forward with .alt would be precluded, 
regardless of WG consensus, no?

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton)  wrote:
> If this was a MUST NOT, then at the point that the RFC is published, would 
> that not mean that all DNS stub (and maybe recursive) resolvers immediately 
> become non complaint with the new standard?

The draft says “Informational”.  It is (maybe) recommending the partitioning of 
the domain name namespace, explicitly creating a sub-space that is for non-DNS 
use.  It makes no sense to me to then pretend it’s "just fine” to issue DNS 
queries in that sub-namespace.

> My interpretation of Paul's comment is that nothing bad happens if a client 
> does attempt to resolve .alt names in the DNS because they will just fail in 
> the same way as any other domain that doesn't exist in the DNS, and that is 
> okay.

But it is not OK.  Yes, the root servers are surely provisioned to handle the 
additional load the use of .alt might create, but it adds to the useless noise 
— why would the IETF encourage this?  Worse, it exposes .alt traffic to 
potential eavesdroppers.  I’m confused why the IETF would publish an 
informational document that says both of those are not protocol violations.

> Possibly, the draft could have some text that allows stub resolves to filter 
> out DNS requests for .alt names if they wish.

The point is that DNS resolvers of any kind are explicitly not supposed to see 
.alt queries — .alt is NOT a DNS namespace.  If they do (and they obviously 
will), something is broken and should be fixed.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 21, 2022, at 3:34 PM, Paul Hoffman  wrote:
>> If the intent here is that .alt names should never be looked up via the DNS, 
>> then MUST NOT is the expected behavior, no?
> There is no such intent of the draft.

Ah.  Then I guess I don’t support the draft and the rest of my input is 
irrelevant.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

On Oct 21, 2022, at 3:48 PM, Tim Wicinski  wrote:
> Not putting any hat on, I do like Ben's https+alt:// URI suggestion.
> As a chair, if we see enough interest in this, the WG should find consensus

All the world is not a URI, e.g.,

% ping https://www.ietf.org
ping: cannot resolve https://www.ietf.org: Unknown host
%

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 21, 2022, at 1:46 PM, Paul Hoffman  wrote:
>> The document says domain names in .alt “should not” be looked up in a DNS 
>> context.  The whole point of .alt is that it isn’t to be used in the DNS 
>> context. Why is this not RFC 2119 “MUST NOT”?
> Because we cannot force applications or APIs to do anything.

This is true for all IETF protocols/specifications.  Are you arguing RFC 2119 
“MUST” is pointless?  As far as I understand, the point of 2119 language is to 
be explicit in expected behaviors, not to imply that the Internet Police will 
hunt you down if you violate them.  If the intent here is that .alt names 
should never be looked up via the DNS, then MUST NOT is the expected behavior, 
no?

> If they look up a .alt name in a DNS context, that's just fine, as long as 
> they want to get an NXDOMAIN.

No, it is not "just fine":
a) it leaks potentially sensitive information
b) it adds load to the root servers

> The draft says "should not" in two places: "should not be resolved using the 
> DNS protocol" and "should not attempt to be resolved using the global DNS". 
> Would it be clearer to say "will never be resolved in the global DNS" in both 
> places?

It is marginally clearer, but misses the point.  .alt is defining a technique 
by which a non-DNS name resolution system can make use of domain name syntax 
that applications expect.  Given that it is explicitly non-DNS, I feel the 
wording should be explicit in stating that the DNS protocol MUST NOT be used.

>> Section 2, paragraph 6:
>> 
>> “  If the non-DNS protocol has a wire format like the DNS wire format,
>>  it might append the null label at the end of the name, but it also
>>  might not.  This document does not make any suggestion for how non-
>>  DNS protocols deal with the wire format of their names.”
>> 
>> The sentence preceding the last is pointless. Just use the last sentence.
> 
> This was discussed earlier in the WG. The preceding paragraph is useful 
> because some readers of the draft forgot that there is a difference between 
> the DNS presentation format and wire format.

Sorry if I was unclear: I said “sentence preceding last", not paragraph.  
Simply saying “This document does not make any suggestion for how non-DNS 
protocols deal with the wire format of their names” is sufficient — you don’t 
need the “it can be X or not X” tautology.

>> Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or 
>> query the global DNS root name servers for names in .alt”?
> No, it shouldn't, unless you can say why resolvers and caching DNS servers 
> should treat .alt any differently than any of the other zillion popular 
> non-delegated TLD?

Because .alt is being set up to be for use in non-DNS contexts.  If not, then 
what is the point of this draft?

>> DNS server operators don’t register names.
> According to RFC 6761, they do, or at least they act like what a registry 
> does after it registers a name.

No.  RFC 6761, section 5.6 talks about configuring, not registering.  I believe 
what 6761 was getting at is whether or not the server should reject a name as a 
configuration error.  This is different than administratively rejecting a name 
for registration.  E.g., I can easily imagine a registrar creating a 
registration for the equivalent of ‘*.alt’ to block anyone from even bothering 
to register a .alt name by indicating it is already registered (as is hinted at 
in RFC 6761 section 5.7).

>> "Currently deployed projects and protocols using pseudo-TLDs are encouraged 
>> to move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
>> collision with TLDs allocated via ICANN processes or other future 
>> modifications to the global DNS root zone.”
> Because encouraging those parties seems pointless. They're gonna do what they 
> want to do regardless of what some RFC says.

Then what is the point of this draft?

>> Section 4:
>> 
>> There is no explanation as to why leakage will “undoubtedly occur" or why it 
>> represents a privacy consideration.
> 
> See the URL above for why leakage undoubtably occurs. Some such leakage will 
> include labels below the TLD that some might consider a privacy concern. 
> Further, leakage can be worse than just full names: if you paw through the 
> queries received by root server operators, you will see some queries that 
> contain full URLs as the QNAME.

This may surprise you, but I’m aware of why leakage occurs :).  My point was 
that the reader, i.e., someone implementing a non-DNS name resolution system, 
may need a bit more explanation as to why leakage happens and the privacy 
implications of that leakage.

>> AFAICT, the primary security consideration is that .alt name lookups can 
>> receive unanticipated or malicious responses due to incorrect mapping of the 
>> non-DNS name resolution system to the .alt pseudo-TLD.
> 
> Isn't that true for any TLD, pseudo or not?

If it is not a pseudo-TLD, presumably DNSSEC validation may be able to provide 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

> On Oct 21, 2022, at 10:34 AM, Paul Hoffman  wrote:
> Warren and I believe that the changes in draft-ietf-dnsop-alt-tld-18 meet all 
> of the concerns in the message that started this thread, and thus it is ready 
> for WG Last Call.

I disagree that the document is ready for WG Last Call.  I will try again:

Throughout the document:

The document says domain names in .alt “should not” be looked up in a DNS 
context.  The whole point of .alt is that it isn’t to be used in the DNS 
context. Why is this not RFC 2119 “MUST NOT”?

Section 1, paragraph 4:

Two of the quoted terms “Experimental Squatting Problem” and “Land Rush 
Problem” are NOT defined in RFC 8244 — those terms do not exist in RFC 8244.  
It would be helpful if those terms were defined.

Section 2, paragraph 3:

Namespaces aren’t actors. They can't "differentiate themselves".  Applications 
differentiate namespaces by the uniqueness of the label for each namespace 
(something the draft suggests but makes no provision for).

Section 2, paragraph 6:

“  If the non-DNS protocol has a wire format like the DNS wire format,
   it might append the null label at the end of the name, but it also
   might not.  This document does not make any suggestion for how non-
   DNS protocols deal with the wire format of their names.”

The sentence preceding the last is pointless. Just use the last sentence.

Section 2, paragraph 7:

“Caching DNS servers and authoritative 
DNS
   servers will treat all names in the .alt pseudo-TLD just as they
   would any other name whose TLD does not appear in the global DNS
   root.”

This guarantees the root will receive queries for .alt.  Shouldn’t it say 
“Resolvers and caching DNS servers MUST NOT forward or query the global DNS 
root name servers for names in .alt”?

Same paragraph:

“  DNS server operators and DNS registries/registrars for the
   global DNS will never register names in the .alt pseudo-TLD because
   .alt will not exist in the global DNS root.”

DNS server operators don’t register names.

Section 2, last paragraph:

“  Currently deployed projects and protocols that are using pseudo-TLDs
   may choose to move under the .alt pseudo-TLD, but this is not a
   requirement.  Rather, the .alt pseudo-TLD is being reserved so that
   current and future projects of a similar nature have a designated
   place to create alternative resolution namespaces that will not
   conflict with the regular DNS context."

Why not encourage movement and explain why, e.g.:

"Currently deployed projects and protocols using pseudo-TLDs are encouraged to 
move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
collision with TLDs allocated via ICANN processes or other future modifications 
to the global DNS root zone.”

Section 4:

There is no explanation as to why leakage will “undoubtedly occur" or why it 
represents a privacy consideration.

Section 5:

It is unclear what “re-use the chosen label” means or what “special host name” 
is being referenced. AFAICT, the primary security consideration is that .alt 
name lookups can receive unanticipated or malicious responses due to incorrect 
mapping of the non-DNS name resolution system to the .alt pseudo-TLD.

> We note that there are still some people who want a registry of some sort for 
> names that would appear under .alt, but it feels like the number of people 
> who want no registry is larger, and it also is clear that the people who want 
> a registry don't agree on the rules or location for that potential registry. 
> During WG Last Call, if there is a consensus (decided by the chairs, not the 
> authors) for one proposal for a registry, we can add it to the draft.

Without a registry, how is a non-DNS name resolution developer supposed to 
"choose a label that they expect to be unique”?

Regards,
-drc



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

Re: [DNSOP] Speculations Re: [EXTERNAL] Possible alt-tld last call?

[David Conrad]

Suzanne,

On Oct 18, 2022, at 6:50 AM, Suzanne Woolf  wrote:
> We don't know what ICANN considers an attempt to "wade into ICANN territory," 
> and there's nothing the WG can do to resolve this question.

I’m unsure the protocols here, but the WG could request the IAB to have the 
IETF Liaison to the ICANN Board inquire as to whether the proposed reservation 
of .alt would be “an attempt to ‘wade into ICANN territory’”, no?  Speaking 
personally, I think it’d be nice if there could be a definitive statement by 
ICANN on this question.

> It would be helpful if we could focus on technical/operational impacts and on 
> whether .alt would in fact solve the problems that the draft claims to 
> address.

OK. I’m assuming the "problems that the draft claims to address” (since there 
isn’t an explicit problem statement in alt-tld) are from the Introduction:

"The techniques in this document are primarily intended to address the 
"Experimental Squatting Problem", the "Land Rush Problem", and “Name 
Collisions" issues discussed in [RFC8244]”

Editorially, section 3 of RFC 8244 identifies 21 different problems and the 
terms “Experimental Squatting”, “Land Rush”, and “Name Collisions” are not 
explicitly referenced in that section (there is a  reference to name collisions 
in section 4, but it talks about ICANN’s name collision study). This forces the 
reader to interpolate which RFC 8244 problems are being referenced.  For 
clarity, it might be helpful to use the numbers in RFC 8244 (as I gather was 
the intent of numbering).

Anyhow…

On the “Experimental Squatting Problem”:

Personally, I’m skeptical as I don’t see a lot of incentives to use .alt over 
some “interesting” string that has not yet been delegated, particularly given 
the low rate of change via ICANN’s gTLD processes. There might even be some 
perverse incentives unrelated to reserving .alt, e.g., squat now and get market 
share so ICANN can’t delegate due to name collision avoidance, and then 
petition for ICANN to delegate the name to you at a later date.  However, 
empirically, since GNS appears to be willing to migrate over, perhaps I’m 
overly cynical.

On the “Land Rush Problem”:

As this isn’t referenced (AFICT) in RFC 8244, I’m guessing this is when lots of 
people rush in to obtain domains either for squatting purposes, to prevent 
squatting, or “investment”. I gather the intent of registry restrictions as 
specified is to limit who can use .alt names, but I’m not sure that’s going to 
work as intended.  Specifically, section 3 of alt-tld states:

'Entry to the registry is a combination of "Specification Required” and either 
"Expert Review" or "IESG Approval".  See [RFC8126] for the definition of these 
three terms,'

(Nit: line ends with a comma.) If the goal is to encourage folks to move over 
to .alt from the root, I suspect the entry requirements are too much. I’d 
imagine any sort of requirement is going to create friction and reduce the 
likelihood folks will bother to move. As such, I might suggest a lighter weight 
registration process (maybe just “Expert Review”?). However, the draft states 
.alt is an unmanaged space, so I’m not sure I understand what the registry 
entry restrictions are going to look at (maybe just to avoid collision?).

On the “Name Collisions Problem”:

Section 2 of alt-tld states:

"Alternative namespaces should differentiate themselves from other alternative 
namespaces by choosing a name and using it in the label position just before 
the .alt pseudo-TLD.”

and later:

“[Groups wishing to create new alternative namespaces] should attempt to choose 
a label that they expect to be unique among similar groups and, ideally, 
descriptive. Developers are wholly responsible for dealing with any collisions 
that may occur under .alt."

The phrasing here is odd in that a namespace can’t differentiate itself from 
anything, rather applications need to be able to differentiate behaviors based 
on the (sub-)namespace created by .ALT. The implication of this statement is 
that some mechanism must exist that allows an application to make the 
distinction. What this mechanism is appears to be left to the reader as an 
exercise. As such, I’d say that the alt-tld draft doesn't address “Name 
Collisions”, rather it provides a way in which name collisions _at the root of 
the DNS_ can be avoided, but it explicitly moves that problem to a non-DNS 
context underneath .ALT.

One other comment, as a nit, section 2 of alt-tld stats:

"Because names beneath .alt are in an alternative namespace, they have no 
significance in the regular DNS context.”

Presumably, the DNS significance of .alt is that it MUST NOT be looked up in 
the DNS and/or ICANN MUST NOT delegate .ALT in the DNS.  The latter is probably 
implementable (assuming ICANN agrees, which I imagine they would). The former, 
pragmatically speaking, not.

Regards,
-drc


signature.asc
Description: Message signed with OpenPGP
___

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

[David Conrad]

Hi,

On Aug 23, 2022, at 4:18 AM, Schanzenbach, Martin  
wrote:
>> IMHO, if you want to be in a carve-out of the domain name space, you still 
>> need to play by the domain name space's technical rules, in a way that's 
>> backwards compatible with systems that don't know about the carve-out and 
>> will assume that veryverylonglabel.foo.alt _is_ a domain name.

Just to be clear, it IS a domain name.  The magic terminal label “.alt” merely 
indicates (to applications that are aware) that the FQDN is not supposed to be 
submitted to the DNS for resolution.

> I think the notion that there is strict "format" of a name and that if it is 
> not in that format is not actually part of the same namespace is already 
> behind us.

Not as long as there are operating systems and applications that assume that a 
domain name is, well, a domain name.

> If that were the case then we do not need .alt at all.
> For example, GNS names are UTF-8. They are not LDH or any kind of 
> DNS-compliant wire format.

You are mixing domain names, host names, and names to be resolved via the DNS 
together.

If you want to create a GNS namespace that doesn’t "look like”, that is, 
interpreted by a users, application, or operating system as a domain name 
(e.g., フォオ:GNS), there is no need to discuss this within the context of DNSOP 
(or maybe even the IETF).

As far as I know, that’s not what is being discussed here.  The idea is that 
there is a "cut out” of the domain name namespace that will help users, 
applications, and operating systems to know that a particular partition of the 
domain name space is NOT to be resolved via the DNS, rather (if the last labels 
of the domain name are “gns” followed by “alt”) it is to be resolved via GNS.

The key part is that it is a partition of the _domain name_ namespace.

The question of LDH or UTF-8 is orthogonal.  UTF-8 or random binary gibberish 
are perfectly acceptable within the domain name namespace.  It is NOT 
acceptable for a “host name”, which is the subset of domain names used to 
identify hosts resolved via the DNS.  Whether or not random binary gibberish is 
acceptable to end users is a separate question.

> I think one way to look at is is that we try to solve a problem with the 
> display/presentation of names in alternate name systems and how they can be 
> confused by applications but also humans with DNS names.

Yes.

> Applications (to some degree) have to deal with malformed names anyway as 
> part of the user input handling.
> If they consider the given .alt-name malformed because they only expect DNS 
> names, then that is within the expected behaviour.

Of course, the vast majority of applications don’t try to parse the domain 
name. They take argv[n] and blindly throw it to gethostbyname() or whatever and 
if that routine returns an error, the application exits.

> If the application crashes because of such a name, it would also crash 
> because of data corruption or faulty user input.
> And that is a bug in the application, possibly even a security issue if it 
> leads to a buffer overflow etc.

IIRC, the whole creation of punycode and IDNA was because of concerns that the 
use of UTF-8 in a host name context was going to break applications. I’m 
intrigued that these concerns are now just hand-waved away.

Regards,
-drc



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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 15, 2022, at 7:07 PM, Stephen Farrell  
wrote:On 16/08/2022 03:01, John Levine wrote:
>> Right. If it's FCFS, I am sure I am not the only person who will be
>> waiting at the gate with thousands of preemptive registrations.
> Why?

Because they believe (or are convinced) there is or will be profit in it. My 
experience has been that the majority of folks who are getting Unstoppable 
Domains TLDs haven’t the slightest clue what they are or why they’re not 
particularly useful.  And they’re paying actual money, not merely (say) copying 
a document and changing a few words or wading through mind-numbing technical 
process. They are speculators and if the cost of obtaining the “asset” is below 
what the projected/potential value may be, then they’ll “invest”.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 15, 2022, at 1:22 PM, Paul Wouters  wrote:
> I guess we could prevent draft--alt-name-cocacola if we consult the Trademark 
> Clearing House,

https://tmsearch.uspto.gov/bin/showfield?f=doc=4806:y9m1tz.2.21 
 :)

> but maybe this is a clear signal that we
> are turning the IETF into ICANN and it is time to take a step^Wleap
> back.

My impression is that some folks here believe that the demand for non-DNS 
namespace partitioning won’t be that great, thus a lightweight IETF-managed 
mechanism will be sufficient.  Perhaps I’ve been in the ICANN world too long, 
seen far too much gaming, and far, far too many lawsuits resulting in me having 
a different view: I’m not so confident that a lightweight mechanism will 
survive, particularly given stuff like 
https://techcrunch.com/2022/07/27/web3-digital-identity-startup-unstoppable-domains-raises-funds-at-1-billion-valuation/
 
.

ICANN was specifically intended to be a venue in which naming policy was to be 
made and was explicitly required to include non-technical constituencies 
because the myriad non-technical implications of that policy. The fact that the 
ICANN process did not take this particular use case into account suggests to me 
that that process needs to be fixed, not that the IETF should put itself into 
the same swamp by providing a way by which that process can be short-circuited.

But I’m repeating myself, so I’ll shut up now.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 15, 2022, at 10:14 AM, Ray Bellis  wrote:
> STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire protocols 
> for interrogating that system, mostly surplanting the use of host files.
> 
> On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name System" 
> namespace from the STD-13 one embodied in the ICANN-managed root zone that we 
> have now.  I think they're the same thing.

Exactly.  I’ve tried to ignore the “but hostnames existed before the DNS” 
argument because it’s simply irrelevant — users and applications understand 
there is a single namespace, known as the “domain name” namespace. There are 
partitions of that namespace (see RFC 6761 and 7686) that may or may not be 
resolvable via the DNS, but they all exist within the “domain name” namespace.

In my view, ICANN was established, in part, to deal with the issues involved in 
creating those partitions. I believe the real problem here is that the model of 
operation assumed by the ICANN processes didn’t account for particular corner 
case uses of the namespace. I remain unconvinced that the IETF providing a 
short circuit for that process is the right solution.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Eliot,

On Aug 15, 2022, at 7:41 AM, Eliot Lear  wrote:
> What I like about .alt (or whatever we end up calling it) is that it requires 
> a single or small number of changes, not one change per name space.

It creates a new namespace (*.alt), presumably one that is less contentious 
than the root.  The allocation policy for names in that sub-namespace is 
undefined at this point.  There is an implicit assumption that all the 
unpleasantness that has resulted in the current ICANN process won’t be visited 
upon that sub-namespace.  That’s probably true as there doesn’t seem to be a 
lot of incentive to use .alt (other than ‘for the good of the Internet’).

> That will help reduce leakage.

Leakage occurs because underlying systems are unaware of special handling 
requirements for a particular name. I believe the assumption is that all 
resolvers (of all kinds) will be aware that they should not forward a name 
ending with .alt to the DNS. This is a hard problem at Internet scale. As with 
.local, I’ll be surprised if declaring .alt a SUDN will have much impact on the 
amount of leakage.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 15, 2022, at 6:46 AM, Stephen Farrell  wrote:
> On 15/08/2022 06:09, Christian Huitema wrote:
>> .onion is barely visible, with 0.01% of root traffic.
> So that should be significant for the disposition of the GNU stuff, shouldn't 
> it?

No.

> My impression is that there'd be maybe an order of magnitude fewer clients.

This is irrelevant.

We have no idea whether GNS will take off in popularity or fade away into 
non-existence. Given the way "configuration is forever”, any partitioning of 
the namespace will be a feature for the foreseeable future.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 14, 2022, at 3:54 PM, Stephen Farrell  wrote:
> On 14/08/2022 23:37, David Conrad wrote:
>> It seems to me that “the correct handling” of how an operating system or an 
>> application distinguishes what protocol to use for domain name lookup (other 
>> than DNS) is outside of the bailiwick of DNSOP or the IETF.
> Disagree in part. I think it is entirely within the balliwick of the IETF to 
> document that e.g. gnu.alt. or gnu. is a SUDN.

Ah.  Well, perhaps this time, after 20+ years, it’ll be possible to come up 
with something that works.

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 14, 2022, at 1:42 PM, Stephen Farrell  wrote:
> On 14/08/2022 19:32, David Conrad wrote:
>>> But, there are also what ought be almost purely technical parts,
>> Sorry to be dense, but what exactly are those technical parts,
>> specifically those that are relevant to DNSOP and/or the IETF?
> 
> It was the text right after the bit you quoted. In full:

> 
> > But, there are also what ought be almost purely technical
> > parts, and IMO the correct handling of such a niche thing
> > as a namespace the GNU people would like to use (without
> > DNS) is one of those technical discussions.


It seems to me that “the correct handling” of how an operating system or an 
application distinguishes what protocol to use for domain name lookup (other 
than DNS) is outside of the bailiwick of DNSOP or the IETF.

Or are you suggesting the DNS protocol be modified to deal with such "a niche 
thing” to facilitate transition? (Honest question: e.g., one could imagine the 
root servers “knowing” about SUDN and doing special things when they see 
queries for (mostly, except for the root query obviously) non-DNS resolution 
protocols and DNSOP may be a good place for that discussion).

Regards,
-drc



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 13, 2022, at 7:14 PM, Stephen Farrell  wrote:
> But, there are also what ought be almost purely technical parts,

Sorry to be dense, but what exactly are those technical parts, specifically 
those that are relevant to DNSOP and/or the IETF?

Thanks,
-drc




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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Paul,

On Aug 13, 2022, at 7:26 PM, Paul Vixie  wrote:
>> The problem is that every resolver implementation and deployment on the 
>> Internet, which assumes anything that looks like a domain name IS intended 
>> for the DNS, has to be modified to “do something different” when it sees 
>> that reservation and failure to do so mean the name is going to be looked up 
>> via the DNS.
> that's a problem for future innovators.

Just to be clear: you’re saying to carve out namespace and let some future 
innovators figure out how to not dump queries for that namespace to the DNS?  
If so, I’m not sure what innovation you’re talking about -- this appears to 
largely be a solved problem via nsswitch (or equivalent). The actual problem is 
figuring out how to actually do the carve out.

>> It didn’t block research into overloading the domain name namespace into 
>> protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, 
>> Butterfly, etc., all demonstrate), it made it unscalable because of 
>> conventions of operating system vendors and application developers and 
>> assumptions of users.
> if by unscalable you include the idea that if someone experiments with .XXX 
> they run the risk of having IANA later allocate that to some unique purpose, 
> then i agree with your use of that word.

No. By "unscalable" I mean that if you want to use that carve out, you have get 
every stub resolver and every iterative resolver/forwarder on the planet to 
understand that the specified namespace partition is not to be handled by the 
DNS. Failure to do on both sides of any given session means one party won’t be 
able to establish the connection and (typically) the losing party sending 
queries to the root. It might be worth noting that according to 
https://ithi.research.icann.org , .LOCAL, 
which shouldn’t be seen at the root, appears to account for 7% of all queries 
to the root.

As for the concern you describe, the folks at IANA aren’t idiots and ICANN has 
already demonstrated (arguably over-) sensitivity to avoiding name collisions 
(see CORP, MAIL, and HOME). I suspect future name collision risk will be 
handled more or less the way it was handled in the last round, namely 
delegation won’t be done if the number of queries to the root for a particular 
label is above some arbitrary threshold.

>>> warren's .ALT proposal can begin to undo that harm. internet standards 
>>> should describe roads not walls. i am no fan of blockchain naming, but i'd 
>>> like those systems to reach the market rather than be prevented from doing 
>>> so.
>> Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
>> Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And 
>> you also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
>> address the markets they’re trying to address? I’m not against moving 
>> forward with .ALT, but I’ll admit some skepticism that it will work as 
>> intended: it feels to me that it’s more an exercise in “if you build it, 
>> they will come” but without James Earl Jones.
> i think GNU would use it. others can decide what to do. the worst case risk 
> is low, the best case benefit is high. so, to be clear, "yes".

Not suggesting Martin speaks for GNU, but excerpting 
https://mailarchive.ietf.org/arch/msg/dnsop/S1Up3rDLNZi5RWCcMf_kY1clByQ/ 


"tl;dr:
I am a bit ambivalent towards the ".alt" approach.
For alternative name systems that are specified with status
"Informational"  the use of ".alt" seems highly unattractive as there is
absolutely no benefit in using it but at the same time there are
(obvious) disadvantages especially compared to other name systems which
do not (try to) publish in the RFC series.”

I agree with his analysis.

>> As John Levine points out, this isn’t a technology issue: it is 
>> social/politica/economic/bureaucratic. ...
> i'm aware of legal matters which could pertain, but i am not IETF's lawyer so 
> will not seek to advise them.

Fair enough.  I just think it is perhaps inadvisable for DNSOP to promote a 
model that attempts to short circuit efforts the IETF undertook back in 2000 to 
avoid this particular swamp.

> what matters as an engineering question is that the domain name system camps 
> onto the whole of the domain-style / hierarchical / structure space of names, 
> and this was an error, and a carve-out is needed to facilitate innovation.


It seems to me the “engineering question” is largely out of the purview of the 
IETF — folks who need to engineer solutions are operating system vendors and 
resolver implementers to write the code to understand that some TLDs shouldn’t 
be sent to the root.  The real problem I see is how exactly the “carve out” is 
determined.  ICANN’s process to partition the namespace resulted in a 300+ page 
application guide and entailed payment of (at least) US$185,000.  

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Paul,

On Aug 13, 2022, at 3:32 PM, Paul Vixie  
wrote:
> i suggest that we adopt the technology "domain names (which is a concept that 
> precedes DNS itself)" whenever we are trying to talk about the name space as 
> distinct from the protocol.

Sorry, which technology are you suggesting we adopt?  Or did you get 
auto-corrected from “terminology”?

> ideally the domain name system would have left a carve-out for domain names 
> that were not expected to be served through the first such "domain name 
> system", but were rather reserved for future domain name systems.

The domain name namespace (labels separated by dots) is obviously agnostic to 
how it is implemented. The problem isn’t that parts of the namespace can’t be 
reserved: anything can be reserved for anything, regardless of protocol (see 
.ONION or .LOCAL).  The problem is that every resolver implementation and 
deployment on the Internet, which assumes anything that looks like a domain 
name IS intended for the DNS, has to be modified to “do something different” 
when it sees that reservation and failure to do so mean the name is going to be 
looked up via the DNS.

> by camping onto the whole of the domain name space, DNS (the domain name 
> system) has blocked research into new naming systems.

It didn’t block research into overloading the domain name namespace into 
protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, Butterfly, 
etc., all demonstrate), it made it unscalable because of conventions of 
operating system vendors and application developers and assumptions of users.

> warren's .ALT proposal can begin to undo that harm. internet standards should 
> describe roads not walls. i am no fan of blockchain naming, but i'd like 
> those systems to reach the market rather than be prevented from doing so.


Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And you 
also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
address the markets they’re trying to address? I’m not against moving forward 
with .ALT, but I’ll admit some skepticism that it will work as intended: it 
feels to me that it’s more an exercise in “if you build it, they will come” but 
without James Earl Jones.

As John Levine points out, this isn’t a technology issue: it is 
social/politica/economic/bureaucratic. Folks (understandably) want to leverage 
THE (singular) Internet’s namespace for fun or profit but existing processes at 
ICANN make this unappealing/impossible. As a result they (understandably) are 
looking to do an end run around those processes.  However, those processes were 
established by an entity outside of the IETF with a very different composition 
than that which participates in the IETF for very good reasons. If the IETF 
were to provide a way to bypass the ICANN processes (as Rubens points out, yet 
another beauty contest: yay), I’d be quite surprised if the myriad 
social/politica/economic/bureaucratic issues faced by ICANN wouldn’t come along 
for the ride. What’s the IETF’s legal budget again?

Regards,
-drc



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

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

[David Conrad]

Martin,

On Aug 4, 2022, at 12:01 PM, Schanzenbach, Martin  
wrote:
> But the resolution protocol is technology-neutral. I invite you to re-read 
> the draft. We are not proposing a namespace.

Right. If I understand correctly, you are proposing to use the existing domain 
name namespace, and that’s where the problem lies.

Because of the way applications have been written and users have been trained, 
there is precisely one global "domain name” namespace.  It is a series of 
labels separated by ‘.’s” at the presentation layer. As applications and end 
users cannot distinguish the underlying protocol by which names are resolved 
simply from the name, the fact that the protocol is “technology-neutral” 
(whatever that means) is irrelevant. Since the domain name namespace is 
hierarchical, there can be only one designated administrator for each branch of 
the global name space. Note that that administration can be centralized or 
decentralized, but if it is decentralized, it must be coordinated, i.e., the 
multiple authorities can’t just go off and partition the namespace by 
themselves and expect those partitions to have global uniqueness.

> The possibility for the user to modify local configurations is as benign as a 
> modification of /etc/hosts or Nsswitch.

Sure. And to what will those users/applications that do not modify /etc/hosts 
or use nsswitch, which will undoubtedly be the vast majority, send their 
queries?  And what happens when someone who “plays by the rules” and goes 
through the ICANN “global multi-stakeholder defined" process (e.g., the folks 
who obtained .pet) obtains the same portion of the domain name namespace you 
have chosen for GNS?

I believe (and I’m sure I’ll be corrected if I’m wrong) a major reason there is 
a moratorium on the process defined in RFC 6761 is because of a lack of clarity 
about who has authority over the administration of the single, global domain 
name namespace that you want to insert a name into. Some believe that authority 
is ICANN and others believe your usage would fall under “technical use” 
(whatever that means) and thus, be in the realm of the IETF. Complicating 
matters, the existing processes for TLD allocation at ICANN simply did not 
envision this particular usage and even if it did, the "new round”, known in 
ICANNland as “Subsequent Procedures”, is still (probably) years off.

The implication of all of this is the quagmire you find yourself in. In my 
view, you should be commended for trying to do “the right thing” but that 
doesn’t solve your problem. Pragmatically speaking, and to perhaps state the 
obvious, I see 4 options:

1) Wait for ICANN to fix their processes
2) Wait for the IETF to figure out whether/how to reopen the “Special Use 
Domains” registry
3) Try to bypass (1) and/or (2) by publishing through the ISE (I don’t know 
enough about the ISE process to guess whether this is appropriate or feasible)
4) Squat on a name like various other folks (Unstoppable Domains, Handshake, 
Butterfly, Namecoin, etc.) have done and hope (1) or (2) will happen and 
recognize the name you squatted on.

Did I miss anything?

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

[David Conrad]

Hi,

On Jul 29, 2022, at 12:53 AM, Petr Špaček  wrote:
> By any chance, do you remember in what iteration the DO=1 in query was 
> introduced?

Mid- to late 2000/early 2001, after the 2nd iteration (using Ed’s terminology), 
but before the third.

> I wonder what sort of disruption was anticipated/feared.

IIRC, there were some resolvers that reacted poorly to receiving unanticipated 
RRs in response to a “normal” query and there were some concerns about the 
amount of bandwidth signed authoritative servers would consume with useless 
information, particularly at the earliest stages of deployment (this was the 
early 2000s after all). The idea was for a resolver to signal its willingness 
to receive and process DNSSEC-related responses to as to avoid flooding 
DNSSEC-unaware resolvers with stuff they had no clue about.

> In hindsight is seems that DO=1 requirement for "new" behavior (like, say, 
> adding RRSIG to delegations sent from the parent zone) could be enough.

At some point, biting the bullet and introducing actual feature negotiation 
into DNS may be warranted...

Regards,
-drc


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

Re: [DNSOP] DNSSEC as a Best Current Practice

[David Conrad]

On Mar 21, 2022, at 1:01 AM, Masataka Ohta  
wrote:
> Paul Wouters wrote:
> 
>>>  Constructive thing to do to make DNS secure is to totally
>>> abandon DNSSEC and rely on DNS cookie or something like that.
> 
>> DNS cookies provide no data origin security, only a weak transport
>> security against non-onpath attackers.
> 
> If a resolver correctly knows an IP address of a nameserver of a
> parent zone and the resolver and the nameserver can communicate
> with long enough ID, the resolver can correctly know an IP
> address of a nameserver of a child zone, which is secure enough
> data origin security.

No.

https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/ 

https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/ 

Etc.

Securing the channel of communication != securing the data communicated via 
that channel.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
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

[David Conrad]

Hi,

On Apr 28, 2021, at 5:38 AM, Jim Reid  wrote:
>> On 28 Apr 2021, at 13:24, Roy Arends  wrote:
>> The working group can (after a potential clarification from the ISO about 
>> the future status of code elements) decide if a subset suffices and if so, 
>> the composition of the subset.
> 
> I agree with this approach.
> 
> IMO it’s reasonable for the WG to produce an RFC which says “If you need a 
> TLD for private use, pick from the two letter codes that ISO 3166 MA says 
> they’ll never allocate. Bear in mind if they later change their mind, you’ll 
> be on your own and could well be in a world of pain. Have a nice day.”.

I’d agree, with the slight modification of:

“…  if they later change their mind, you and any of the unmeasurable number of 
folks who happened to listen to ISO-3166/MA regarding the status of the user 
assigned codes will be on your own and could well be in a world of pain.”

(Only half :) — the reality is that lots of folks use the user assigned codes 
for all sorts of reasons and if they’re repurposed, it’s probably going to be a 
mess).

Regards,
-drc
(Speaking for myself)



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

Re: [DNSOP] [Ext] on private use TLDS

[David Conrad]

On Nov 28, 2019, at 2:29 PM, Doug Barton  wrote:
> On 11/28/19 2:15 PM, Paul Hoffman wrote:
>> On Nov 28, 2019, at 1:30 PM, Doug Barton  wrote:
>>> The IETF and ICANN share a sandbox on many topics, including the root zone. 
>>> (But of course you already knew that.) And if you don't think ICANN has 
>>> promised to not delegate HOME, CORP, and MAIL; you didn't read the 
>>> reference I provided. Or, if you did read it, and still have concerns, that 
>>> is that much more reason to work with them on a draft that memorializes it.
>> That document 
>> (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf)
>>  doesn't have such a promise. And, yes, I did read it. (Disclaimer: I also 
>> wrote it.)
> 
> Thanks for clarifying. All the more reason to codify it in a draft.

That’s been tried: 
https://tools.ietf.org/html/draft-chapin-additional-reserved-tlds-02

It failed.

Regards,
-drc
(Speaking for myself, not for any organization I may be affiliated with)



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

Re: [DNSOP] on private use TLDS

[David Conrad]

[Sorry for the slow response — US holidays and a resolution not to look at my 
computer over said holidays got in the way]

Doug,

On Nov 27, 2019, at 8:39 PM, Doug Barton  wrote:
> I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
> expressed that we should stay out of ISO's sandbox.

No one is suggesting we get into their sandbox.

> Whatever the rules are today, they can change, and poaching their stuff for 
> our purposes is bad form (and yes, I feel that poaching is what is being 
> proposed, in spite of the arguments to the contrary).

I’m confused. ISO 3166 says a set of codes are intended for user defined 
purposes. What is being proposed is using those codes for user defined 
purposes. How can this be construed as poaching?

> ICANN has already said that it's not going to ever delegate CORP, HOME, or 
> MAIL.

No, ICANN has not said that.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)




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

Re: [DNSOP] on private use TLDS

[David Conrad]

On Nov 26, 2019, at 12:52 PM, Ted Lemon  wrote:
> It might be worth clarifying what the actual scope of this proposal is.  I 
> think that the idea is to say “look, if you want to use a private name, these 
> names are known to be safe.”   It’s not to say “the IETF hereby declares that 
> the following names are safe,” but rather “the IETF is reporting that these 
> names have been declared safe by this other SDO.”
> 
> The point of making this recommendation is that we know that people will have 
> reasons to privately use domains that have not been allocated to them out of 
> the global namespace, and we’ve seen the problems that such private 
> allocations cause when they are done in an unsafe manner.  The advice here is 
> on how to avoid making that mistake.   It’s not a TLD allocation by IETF: 
> those TLDs are already effectively allocated.
> 
> Is that about right?

Exactly (at least from my perspective).

Regards,
-drc



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

Re: [DNSOP] On .ZZ

[David Conrad]

This whole discussion confuses me.

As Roy and Jaap have pointed out, ISO 3166 has indicated the user defined codes 
won’t be allocated.  They are for private use. Just as RFC 1918 has designated 
10/8 for private use.

To me, this means any of the user defined ISO codes are fair game for internal 
use (that is, between consenting adults), regardless of context, including use 
in the DNS.

My interpretation of this is that since ISO 3166/MA won’t be assigning those 
codes and it is wildly unlikely ccTLD policy will change such that IANA could 
delegate any of those codes, it makes the use of those 2-letter domains for 
private use wildly unlikely to result in a collision with public use (that is, 
delegation) since the domains can’t be delegated.

The advantages of this are:

1) no change in IANA policy
2) no need to rerun the fun of the RFC 6761 “discussions"
3) no need to do an ICANN PDP or some other undoubtedly painful process to 
reserve a string
4) no need for interminable arguments about language (“internal doesn’t mean 
anything in Klingon!”)
5) people can paint their bike shed any one of 42 colors

I don’t understand why one would need to pick ZZ (or any other user defined 
code) to mean by convention anything.  It doesn’t hurt anything, I just don’t 
see the point.

I would turn the question around:

Why not simply have an RFC that declares the user defined ISO 3166 codes as the 
RFC 1918-space equivalent for the DNS and be done with it?  If people _really_ 
want to continue the bike shedding on a particular string, they still can, but 
the folks who want a string (or strings) that they can use for internal 
purposes without fear of it being delegated in some future round of new gTLDs 
can just get on with their lives.

Confusedly,
-drc

P.S. Yes, I know people can use those 2 letter codes now, but having it 
explicitly stated in an RFC comforts some folks

> On Nov 22, 2019, at 4:23 PM, Bill Woodcock  wrote:
> 
> Man, sorry for the weird random capitalization, y’all.  Autocorrect has a 
> mind of its own.
> 
> Also, what Matt said: perhaps we could approach consensus if those in favor 
> of the proposal would articulate their thoughts on why specifying a 
> two-letter is the best solution to (this, any) problem, the rest of us might 
> be able to see why you feel your case is compelling.
> 
>-Bill
> 
> 
>> On Nov 22, 2019, at 07:15, Bill Woodcock  wrote:
>> 
>> Eberhard:
>> 
>> The principle I’m trying to articulate is that our relationship to ISO 3166 
>> is that of a standards body which has delegated to it.
>> 
>> ISO 3166, in turn, specifies that this code is (for now, and at their 
>> authority) to be used by USERS for their purposes.
>> 
>> It’s my assertion that it’s bad form for us, having placed ourselves in the 
>> standards body role on one side of ISO, to now also claim that we, the same 
>> people, are also  “users”  Standing on the other side of ISO.
>> 
>> That seems to me to not be in the spirit of a good-faith delegation.
>> 
>> If we want to start individually specifying the meaning or use of two-letter 
>> TLDs, it’s my assertion that We should first un-delegate that role from ISO, 
>> and take direct control of the task, not attempt to stand on both sides of 
>> them. And I think the harm of doing so would vastly outweigh any benefit. 
>> Therefore I think this shouldn’t be done. Either we delegate authority to 
>> them, or we don’t. No splitting the baby.
>> 
>>   -Bill
>> 
>> 
>>> On Nov 22, 2019, at 02:17, Dr Eberhard W Lisse  wrote:
>>> 
>>> Bill,
>>> 
>>> ISO has new draft out as part of their regular maintenance cycle which
>>> states
>>> 
>>>  [...]  In addition exactly 42 alpha-2 code elements are not used in
>>>  the ISO 3166, AA, QM to QZ, XA to XZ, ZZ. This rule may change in
>>>  the future.  [...]
>>> 
>>> and then references this
>>> 
>>>  If users need code elements to represent country names not included
>>>  in this part of ISO 3166, the series of letters AA, QM to QZ, XA to
>>>  XZ, and ZZ [...] are available.
>>> 
>>> I read that to mean that a .ZZ (or rather any of the 42 possibles) would
>>> be safe to use in our context.
>>> 
>>> If the rule were to change I would however speculate that the wishes of
>>> the government concerned might prevail over the wishes of ICANN.
>>> 
>>> Whether this all is safe enough to write a standard, I don't know.
>>> 
>>> 
>>> el
>>> 
>>> 
 On 22/11/2019 10:26, Bill Woodcock wrote:
> On Nov 22, 2019, at 12:20 AM, Shane Kerr 
> wrote:
> 
> "User-assigned codes - If users need code elements to represent
> country names not included in ISO 3166-1, the series of letters AA,
> QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ,
> XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers
> 900 to 999 are available.  NOTE: Please be advised that the above
> series of codes are not universal, those code elements are not
> compatible 

Re: [DNSOP] [Add] new draft: draft-grover-add-policy-detection-00

[David Conrad]

On Jul 14, 2019, at 7:09 PM, Rob Sayre  wrote:
> Was DNS intentionally designed to be insecure?

What’s your definition of “secure”?

DNS had clear design elements for availability. DNSSEC added integrity. 
Confidentiality wasn’t a design goal.

Regards,
-drc




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

Re: [DNSOP] Proposal: Whois over DNS

[David Conrad]

Philip,

On Jul 10, 2019, at 6:24 AM, Philip Homburg  wrote:
> With that in mind, it seems that this proposal doesn't address any technical
> issues with whois.

Maybe rate limiting by most (all?) whois servers?

Regards,
-drc



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

Re: [DNSOP] Obsoleting DLV

[David Conrad]

I strongly support moving it to Historic.

Regards,
-drc

> On Jul 2, 2019, at 11:12 AM, Matthijs Mekking  wrote:
> 
> Hi,
> 
> 
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
> 
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
> 
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
> 
> 
> Best regards,
> 
> Matthijs
> 
> 
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
> 
> Name:   draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:  Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:  5
> Status:
> 
>  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/ 
> 
> 
> Abstract:
>   This document obsoletes DNSSEC lookaside validation (DLV) and
>   reclassifies RFCs 4431 and 5074 as Historic.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 



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

Re: [DNSOP] [dbound] Related Domains By DNS (RDBD) Draft

[David Conrad]

Alexander,

On Feb 27, 2019, at 4:32 PM, Brotman, Alexander  
wrote:
> I'm supportive of doing this in other ways, but also understand that DNSSEC 
> is not widely deployed.

There is a difference between not being deployed and not being turned on.  My 
impression is that most DNS servers these days support DNSSEC, however it has 
largely not been enabled.  If you are going to be putting stuff into the DNS 
for security decisions, you need to protect that stuff and that means turning 
on DNSSEC.

Regards,
-drc




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

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

[David Conrad]

Paul,

On Feb 14, 2019, at 1:57 PM, Paul Vixie  wrote:
> 7706 is wrong headed on a number of levels, but its worst offense is to think 
> that the root zone is special.

Operationally, the root zone actually is special. It is, after all, the 
starting point of the name space. As far as I can tell, there are 3 ways the 
root zone is special:

1. How does one obtain name servers for the root zone? How does one obtain name 
servers for any other zone?
2. Who controls the name servers for the root zone? Who controls the name 
servers for redbarn.org?
3. What happens if the root zone is unreachable? What happens if redbarn.org is 
unreachable?

7706 describes one method to improve resiliency, performance, and privacy of 
root name service, with no modification of the DNS protocol or name servers. It 
is, of course, possible to do the same thing with any zone, assuming you have 
enough memory, but few zones generate sufficient interest to do so. Not sure 
why you’re arguing against it. Could you explain?

Regards,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 10:03 PM, zuop...@cnnic.cn wrote:
> that's ture. but in my view, if the trust chain is built, we can ensure a 
> resolver(or a cache) is always talking to a identified server and the channel 
> is always secure, then the content could not be tampered.

Your model of how the DNS actually works is too simplistic.

Regards,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 3:03 PM, Paul Vixie  wrote:
> David Conrad wrote on 2019-02-12 14:58:
>>> lack of an IETF-approved standard with planned implementation by a half 
>>> dozen tech giants,
>> And that worked so well with NAT.
> network operators had a choice whether to deploy NAT.

You missed my point.  The IETF declared NATs heretical and as a result, a 
zillion people did it in a zillion different ways, creating a huge mess.  Lots 
of people are implementing sending/receiving DNS queries/responses over HTTPS. 
DoH simply codifies one way of doing it so that network managers, software 
developers, etc., have a chance to develop management systems for it.

> i'd like the same level of freedom when it comes to how DNS is served.

Then force the folks on your network to install a cert so you can filter out 
DoH.  Contrary to your assertion, I doubt netflow will let you discriminate 
between good and evil. You have to have visibility to do that.

> too old-school?

Too ostrich-like.

Regards,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 2:18 PM, Paul Vixie  wrote:
> Ted Lemon wrote on 2019-02-12 14:08:
>> On Feb 12, 2019, at 1:48 PM, Paul Vixie >  > >> wrote:
>>> DoH _specifically_ evades this, by looking as much as possible like other 
>>> traffic to IP addresses shared by a lot of existing traffic.
>> Right.   So what’s to stop other malicious traffic from doing the same thing?
> lack of an IETF-approved standard with planned implementation by a half dozen 
> tech giants,

And that worked so well with NAT.

Regards,
-drc




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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

Paul,

On Feb 12, 2019, at 8:32 AM, Paul Vixie  wrote:
> DoH is _dangerous_ because it's my network and i require all visitors, family 
> members, employees, and apps to use the control plane i have constructed, 
> which includes DNS surveillance and control.

Why don’t you force folks on your network to install a certificate that would 
allow you to inspect TCP/443 outbound traffic?  How can you be sure folks on 
your network aren’t already tunneling their evil deeds through HTTPS?

Thanks,
-drc



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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[David Conrad]

Vittorio,

On Aug 21, 2018, at 3:33 AM, Vittorio Bertola 
 wrote:
> If so, I can accept your use case: a smart user, knowing what he is doing, 
> does not want anyone else to sanitize his queries for him. But I don't see 
> why the best solution to your use case - which is quite a minority case, 
> though easily overrepresented in a technical environment - is to build a sort 
> of "nuclear bomb" protocol that, if widely adopted, will destroy most of the 
> existing practices in the DNS "ecosystem" (I'm using the word that was being 
> used at ICANN's DNS Symposium in Montreal), including the basic security 
> measures that protect the 99.9% of the users who are not technically smart. 

Perhaps I’m misunderstanding: are you saying the folks who provide resolution 
services in a DoH world would have incentive to not follow basic security 
measures?

Regards,
-drc

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

Re: [DNSOP] zonemd/xhash versus nothing new

[David Conrad]

On Jul 30, 2018, at 5:03 PM, Wes Hardaker  wrote:
>> I think the use for non-root zones is quite a different use case,

I don’t.

>> so if
>> I ignore that, we are looking at specifically the root zone only.
> 
> Please don't ignore that.  We really do ourselves a disservice when we
> design a solution that only works for singular or minimal instances.
> This is beneficial to more than just the root zone.

+1

I don’t think the benefits of mirroring a zone into a resolver is limited to 
the root.

Regards,
-drc

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

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[David Conrad]

On Jun 19, 2018, at 2:03 PM, Ray Bellis  wrote:
> AIUI, a large part of the supposed issue with SRV was the inertia of the
> installed base of browsers that wouldn't know how to access them.

I thought the more fundamental problem was the additional latency caused by the 
second lookup since SRV specified domain names as targets.

But maybe I’m misremembering.

Regads,
-drc

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

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[David Conrad]

On Nov 27, 2017, 11:47 AM -0800, Richard Barnes , wrote:

> I don't think that it make sense to infer from the failure of RFC 8145 that 
> resolver/authoritative telemetry isn't possible

Huh? RFC 8145 wasn’t a failure — it was stunningly successful. Within a few 
months of publication it provided us insights we hadn’t before had into how the 
infrastructure was actually working.  This was unexpected.

> To the degree that the DNS still works at all, there must be some channel by 
> which information can be faithfully passed from authoritative to resolver, 
> which can presumably be used to bootstrap telemetry.  Maybe it's a TXT record 
> with an HTTP URL; maybe it's a funny CNAME.

Maybe it is, and when we see another viable channel, we’ll undoubtedly make use 
of it. Until then, adding something like sentinel would seem to be a useful way 
of gathering information about the state of reality.

> Maybe you can't build a road through the jungle, but there are still rivers 
> that make it through, which can carry a message in a bottle.

I don’t want to let the perfect be the enemy of the … well, perhaps not good, 
but functional.

Regards,
-drc

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

Re: [DNSOP] Agenda for IETF100

[David Conrad]

Can confirm, as can anyone willing to go to an Adobe Connect archive. For the 
curious:

https://participate.icann.org/p6u03rimy92/?launcher=false=true=normal

The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts at 
00:31:00. Paul’s question is at 00:42:16. From the transcript:

>> PAUL:  PAUL, IETF.  LET'S SAY IETF GETS THE DOMAINS IETF IN THIS NAMING 
>> SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS.  EVERYBODY USES THE SITE.  
>> AND THEN AT SOME POINT WE FORGET TO PAY AND THE DOMAIN FALLS BACK INTO THE 
>> POOL AND SOMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY ARE OR WHO 
>> THEY ARE.  NOW I GO TO A COURT SYSTEM.  I GET SOME LEGAL OPINION SAYING I 
>> OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK.  IS THERE ANY WAY 
>> FOR ME TO GET THIS DOMAIN BACK?
>>LEONARD TAN:  SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BECAUSE IT 
>>REQUIRES FOUR OUT OF SEVEN PEOPLE.  MOST OF THEM ARE ETHEREUM DEVELOPERS.  
>>AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANGES.  SO IT IS POSSIBLE, BUT IT 
>>IS GOING TO BE A VERY DIFFICULT THING TO DO.

Regards,
-drc

On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote:
> The ENS developer said so in response to my question.
>
> Sent from my iPhone
>
> > On Nov 10, 2017, at 19:55, Stephane Bortzmeyer  wrote:
> >
> > On Fri, Nov 10, 2017 at 05:58:13PM +0530,
> > Paul Wouters  wrote
> > a message of 29 lines which said:
> >
> > > It takes 4 out of 7 geeks to bypass the blockchain in case of
> > > emergency, court orders or kneecaps.
> > >
> > > According to the presentation held at ICANN60
> >
> > Well, if someone at ICANN said so, someone is wrong (or, at the
> > minimum, over-simplificator).
> >
> > ___
> > 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new DNS classes

[David Conrad]

Mark,

On Jul 6, 2017, 11:56 PM -0700, Mark Andrews , wrote:
> > > Or you could stop trying to reinforce the myth that new RR types
> > > are hard to deploy. They really aren't.

Please stop trying to minimize the amount of work here. They really are. Not 
for you, but for the folks who make domain names available for use by 
non-technical types.

> Then change domain hosting providers and tell them why or run you
> own master server or use a service which allows for dynamic updates
> which shouldn't care about the record types. There are plenty of
> DNS providers that will slave content.

The number of folks who even understand what you've written above, much less 
can actually do it, is insignificant in the context of seeing significant 
adoption of new RRs.

> As a DNS server vendor

You need to look at the wider world.

The DNS server side of deploying a new RR is the easiest part and while 
necessary, it's no where even close to sufficient to getting a new RR deployed. 
It's like trying to move the automobile industry to hydrogen fuel: building a 
car that runs on hydrogen is easy, relatively speaking. However to actually do 
anything useful with that car, you need need to modify the fuel delivery 
infrastructure, which is vastly harder, involves a vastly larger set of 
players, very few of which have any sort of financial incentive to make the 
change. Standard chicken-or-egg problem.

ICANN funded John Levine to develop 
https://metacpan.org/release/JRLEVINE/Net-DNS-Extlang-0.1 to try to make it 
easier to break the chicken-or-egg problem by hopefully giving the folks who 
provide the UIs by which domain names are managed by non-geeks better tools. 
However, that's just the first step -- the domain name managers still need to 
be encouraged to use them.  Pretending this is an easy problem isn't helping.

Regards,
-drc
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new DNS classes

[David Conrad]

Paul,

On Jul 4, 2017, 10:59 AM -0700, Paul Vixie , wrote:

> > > On 4 Jul 2017, at 18:49, Paul Vixie wrote:
> > > while IETF governs the protocol, ICANN only governs the IN class.

Sorry, could you point me to anything that documents this?  My impression has 
always been that ICANN governs (I'd prefer the term coordinates myself) what 
"the community" feels it should coordinate. I don't recall this being limited 
to a particular DNS class, but I might have missed it.

> nobody ever got a bonus for making things simpler.

Oh sure they have.

Thanks,
-drc

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

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[David Conrad]

Paul,

On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote:
> the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or 
> non-experienced or non-protocol-geeks;

7706 doesn't recommend editing someone else's zone file, re-signing it, and 
figuring out how to replicate the hints and trust anchor to _all_ relying 
devices (and restoring the real hints/trust anchor when you're done). This 
strikes me as a bit more complicated than 7706. YMMV.

> and both approaches are appropriate only for closed internal networks where 
> the configuration is controlled by a single administration.

If I set up an open resolver using 7706, what negative repercussions do you see?

> the misstatement is, dnssec's purpose is not defeated, because iana's 
> signatures are checked before the zone is accepted, and new signatures are 
> added using local keys before publication.

Meaningless given you are explicitly editing the zone as published from and 
signed by the authority. You claim you aren't modifying the namespace content 
(well, except for the root NSes), but the point of DNSSEC and the rather 
Byzantine structures we've built around establishing trust is that we don't 
have to believe you: you can see _everything_ having to do with creating the 
trust anchor and everything down to the leaf.

The only advantage(?) I see in your approach is that is allows (forces) you to 
play around with the namespace and re-sign. Might be useful for neo maxi zoom 
DNSSEC nerd experimentation, however as mentioned previously, that doesn't 
strike me as something one might recommend lightheartedly.

> for my many-vm's laptop environment, running on a loopback isn't a solution.

I strongly suspect you could come up with a solution that didn't use loopback 
but which also didn't require modifying the root zone, resigning it, and 
getting all relying devices to use both your NS hints and trust anchor. Like, 
perhaps running on a non-loopback address within your flock of laptop VMs?

> http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

Saw that a year ago and still think it post-hoc rationalization and specious, 
but I'm sure that's just me.

Regards,
-drc

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

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[David Conrad]

On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote:

> if you want to run yeti-style, there are some perl scripts that will
> fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> re-sign with your local key, and give you a zone you can run on several
> servers inside your internal network, such that you can point your
> "hints" and your dnssec anchor at servers you control, for all your
> internal-network recursives,

Not so sure this is something I'd go about recommending to pretty much anyone 
other than hardcore, very experienced DNS/DNSSEC protocol geeks since it pretty 
much defeats the purpose of DNSSEC (edit the apex? ugh) and requires all 
relying devices to configure a "non-default" trust anchor or suffer SERVFAILs.

Regards,
-drc


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

Re: [DNSOP] .arpa

[David Conrad]

Hi,

On Mar 26, 2017, 5:37 PM -0700, George Michaelson , wrote:

> In no sense is the domain solely used or intended for PTR requests,

Is anyone claiming this? If so, that'd be really silly given the contents of 
the .ARPA zone is:

as112.arpa.
e164.arpa.
in-addr-servers.arpa.
in-addr.arpa.
ip6-servers.arpa.
ip6.arpa.
ipv4only.arpa.
iris.arpa.
uri.arpa.
urn.arpa.

Of those, only two are used for PTR requests.

> I particularly like that we don't actually have to do very much beyond
> note it, and ask IANA to operate a registry for it.

I'll admit I'm a bit confused: what would be in such a registry?

Truth be told, I sort of like the "home.arpa" idea -- seems to dodge a lot of 
layer 9 stuff (unless, of course, the whole point is to try to resolve layer 9 
issues).

Regards,
-drc

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

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[David Conrad]

Andre,

On Dec 20, 2016, at 9:49 PM, ac  wrote:
> I once made a very cool tool, it improved the life of many people as it
> allowed anyone to take over any pc running a certain operating system
> with the sole and great purpose of helping more users. It too was
> published, improved, altered and distributed widely
> 
> RPZ is like that.

No, it's not.

There is a rather striking difference between a tool I choose to deploy on my 
network that helps protects my users from external threats and a tool that 
allows an external entity to intrude on my users. If you do not understand 
this, there is a bigger problem to address.

> RPZ will be legitimized by this draft, it will be used and living human
> beings may actually die because of server software.

RPZ is legitimized by its use, not by the documentation describing that use.  
Proverbially sticking your head in the sand does not remove the carnivores that 
are eyeing the rest of your body.

> And, this is my final word on this, I apologize if anyone feels that I
> have wasted their time or offended them in any way. This was never my
> intention.

It would appear your intention is to school the ignorant masses in the errors 
of their ways. Personally, I'm always a bit nervous when someone decides they 
know what's best for me or the folks I might provide services for.

Regards,
-drc
(speaking only for myself)



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

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[David Conrad]

+1

Regards,
-drc
(speaking only for myself)

> On Dec 20, 2016, at 4:02 PM, John Levine  wrote:
> 
>> "Not wanting to be recruited into a botnet" is another such consideration.
>> Paul and Vernon invented a useful tool to help address it, and I'm
>> in favor of documenting it.
> 
> I would really prefer that the IETF not embarrass itself with a rerun
> of the NAT fiasco, in which TCP/IP purists yelled and screamed and
> insisted that NAT was evil, while in the real world it solved (still
> solves) real problems, and everyone implemented it in various not very
> transparent or compatible ways.
> 
> RPZ is ugly but it solves serious real world problems, and it's going
> to be used all over the world regardless of what we do.  Just this
> week I heard from a friend at a largish company that one of their
> suppliers got hacked with the trendy new malware that hides in web
> page images.  Without RPZ, approximately all of their Windows users
> would have been infected, with RPZ none of them were.
> 
> If we want to offer advice and perhaps technical twiddles on how to
> deploy RPZ to minimize surprises and make it easy to find and fix
> mistakes, that would be swell.  Insisting that it's stupid and wrong
> confirms the not ill-founded impression that dnsop is out of touch
> with the real world.
> 
> So, yes, we should adopt this draft.
> 
> R's,
> John
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop





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

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

[David Conrad]

Bill,

On Dec 17, 2016, at 11:36 AM, william manning  wrote:
> Is there any public data to support the presumptions of excess capacity at 
> the roots and the impact of NSEC aggressive use on the DNS?

Warren provided some interesting anecdotes at the last IEPG, but I'm unaware of 
any formal modeling.

> I know that in the previous century, punting on operational impact by 
> guessing about outcomes was common.   I thought the IETF had moved away from 
> SWAG and was working toward a more disciplined and fact based process for 
> making changes.

I make no comment on what the IETF has moved towards or away from.

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

[David Conrad]

I presume NSEC Aggressive Use will significantly reduce the amount of crap 
hitting the root servers.

Given how much capacity the root servers already have to provision to deal with 
that crap, I don't think a massive increase in legitimate (NSEC Aggressive 
Use-implementing) resolvers will move the needle significantly.

Regards,
-drc

> On Dec 15, 2016, at 1:00 PM, Ted Lemon  wrote:
> 
> Billions and billions of them?   How often do they query the root, do you 
> think, compared to a stub resolver that did recursion itself?
> 
> On Thu, Dec 15, 2016 at 3:57 PM, John R Levine  > wrote:
> Putting an iterative resolver in a stub resolver is an attack on the DNS 
> infrastructure.
> 
> Ted might want to alert all of the BSD and linux distros that default to 
> running a copy of bind or unbound answering queries on 127.0.0.1.
> 
> Regards,
> John Levine, jo...@taugh.com , Taughannock Networks, 
> Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly 
> 
> 
> ___
> homenet mailing list
> home...@ietf.org 
> https://www.ietf.org/mailman/listinfo/homenet 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] A mention of draft-fujiwara-dnsop-resolver-update and draft-weaver-dnsext-comprehensive-resolver

[David Conrad]

Stephane,

> On Dec 5, 2016, at 9:24 AM, Stephane Bortzmeyer  wrote:
> 
> https://blog.cloudflare.com/tld-glue-sticks-around-too-long/
> 
> "In this article, I explained what DNS glue is, and why I believe that
> DNS TLD glue TTL values hardcoded at 48 hours are not helping with
> DDoS mitigation. I hope this article will serve as a call to action
> for relevant TLD operators. I believe the ability to adjust DNS glue
> TTLs is a simple yet effective way to make DNS infrastructure more
> reliable."
> 
> With my TLD operator hat: not convinced.

It might be more helpful if you perhaps could explain why you're not convinced?

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

[David Conrad]

>> Local Host: "Hip and cool city trips. Totally not creepy and weird."
> Shane is the sarcasm really helpful here?

It rarely is.

> localhost is already out of bounds for the gTLD processes at ICANN and you 
> well know that.
> 
> As per the gTLD Applicant Guidebook, section 2.2.1.2.1 Reserved
> Names in version 2012-01-11 [1].
> 
> Mark
> 
> [1] https://newgtlds.icann.org/en/applicants/agb/guidebook-full-11jan12-en.pdf

Sort of. The Applicants Guide Book referenced was for use with the "Class of 
2012". A revised AGB will undoubtedly be prepared for the next round of new 
gTLDs (if one does occur), taking into account lessons learned.  I would guess 
it is _extremely_ likely that if the IETF were to define a list of top-level 
labels that were reserved for "technical uses", the ICANN community would 
incorporate that into the new version of the AGB. After all, if the community 
didn't, I suspect it'd be cause for the exercise of termination clause of RFC 
2860.

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[David Conrad]

Hi,

On October 3, 2016 at 5:14:24 PM, John Levine (jo...@taugh.com) wrote:
ICANN (or perhaps some people within ICANN) are 
asking whether they should delegate .corp, .home, and .mail and 
presumably other toxic waste names, and want an authority they can 
point to for the answer. 

Just a clarification:
As far as I know, neither ICANN (the organization) nor anyone within ICANN (the 
organization) is asking whether they should delegate such names. Forward motion 
of those names is currently "indefinitely deferred" pending _somebody_ (not 
ICANN staff) figuring out what to do with them. I believe the hope had been 
that the IETF might provide some technical guidance, but that didn't work. Now, 
some members of the ICANN community are asking the board that those names be 
delegated and that results in (re)opening the question of what to do with 
"indefinitely deferred" strings.

The P2P crowd would like to carve out some 
names to run their resolution scheme in parallel with the DNS, and it 
appears they'd also like an authority they can point at. 
Well, some do. To be honest, it feels to me that some appear to want to say "we 
don't like ICANN" or, more generally, "Screw you, Establishment!" 

I suppose it's flattering that everyone is looking at us, but as we are 
seeing, just because a vacuum sucks (by definition, after all) does not 
necessarily mean we are qualified to fill it. 

Not everyone. I (and I think Paul W) have been suggesting that the IETF is not 
really the best place to deal with the implications of trying to fill that 
vacuum -- too many lawyers smelling blood in the water. The new gTLD 
Applicant's Guide Book was 300+ pages for a reason and it wasn't, as some have 
(loudly) suggested, because ICANN (the organization) is evil or greedy or 
incompetent, rather the issues involved in dealing with a resource that can 
only be allocated to one entity when multiple entities might have an arguably 
valid claim to the resource, get complicated quite quickly and when money is 
involved (which names seem to attract), lawyers follow and it gets ugly fast. 

There be serious non-technical dragons here. I don't speak for ICANN, but I 
suspect ICANN (the organization) would love to have a list to point at that 
says "can't delegate these because the IETF say so -- talk to them about why" 
just as ICANN points to ISO-3166/MA when someone comes and demands their 
2-letter made up string should represent their "country." This may not be 
career enhancing, but speaking as an IETF participant (which I assume we all 
are), it isn't clear to me this would be prudent if we want the IETF (or 
rather, it's legal parent(s)) to be a viable entity in the long run. 
Particularly if the "why" turns out to be the winner of a beauty contest 
decided by the IESG as 6761 current suggests.

Regards,
-drc
(ICANN CTO, but speaking only for myself)



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

Re: [DNSOP] Mitigation of name collisions

[David Conrad]

Warren,

On October 3, 2016 at 12:33:12 PM, Warren Kumari (war...@kumari.net) wrote:
... and just for the record, much much more could have been determined 
(and users better warned / informed) if the address handed out was a 
server which displayed an error / links to more information[0],
I'm not particularly interested in beating the smudge on the ground that was 
the honey pot dead horse yet again. Here's an idea: if you can get Google 
lawyers to accept the full legal liability and privacy implications for running 
such a honey pot (regardless of how it is implemented and for what protocols), 
let me know and I'll argue that we should do an RFP to outsource the operation 
of such a honey pot in the next round. Until then, perhaps we can let the dead 
horse rest in peace?

 or if 
the name-servers serving the wildcard were required to collect and 
publish information and statistics. This would have allowed analysis 
of the effectiveness of the mitigations, etc. 

This, however, is more interesting and should another round occur, I think it'd 
make sense to do this in a staged fashion, first to ICANN name servers, then to 
the registry's name servers.

Of course, IIRC, people were arguing that you shouldn't ask questions when you 
aren't sure what you'll do with the answers... 

Regards,
-drc



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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[David Conrad]

Mark,

On September 28, 2016 at 5:08:05 PM, Mark Andrews (ma...@isc.org) wrote:
> I've been telling people that if they need a fake private TLD for their local 
> network they should use one of those since it is exceedingly unlikely 
> ever to collide with a real DNS name. Am I right? 

No. Just because countries don't get assigned these values it 
doesn't mean that they can't be assigned by ICANN or the IETF in 
consultation with ICANN. 
I believe from both the IETF's and ICANN's perspective, 2-letter labels at the 
root are reserved to be associated with ISO-3166 2-letter codes. I cannot 
imagine a plausible scenario in which this policy would change.

And who *needs* a fake tld? As far as I can tell almost no one. 
Can we PLEASE not repeat the arguments made against RFC 1918 space in the 
domain name world?

Regards,

-drc




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

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

[David Conrad]

On Apr 24, 2016, at 7:54 AM, Ted Lemon  wrote:
> Paul. I think actually that we need to start maintaining a list of things 
> that ought to be explicitly looked for when reviewing documents for 
> publication, and this sort of thing would be one such.

I'll admit some surprise that such a list doesn't already exist.

> This is not to say that it's not a hard problem, though--such a list could 
> easily become unwieldy.   We tried to do something like that with RFC 7227 
> section 13.   The problem is that if there isn't a single resource to go to 
> for this stuff, and there's no step in the review process where this sort of 
> check happens.

That's also surprising.

The fact that problems like this haven't occurred before honestly increases my 
(already high) opinion of working group chairs and the IESG.

Regards,
-drc
(speaking only for myself)



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

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

[David Conrad]

Stephane,

On Apr 23, 2016, at 1:07 PM, Stephane Bortzmeyer  wrote:
> Interesting RFC, which introduces officially the TLD .home, without
> using the RFC 6761 framework. So, apparently, you can reserve TLDs
> without going through the Special-Use Domain registry.

I would agree that it is interesting.  Unsurprisingly, it is not in 
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.
 My gut feeling is that this is a process failure, but will admit that the 
whole question is quite unclear given the continuing uncertainty about the 
process described in 6761.

> I also note that some people complained that registering .onion was
> squatting on ICANN's property.

If anyone did complain that .ONION was "squatting on ICANN's property", I think 
they were being silly.

FWIW, I do not believe unallocated names are anyone's "property".  There is a 
process that was developed in an open and transparent manner over a decade in 
which people can apply for parts of the DNS namespace, and that process went to 
great pains to try to walk a twisty maze of policy, legal, and economic 
interests. There is also a process developed within the IETF in which people 
can ask the IESG for parts of the domain [sic] namespace.  Given 7788, it would 
appear there is Yet Another process within the IETF by which parts of the 
domain [sic] namespace can be obtained, the rules of which are unclear (that 
is, it looks like "let's just pick a name").

> But .home was accepted while, unlike
> .onion, there are actually people who are candidates to manage it.

Why does the fact that there are actual people to manage something matter? Who 
manages 10.in-addr.arpa?

Regards,
-drc
(speaking only for myself)




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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

Stephane,

On Apr 7, 2016, at 5:48 PM, Stephane Bortzmeyer  wrote:
> On Thu, Apr 07, 2016 at 04:15:36PM -0400,
> Suzanne Woolf  wrote
> a message of 32 lines which said:
> 
>> To be clear— I wouldn’t argue that “all identities *are not* subject
>> to socio-economic pressures” any more than I’d argue that “all
>> identities *are* subject to socio-economic pressures”.
> 
> As an example, see this registry
> 
> It has many names, some of them being trademarks, and nobody ever
> complained. Because of context.

Yes they have.  On several occasions, back when I was running IANA (circa 
2005-2008) -- I received the complaints. I believe I raised that issue to the 
IESG on a couple of occasions (or maybe not, don't recall exactly).  Maybe 
things have changed since then.

Regards,
-drc
(speaking only for myself)



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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

Suzanne,

On Apr 7, 2016, at 2:49 PM, Suzanne Woolf  wrote:
> It is a matter of scope, to say nothing of opinion, that “all names are 
> subject to socio-economic pressures.”
> [...]
> Given that discussion of “special use names” is even more likely than most to 
> suffer from assumptions about context, a more precise formulation of this 
> claim would probably be helpful.

The way I see it, "Internet names" (that is, domain names whether they are used 
in the DNS or not) are typically used to identify hosts, end points, or 
services on the Internet. People tend to get wound up with their identity and 
how that identity is made available on the Internet (or overlays on top of the 
Internet). That being wound up often result in socio-economic pressures, e.g., 
being bought/sold, triggering lawsuits over ownership/existence, etc.  Do some 
of those identities not get tied up in those socio-economic pressures?  Sure, 
the vast majority.  However, I'm not sure I can see how all identities are not 
subject to socio-economic pressures.

Regards,
-drc
(speaking only for myself)



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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

Suzanne,

On Apr 7, 2016, at 2:39 PM, Suzanne Woolf  wrote:
>> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer  wrote:
>> 
>> Since we have this liaison, does anyone know if it was used to inform
>> ICANN of this discussion (it seems the right thing to do) and to ask
>> them if they wanted to comment?
> 
> https://datatracker.ietf.org/liaison/1351/
> 
> (DNSOP co-chairs, AD, and IAB collaborated on this, as the IAB has oversight 
> of liaisons for the IETF.)

Out of curiosity, since that liaison statement was made about 18 months after 
RFC 6761 was published and about a 10 months after 
draft-grothoff-iesg-special-use-p2p-names was submitted, was there any previous 
liaison communication to ICANN prior to that statement related to RFC 6761?

Thanks,
-drc
(speaking only for myself)



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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

Adrien,

> I think we still need to answer the question about whether DNS namespace 
> should be polluted for non-DNS resolution.

I believe your question is wrong.

The "DNS namespace" can't be polluted for non-DNS resolution because the DNS 
namespace is, by definition, only comprised of names that can be resolved via 
the DNS.  The "Internet namespace" is larger than that.  Even before RFC 6761, 
there were names that should never hit the DNS, specified in RFCs 2606 and 
1918. RFC 7686 added "onion". A number of folks want to add more.

In my view, the real question here is what is the distinguishing 
characteristic(s) and processes by which an "Internet name" is categorized as a 
"DNS name" (which, at least at the top level, presumably falls under ICANN 
community-defined policies) and those fall under a different categorization.

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

>> Also, it would make very difficult to DNS programmers to keep track of
>> all these "special but not special" domain names.
> 
> Personally, I consider naming systems developed outside the IETF a problem.
> 
> There should be no register, because they should not exist.

This appears to assume that naming systems are only developed in the IETF or 
that a naming system not developed in the IETF is not relevant/impactful.

I don't think this is a good assumption.

Regards,
-drc
(speaking only for myself)



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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[David Conrad]

Hi,

> Some people
> complained that it was difficult enough with RFC 6761 (because there
> is no machine-readable version of the special-use registry)

Last I looked 
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml
 was XML and it's machine-readable.

> but it
> would be worse with scattered domain names in many TLDs.

OK, I'll say it.

Put special use registry be put into the DNS, e.g.,

$ORIGIN special-use-domain-names.arpa.

10.in-addr.arpa IN URI 10 1 "http://www.iana.org/go/rfc6761;
...
onion   IN URI 10 1 "http://www.iana.org/go/rfc7686;
...


(in keeping with the t-shirt slogan)

Regards,
-drc
(speaking only for myself)


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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Suzanne,


On Mar 29, 2016, at 5:23 PM, Suzanne Woolf  wrote:
> I’ve always seen people assume that an entry in the special use names 
> registry means that ICANN won’t delegate the same string in the DNS root.

I thought putting a name onto the special use names registries was an exercise 
in informing ICANN (and the rest of the world) that the IETF was invoking 
clause 4.3(a) of RFC 2860. The last paragraph of 4.3 states:

"In the event ICANN adopts a policy that prevents it from complying with the 
provisions of this Section 4 with respect to the assignments described in (a) - 
(c) above, ICANN will notify the IETF, which may then exercise its ability to 
cancel this MOU under Section 2 above."

Are you suggesting you believe ICANN would want to trigger that exercise or 
that using the special use registry is not invoking clause 4.3(a) (or something 
else)?

Regards,
-drc



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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

George,

On Mar 28, 2016, at 6:58 PM, George Michaelson  wrote:
> Whats the process to understand how, and why a name gets added to the
> list? Thats not an IETF question, understandably, but it would be nice
> to understand it, even only in outline.


As Suzanne mentioned, there is no process as the new gTLD program (for the last 
round) has been shut down.  If/when a new round is created, there will be a new 
process (one undoubtedly based on the previous process but with enough changes 
to keep things interesting).  As that process does not yet exist, it is 
difficult to outline it.

One might view this as an encouragement for folks within the technical 
community (and the IETF in particular) to be less reticent to participate in 
ICANN processes than in the past, despite how excruciatingly painful that might 
be, but that's just crazy talk.

Regards,
-drc



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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 28, 2016, at 8:36 PM, Andrew Sullivan  wrote:
> But I think you're smuggling into your argument a claim that
> they're potentially subject to the IPR and socio-economic issues that
> have been a problem in the DNS root and TLD zones.  That's in effect
> an argument that the special-names registrations are not special.  I
> do not agree with that claim.

Just to be clear, you believe that the IESG putting a name onto the special 
names registry means that it will then be immune from IPR and socio-economic 
issues?

Thanks,
-drc



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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 28, 2016, at 11:33 AM, Andrew Sullivan  wrote:
> I am pretty sure that
> whatever could get registered under RFC 6761, it would not be an
> ordinary name in the DNS.

What do you mean by "ordinary"?
In what way is ONION not "ordinary"?
In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"
Are HOME, CORP, and MAIL "ordinary"?

Thanks,
-drc



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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Ralph,

On Mar 28, 2016, at 6:43 AM, Ralph Droms  wrote:
> First, I'll emphasize that the process of designating a name as "special use" 
> is separate from the mechanical process of actually adding a new name to the 
> Special-Use Names registry.

Agreed.

> RFC 6761 explicitly defines the latter process, and implicitly requires open 
> IETF review for the former process.  In my opinion, we can focus on the 
> former process, of deciding whether a name should be designated as having a 
> special use.  This process may have, as you point out, issues regarding 
> trademarks, association of names with organizations, and many others.
> 
> I'm not trying to wish those issues away, and I don't think Andrew is either. 
>  Rather, speaking only for myself, I believe that our open process of 
> community review and consensus is an appropriate starting point for 
> discussion.

In my limited experience, the IETF process is great for (a subset of) technical 
matters. It has perhaps been less than great in social/political/economic 
matters and I thought there was a general reluctance for the IETF to go that 
direction. I am a bit surprised there appears to be a desire, implicit or not, 
to apply the IETF process in these non-technical areas, particularly as many 
assume that part of the reason for 2860 was specifically because the IETF 
wasn't, at least historically, particularly well suited to or interested in 
dealing with these kinds of non-technical issues.

I am a bit curious as to the rationale behind the change of heart.

Regards,
-drc
(Speaking only for myself)


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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 25, 2016, at 7:16 PM, Andrew Sullivan  wrote:
> I think it is plain that a name that is actually somehow implicated in
> the existing root policies (in which I would include names that are
> excluded under some ICANN policy) are just not candidates for 6761
> reservation, and I would expect the necessary consensus involved to
> ensure that happens.

Sorry, how is it "plain"?

Is it plain that (say) GNU is/is not a candidate for 6761?  Given 
https://gnunet.org/gns and the purported interest of folks involved in that 
project to use 6761, what is supposed to happen if the folks at 
http://www.gnu.com decided to pursue a brand TLD in the next round?  If the 
folks at https://onion.coop or http://www.theonion.com had applied for a brand 
TLD in the last round, what would the TOR folks have done?

> For we're talking about names that people have had the opportunity to
> try to claim, but have not done.

I don't think so: this appears to assume a one-time event.

At the highest level, perhaps what we're talking about is what characterizes 
"technical use" sufficient to justify application of 2860 4.3(a).

Thanks,
-drc



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

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Ralph,

On Mar 25, 2016, at 8:33 AM, Ralph Droms  wrote:
> I'm responding here with none of my various hats on...

Me too.

> RD>> I think it's more correct to write that RFC 7686 defines ".onion"
> as a Special-Use Domain Name, which takes it out of the Domain Name
> space.

No.  It is still a domain name in the sense that it is within the universe of 
identifiers under a singly rooted namespace used on the public Internet (the 
"domain name namespace").  What it is not is a part of the subset of that 
namespace that is resolved using the DNS protocol/infrastructure.

> RD>> Similarly, why are .uucp and .bitnet "bad precedents"?

They are bad precedents because of the challenges they caused for network 
operations. Specifically, the fact that they were local policy considerations 
meant that references to a .bitnet or .uucp name within one administrative 
domain would work but would fail when that reference escaped that 
administrative domain (e.g., in a cc line of an email address). In my view, 
this is essentially the same problem that led to the IAB publishing 2826. One 
of my concerns with 6761 is that it can encourage recreating that operationally 
challenging world without explaining the inherent risks.

> I think the common assumption is that everything
> not lised in the Special-Use Domain Names registry is in the DNS name
> space, which would make the Registry a complete catalog.

I disagree. I believe the domain name namespace can be broken down into:

1. In the DNS (exists within the root zone)
2. Not in the DNS (exists within the special use registry)
3. Not defined (everything else)

The primary issue I have with 6761 is that while it is relatively clear who the 
authority is for (1) and (2), it does not provide a clear answer about the 
authority for (3) or how a name gets put into (1) or (2) when taken in the 
context of 2860, section 4.3.

> By design, RFC 6761 makes no
> statement about a specific WG or evaluation body or process.

Which is, of course, one of the key problems. It results in an undefined 
decision process dependent on the individual subjective evaluation of IESG 
members.  Given the economic, political, and social implications of the naming 
hairball, this seems like a really bad idea to me.

Regards,
-drc
(speaking only for myself)





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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[David Conrad]

Suzanne,

On Mar 18, 2016, at 3:51 PM, Suzanne Woolf  wrote:
> There's an argument to be made that "People considered carefully and don't 
> believe any amount of tinkering will make an idea that depends on CLASS 
> workable, so the option isn't available" will result in shorter conversations 
> about those ideas.

I love your optimism, however I am skeptical that closing the registry will 
have the desired effect.  I suspect a more likely outcome is that the 
conversations will instead get longer as they become heated as to whether or 
not the registry should be reopened.  I suspect a better answer for the desired 
effect you are hoping for by closing the registry would be an RFC that says 
"Classes Are Not The Droids You're Looking For" that would allow "DNS experts" 
to simply point to that document whenever someone suggests classes are a 
solution to any particular problem.

And no, I'm not offering to write said document :)

Regards,
-drc



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

Re: [DNSOP] RFC 7719 on DNS Terminology

[David Conrad]

+1

Very good work by all involved.

Now, just need to have a similar document for the DNS protocol itself :)

Regards,
-drc

> On Dec 15, 2015, at 5:06 PM, Tim Wicinski  wrote:
> 
> 
> I want to give a big thanks to the authors and the working group for the 
> painstaking approach to completing this.
> 
> tim
>  Terminology.eml>___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

[David Conrad]

Mark,

> What is the actual harm, discounting aesthetics?

For one thing, names not supported by the underlying infrastructure will 
_always_ leak.

In the bad old days, when an application got a string ending in .UUCP, .BITNET, 
.CSNET, etc., it had to know that those strings had to be treated differently. 
Various hacked libraries did different things to deal with those endings, and 
usually imperfectly. Worse, the universe of endings was local policy specific 
but the use of those names was global in scope, so there were a never ending 
series of issues where a string would work in one locale but not in another, 
resulting in user complaints, general confusion, and much gnashing of teeth. 
After a number of years, we (re)learned that maybe using the name of something 
to distinguish its underlying infrastructure requirements wasn't the best idea.

.LOCAL, .ONION, and 6761 in general allow us to repeat history yet again, since 
we seemed doomed to be unable to remember earlier lessons.

Regards,
-drc



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

Re: [DNSOP] Expiration impending:

[David Conrad]

Hi,

> On Oct 8, 2015, at 9:40 AM, Andrew Sullivan  wrote:
> 
> On Mon, Oct 05, 2015 at 09:39:06AM -0400, Paul Hoffman wrote:
>> Fully agree. That is why this should not be an IETF document, and instead it
>> should be written and published by the organization that is responsible for
>> the formats and publication methods.
> 
> I don't really care how this happens, but I note that both previously
> and currently staff of that organization seem to use the RFC series to
> publish technical specification documents.  Generally policy documents
> don't get published as RFCs, but other documents do.
> 
> I am not too sure I see why it'd be helpful to create a completely new
> publication mechanism for such specifications from ICANN.

Speaking only for myself (which I presume is the case for anyone discussing 
IETF-related goop)...

I'd like to try to get away from the "I" word, err... acronym, as that seems to 
cause some people to knee-jerk in unhelpful ways.

If I can generalize a bit:

There is a file. A bunch of independent people want to use the contents of that 
file. They also want some level of assurance (not absolute) that The Bad Guys 
haven't mucked with the contents of that file. The folks who currently generate 
the file do a bunch of things to provide some level of assurance that most (not 
all) folks think provide a useful level of assurance.

Now, in order for the independent people to verify the contents of the file, 
the folks who _currently_ generate the file need to publish the things they do. 
The folks who _currently_ generate the file could publish the things they do on 
their website, but the folks _currently_ generate the file may not do so in the 
future and the independent people would then have to worry about whoever takes 
over the role of generating the file will change things in non-backwards 
compatible ways, resulting in much gnashing of teeth.

So instead of the folks who _currently_ generate the file publishing stuff on 
their own website, they turn to a neutral, third party, voluntary standards 
development organization and say "hey, this is how we provide some level of 
assurance for the content of the file a bunch of independent folk care about. 
We'd like to turn it into one of your standards, any thoughts?" If the 
standards development organization accepts this, it means the folks who 
_currently_ generate the file won't pull the rug out from under the independent 
folks who use the file (not that they would, but having the assurance that they 
won't is often helpful in convincing developers to use the file). It also means 
if/when the folks who generate the file change, the new folks who generate the 
file will have a standard to conform to.

This strikes me as a good thing.  It also implies that people in the standards 
development organization can change how the file is secured and that's OK, 
because the folks who _currently_ generate the file go to great lengths to try 
to get input from "the community" (whatever that is) and that input is actually 
welcomed.

What am I missing?

Thanks,
-drc





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

Re: [DNSOP] Expiration impending:

[David Conrad]

Suzanne,

> (Jonne Soininen is the current liaison manager, cc'd).

Jonne's email address looks suspiciously like Andrew's :)

> This sounds like you'd be OK with publishing the document as an Informational 
> RFC,

Yes.

> mod making sure it's accurate as a current description,

Most important and prerequisite to the above.

> and you don't much care which document stream does it-- correct?

Don't have an opinion as the only thing I know about streams is that crossing 
them is "bad".

Regards,
-drc



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

Re: [DNSOP] Expiration impending:

[David Conrad]

Hi,

On Oct 2, 2015, at 9:10 AM, Suzanne Woolf  wrote:
 Preempting a WGLC, I support the document.  It states its aim of
 documenting existing practices, and it does so clearly.
>>> 
>>> I agree completely. I am actually confused as to why it is not already
>>> an RFC.
>> 
>> +1

I've since been told that the draft doesn't actually document current practice 
(don't know the details), so this probably needs to be fixed.

> Well, as a technicality, I don't see that this draft was ever adopted by the 
> WG.

Perhaps that might be a good next step?

Regards,
-drc



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

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[David Conrad]

> On Oct 1, 2015, at 10:45 AM, John Levine  wrote:
> 
>>> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is 
>>> reserved.
>> 
>> Anything is a loopback address if you alias it on your loopback interface.
>> 
>> ::2 was only intended as an example (that's why I said "salt to taste"),
>> but it was not a particularly well-chosen one.
> 
> On your system, I'm sure it works fine.  On other systems that
> implement IPv6 in other ways, maybe not.

Which is why I think

https://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00

should be resurrected (not directly relevant to DNSOP of course).

Regards,
-drc



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

Re: [DNSOP] Expiration impending:

[David Conrad]

On Sep 29, 2015, at 2:53 AM, Shane Kerr  wrote:
>> On Mon, Sep 28, 2015 at 07:59:00AM -0400, Joe Abley wrote:
>>> This document describes existing practice, and provides guidance for
>>> people who need to bootstrap a validator using the mechanisms provided
>>> by ICANN back in 2009/2010 when the root zone was first published.
>> 
>> Preempting a WGLC, I support the document.  It states its aim of
>> documenting existing practices, and it does so clearly.
> 
> I agree completely. I am actually confused as to why it is not already
> an RFC.

+1

Regards,
-drc



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

Re: [DNSOP] Warren's DNSSEC root update draft

[David Conrad]

Mike,

On Jul 21, 2015, at 9:07 AM, Michael StJohns m...@nthpermutation.com wrote:
 The decision with respect to clients ... would see some benefit...  has to 
 be based on what the servers know.

Yes, and the information provided by the mechanism described by Warren's draft 
would provide at least some information to the servers as to state of the 
clients.

 Causing a client to emit something that isn't necessary to get the service is 
 generally considered a requirement for opt-in type of consideration.

Do you disable Software Update-like probes on your operating system(s) and 
applications?

 and probably an assignment of resources at ICANN for the data reduction.
 You mean like https://github.com/dns-stats/hedgehog/wiki/About?
 Tools are cool.  I assume you're going to fund the people?

Me? No.

However, if you're asking if ICANN would fund the people, you might want to 
look at who funded Hedgehog in the first place. Since ICANN runs a root server, 
I think it safe to assume we'll support continued development of features we 
need.

 I am unclear how Warren's draft alters the privacy profile of the root 
 servers in any way.
 It doesn't.  It alters the privacy profile of the clients.

Sorry for being unclear.

Today, everyone trusts the root servers and a vast amount of (meta) data is 
available to anyone at or in the path of the root servers (this is the privacy 
profile of the root servers I was mentioning). Warren's draft enables the root 
server operators (and anyone in the path to the root servers) to be able to see 
the keyids the resolvers are using, presumably for validation. Given the 
information already available to the root servers, et al., and the fact that 
the querying systems that are leaking the information are (generally) not end 
user systems, I personally do not see any significant increase in privacy 
exposure risk. YMMV.

 A serious question: how does one monitor the progress of resolvers migrating 
 to the new KSK via 5011 rollover?
 To answer your question (and mine)- statistically and with great difficulty.

And what data do you use to measure 'statistically and with great difficulty' 
the progress of resolvers migrating to the new KSK via 5011 rollover?

 You're going to have classes of devices that you can look at to see what they 
 would *normally* do and you'll use that to reason about the actual ones in 
 the wild (e.g. the home premise stuff or DNS in a box stuff);

Statistically speaking, the number of machines ICANN, as the IANA Function 
operator and the entity responsible for managing the KSK, can look at to see 
what they would *normally* do is and will always be insignificant.

 Mostly, I'm unclear why we're worrying about it.

Because the root of the DNS is seen as critical infrastructure and I believe 
the Root Management Partners would prefer to have more information rather than 
less regarding how much of the Internet we're going to break.

 We told the community what we were going to do, they are adults.

We told a bunch of DNS protocol geeks, network operators, and a few others what 
we're going to do.

Being adults and having a bit of responsibility, I don't believe the Root 
Management Partners have the luxury of being cavalier about breaking critical 
infrastructure.

  They were told this was going to happen within 5 years and that it would be 
 5011.

Actually, I believe we said after 5 years and we did not specify the 
technology by which the key would be rolled.

 At this point, implementing new functionality is pretty much a non-starter.

I do not believe DNS software will be frozen after the first key roll.

Regards,
-drc
(ICANN CTO, but speaking only for myself)



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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

David,

On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote:
 Of course, ICANN has already determined that .corp does pose a security issue 
 of sufficient  significance that .corp will not be delegated.

For clarity, I believe ICANN has placed the delegation of .CORP on hold 
indefinitely. I do not believe ICANN has stated that .CORP will not be 
delegated. Part of the reason for this discussion is due to this fact.

Regards,
-drc



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

Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Paul,

On Jul 19, 2015, at 6:01 AM, Paul Vixie p...@redbarn.org wrote:
 there are no hoops here.
 people will register if they want to, and people will
 check the registry if they want to.

For the people who want to register, an exclusive registry explicitly creates a 
discussion for everyone but the first registrant, i.e.:

With a non-exclusive registry:

Them: Hey IANA, we're using .PAUL and here's the docs describing who we are 
and how.
IANA: OK. We'll add your information to the others already registered for that 
label.

With an exclusive registry:

Them: Hey IANA, we're using .PAUL and here's the docs describing who we are 
and how.
IANA: Um, sorry. Someone else is already using that label.
Them: But we really like .PAUL and we have deployed a zillion instances that 
make use of .PAUL
IANA: That's fine, but you're potentially creating an interoperability 
problem.
Them: So tell the other guys to stop, since we've been using .PAUL since the 
early 1700s.
etc.

This smells like a hoop to me.

 so: offering someone a chance to register that a conflict exists does
 not serve the purpose of advancing interoperability.

It doesn't address the interoperability of non-interoperable domain name 
overlays. It does advance interoperability in the sense of improving the state 
of knowledge that the non-interoperable domain name overlays exist, how they 
operate, who runs them, etc.

It seems to me that by making the registry exclusive, you're trying to put the 
IESG/IETF/IANA in the role of gatekeeper of the non-interoperable domain name 
overlays.

Regards,
-drc



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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Hugo,

On Jul 17, 2015, at 4:03 PM, Hugo Maxwell Connery h...@env.dtu.dk wrote:
 The goal here from the non-DNS people seems to be to have DNS type labels 
 (thus URI's)
 which are known to the recursive and authoritative resolvers to be outside of 
 DNS.

That appears to be the goal of some folks, however the insertion of strings 
into the Special Names Registry will not (of course) by itself result in 
recursive and authoritative servers.

 If it is known that .a to .z are such; why where they not used?  Perhaps they 
 should be
 publicized a little more.

They aren't -- my suggestion was to avoid bikeshed painting on the specific 
string to use for the not DNS TLD.

 Additionally, we a challenge with the certificate issuance for .onion,

For clarity, I was speaking of the string being used in Warren's ALT draft. 
I've already indicated support for ONION in the Special Names Registry for 
pragmatic reasons.

Regards,
-drc



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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Stephane,

On Jul 17, 2015, at 4:17 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 Well, even worse, what happens if name-your-next-OS-vendor decides
 to create a new dns-like protocol that uses .foo, does that mean
 that we should automatically block it?
 
 No need to speculate about what happens. It already happened, the
 vendor was Apple and the result was the registration of .local (first
 use of RFC 6761).

No. .LOCAL was not already in the root zone. .FOO is.

Regards,
-drc



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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Paul,

On Jul 17, 2015, at 9:51 AM, Paul Vixie p...@redbarn.org wrote:
 yes, but not with .ALT, which is a politically desirable gTLD name, and
 which allows the connotation of alternate DNS. i suggested .EXTERNAL
 because nobody will ever want it as a gTLD and because its connotation
 is unambiguously not DNS.

Given many of the names that were applied for, I would be quite hesitant to 
make assertions about what people would or would not want (or what would or 
would not be politically desirable) for new gTLDs in future rounds.  After all, 
we were talking about .FOO in this thread...

 seriously, i wouldn't object to warren's draft if the string he chose
 hadn't been .ALT.

I suspect any name chosen would have proponents and opponents based on their 
own assumptions and biases. Looking at the technical requirements, we'd 
probably want a string that would be unlikely ever to be requested and which 
wouldn't be significant/controversial to any particular subset of the 
community. A quarter-baked idea: perhaps instead of a single label that (may or 
may not) has significance of English, we could go with up to 26 'non-DNS' 
labels, i.e., .A ... .Z?

Regards,
-drc





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

[DNSOP] namespace control (was Re: Last Call: draft-ietf-dnsop-onion-tld-00.txt ...)

[David Conrad]

Stephane,

On Jul 17, 2015, at 4:23 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 I agree on the need for less friction, hence my interest in trying
 to find objective criteria. Lack of objective criteria pretty much
 guarantees the same sort of discussion and 'heavy process' you're
 complaining about.
 
 No, friction comes from the fact that some people see the IETF as a
 control center and not as a service, trying to use it to enforce their
 own views such as ICANN should have the right to decide for every
 string in the root.

As far as I am aware, the IETF has defined the domain name namespace and, via 
RFC 6761, has implicitly asserted it has control over that name space. To my 
knowledge, the IETF has delegated policy of creating top-level strings for use 
in the DNS, that is, the things that go into the root servers, to ICANN. One of 
the issues I see is that there is no clear criteria by which a particular 
string can be reserved (or pre-empted) by the IETF (as is the IETF's right) and 
which is constrained by ICANN's policies and processes.

This, of course, has no impact on folks who squat on names (at least until they 
decide they want/need to interoperate with the IETF-defined namespace).

However, trying to understand your perspective, I gather you don't see the IESG 
approval as a control point?

Regards,
-drc



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