[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Martin Schanzenbach]

On Thu, 2024-07-25 at 14:39 +0200, Philip Homburg wrote:
> > As hinted to in the CVE description, Thomas asked here where this
> > behaviour is defined exactly and did not receive a response that
> > fits this issue:
> > https://mailarchive.ietf.org/arch/msg/dnsop/X7ul3Updo4XP0EYdExuZ6pkp-Gk/
> > 
> > Yes, of course a stub resolver will have to sift through the CNAMEs
> > (especially if DNSSEC validation is supposed to be done).  But
> > where is the filtering between QNAME and received answers
> > explicitly
> > defined, exactly?
> 
> By and large, the IETF defines network protocols. The IETF is not
> good
> a defining APIs for network functions. And it is not part of its core
> mission.
> 
> So what happens after a stub resolver receives a response is mostly
> undefined. Low level C APIs were done in the past by the IEEE (POSIX)
> and more
> recent by the Open Group.
> 
> For example RFC 3493 is not an IETF standard, but the functions
> described,
> such as getaddrinfo, are part of the Single Unix Specification.
> 
> > I am pointing out that there is a root cause
> > for this CVE/bug and it may not be simple oversight. It very well
> > may be a gap in specification or missing security considerations
> > that could hit any future implementer of (stub) resolvers.
> 
> The gap is that there is no good standards organisation for APIs
> related to
> internet protocols. That is unfortunate. It is not clear to me who
> would
> have enough cloud to create one.

Are you trying to say that the behaviour of a validating stub resolver
is not in scope of the work on DNS(SEC)?
Because I was pretty sure it is.
See Thomas' post before on how separating validation from result
filtering (following the CNAME-chain) would be tricky to do outside of
the validating stub resolver (or only with significant overhead and re-
validation) for any implementation.

BR


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Martin Schanzenbach]

On Thu, 2024-07-25 at 14:11 +0200, Philip Homburg wrote:
> > I think this is the core issue behind the CVE and the filed bug.
> > Who is the "ultimate user"? And where is this expectation
> > formulated
> > exactly? I would believe that most applications using DNS libraries
> > such as dnsjava do not expect that they have to sift through CNAMEs
> > in the replies and filter according to their initial query.  So is
> > dnsjava in your opinion the "ultimate user" that is expected to
> > filter? If yes, "ultimate user" is an odd description because
> > dnsjava is a resolver implementation, whereas "ultimate user" to
> > me means application using a resolver (library/implementation).
> 
> The typical model is that of a library that implements a DNS stub
> resolver
> function. This library is expected to offer a function that takes a
> QNAME,
> QCLASS, and QTYPE as arguments and returns a set of resource records
> or an
> error.
> 
> If dnsjava implements the function of a stub resolver, then yes,
> dnsjava would
> be expected to sift through the CNAMEs. A stub resolvers speaks the
> DNS
> protocol and this is just how the protocol works.
> 
> 

As hinted to in the CVE description, Thomas asked here where this
behaviour is defined exactly and did not receive a response that fits
this issue:
https://mailarchive.ietf.org/arch/msg/dnsop/X7ul3Updo4XP0EYdExuZ6pkp-Gk/

Yes, of course a stub resolver will have to sift through the CNAMEs
(especially if DNSSEC validation is supposed to be done).
But where is the filtering between QNAME and received answers
explicitly defined, exactly?

> Obviously, you are free to define a new protocol that runs between a
> stub resolver and a recursive resolver. However, just compaining
> about the
> current situation is not going to change much.
> 

I am not complaining. I am pointing out that there is a root cause for
this CVE/bug and it may not be simple oversight. It very well may be a
gap in specification or missing security considerations that could hit
any future implementer of (stub) resolvers.

BR

> 
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org



signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Martin Schanzenbach]

Hi,

On Wed, 2024-07-24 at 17:36 +0200, Philip Homburg wrote:
> > Partially. I believe the DNSSEC validation and following the
> > CNAME-chain have to be implemented in the same routine.  This is
> > because to perform an authenticated denial of existence, you first
> > need to know which name and rrtype you want to prove does not
> > exist.
> 
> DNSSEC validation follows the CNAME-chain that is part of validation.
> 
> However, the ultimate user of the data also has to follow the CNAME-
> chain
> to avoid picking up unwanted additional records in the answer
> section.
> 

I think this is the core issue behind the CVE and the filed bug.
Who is the "ultimate user"? And where is this expectation formulated
exactly?
I would believe that most applications using DNS libraries such as
dnsjava do not expect that they have to sift through CNAMEs in the
replies and filter according to their initial query.
So is dnsjava in your opinion the "ultimate user" that is expected to
filter? If yes, "ultimate user" is an odd description because dnsjava
is a resolver implementation, whereas "ultimate user" to me means
application using a resolver (library/implementation).

BR
Martin

> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org



signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Martin Schanzenbach]

On 14.12.22 12:25, Paul Wouters wrote:
> On Dec 14, 2022, at 11:29, Eliot Lear  wrote:
> > 
> > 
> > We're off in the woods again.  Let's keep these two principles in mind:
> > 
> > The DNS resolution mechanisms are not expected to resolve, let alone secure 
> > names ending in .ALT.
> > How other resolution mechanisms secure names is their affair.
> I don’t think people disagree on this.
> 
> 
> >> On 14.12.22 17:13, Paul Wouters wrote:
> >> "bob.foo.alt" still squarely falls into "my" namespace
> >> It is indeed not “yours”. 
> > ... from the perspective of DNS.  Whether it is "yours" or "mine" from the 
> > perspective of GNS is a matter for GNS to resolve (for example).
> > 
> I was not talking from the perspective of IETF or DNS. The .alt is the Wild 
> West. Even GNS cannot claim exclusivity of a chunk of it. It is competing 
> with all the other unregulated namespaces.
> 

Then the draft should just say that. And not insinuate that as a dev I
can or should do something about that.

> Martin said he cannot help other alternative namespaces using the same 
> alternative namespace as he is using. I merely confirmed that and recommend 
> that if he is looking for exclusivity, he has to leave the Wild West behind 
> and go to a regulated space and play within the rules set out there to get 
> his exclusive namespace.
> 

If there is an obvious way to do it, the draft could give an example. Whatever 
you
mean by "go to a regulated space" should be given with clear example.
But as you well know, your wording is simply not without problems (IANA
SU-TLD registry is technically also/still a "regulated space" that would
fall within your wording).

My best interpretation of the sentence is that it low-key defines a fcfs-style 
self-governance of .alt. Which would also be fine, but I have an issue
with the unclear wording (i.e. I should not have interpret what the
meaning of "wholly responsible for dealing with collisions" is).

BR
Martin

> Paul
> 
> 
> 
> > Eliot
> > ___
> > 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] draft-ietf-dnsop-alt-tld-19

[Martin Schanzenbach]

On 14.12.22 10:19, Joe Abley wrote:
> Hi Martin,
> 
> On Wed, Dec 14, 2022 at 10:08, Martin Schanzenbach  
> wrote:
> 
> > "Developers are wholly responsible for dealing with any collisions"
> >
> > I think this is an impossible task and as a developer that is addressed
> > here I have to say that we cannot do that unilaterally for our
> > implementation/design because collisions occur when _others_ do
> > something.
> 
> I don't understand why you say this is impossible when it is what happens 
> today and what has always happened.
> 
> But perhaps I don't understand something about how "developers" is intended 
> to be interpreted. I agree it would be nice to clarify this sentence if it is 
> to remain.
> 

I think my main issue is the word "wholly".
The developer cannot be "wholly" responsible.
I can choose a label (e.g. "foo.alt") that is not already taken right
now.
But I cannot really do anything if somebody else comes along and uses
the same label. It is not my responsibility to mitigate the emerging
collisions. Or how is it expected that I do that? Change my design?
Bribe the other group?
"bob.foo.alt" still squarely falls into "my" namespace, so I cannot
write a single line of code to mitigate the collision.
Not only is it not really possible for me as a developer to do that, it
is also unlikely that I even notice this issue as a user.
Is the developer of a DNS server/resolver in any way responsible if
"alice.eth" collides with ENS? Or what do you mean by "this happens
today"?

BR
Martin

> Joe
> 
> >

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Martin Schanzenbach]

Hi Paul,

the draft lgtm. But, the passage regarding collisions because of
the missing registry now contains a regression IMO:

"Developers are wholly responsible for dealing with any collisions"

I think this is an impossible task and as a developer that is addressed
here I have to say that we cannot do that unilaterally for our
implementation/design because collisions occur when _others_ do
something.
Maybe you are talking about "groups" (as used in this paragraph) or the
"alternative name system community" here, which would make more sense?
This paragraph also uses both "groups" and "developers", and the
difference (to me) is not clear.

Maybe simply strike this sentence again?
Instead or in addition maybe a full acknowledment of this issue in the
security considerations, along the lines of

"
This draft does not define a registry or governance model for the .alt
namespace and as such developers/groups as well as users and applications cannot
expect unambiguous mappings from names with a ".alt"-TLD to a specific
alternative name space / name resolution mechanism.
This issue can be mitigated, for example, through the creation and use of a
registry by the alternative name system developer community.
"

Best
Martin

On 13.12.22 20:20, Paul Hoffman wrote:
> Greetings again. As you can see, Warren and I just updated the draft to 
> reflect the WG discussion at IETF 115 and on the list after that. At IETF 
> 115, the WG chairs said that they might move this to a second WG Last Call 
> soon.
> 
> In the discussion, there was lots of active disagreement about reducing 
> traffic to the root servers, particularly around what it would mean for 
> recursive resolvers filtering for .alt. One such proposal that came up was 
> scrapping this draft and moving to AS112, but there was little interest and 
> some strong pushback.
> 
> Thus, we did not include any proposed way to do this in the new draft, 
> although we did make a strong push towards methods resolvers could use that 
> would reduce root queries for names ending not only in .alt, but all other 
> non-existent TLDs.
> 
> --Paul Hoffman
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


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

Re: [DNSOP] the requested change to the dns-alt draft

[Martin Schanzenbach]

On 08.11.22 10:42, Eliot Lear wrote:
> As mentioned in the dnsop meeting the proposed change would be to remove the
> following sentences in Section 2:
> 
> OLD:
> 
>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.  For example, a group
>wishing to create a namespace for Friends Of Olaf might choose the
>string "foo" and use any set of labels under foo.alt.
> 
> OLD:
> 
>  They should attempt to choose a label that they
>expect to be unique among similar groups and, ideally, descriptive.
> 

IMO this should also be struk. If the WG decides to not govern the
namespace, then this implied or recommended governance is only
confusing if there is an effort to govern it externallly.
For one: Why only one label per group and not two? Three? Ten? All ASCII? It is
unclear what this means if the spirit of draft is what matters here.
So, I think this should be struk and what happens under .alt will
happen.
I do not think you can have both: Not set a governance inplace for the namespace
through a registry and set down (albeit not binding but implied)
rules/recommendations.

BR
Martin

> 
> This comes under the "do/do not" approach, and the WG has chosen to "do not"
> as far as a registry is concerned.
> 
> Regards,
> 
> Eliot

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

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

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

[Martin Schanzenbach]

On 23.10.22 10:50, Suzanne Woolf wrote:
> Eliot,
> 
> On Oct 23, 2022, at 2:15 AM, Eliot Lear mailto:l...@lear.ch>> 
> wrote:
> 
> 
> On 23.10.22 05:40, John Levine wrote:
> It appears that Eliot Lear  mailto:l...@lear.ch>> said:
> As a matter of practicality, a registry surely will be form.  It is
> simply a matter of whether the IANA will host it.  If the IANA does not
> host it, then by shifting it elsewhere this group is actually weakening
> the IANA function, and that would be sad.
> But trying to turn IANA and .alt into a junior version of ICANN would
> be much worse than sad.
> 
> Nobody is trying to do that.
> 
> 
> I believe the point is that it would happen if the IETF ran such a registry, 
> regardless of intent: if the IETF is deciding who gets to use names that look 
> like domain names, it's at high risk of walking directly into the conditions 
> that led to the creation of ICANN in the first place. The exception is names 
> under .arpa, which is explicitly under the administration of the IETF.
> Personally, I agree with the comment that several people have now made, that 
> such an attempt is likely to be fraught with legal and reputation risk. But 
> for the WG's purposes those comments are somewhat speculative.
> 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. Any 
> member of the IAB might be able to correct or add to this assessment, but 
> it's currently the chairs' understanding that we or the responsible AD should 
> request any liaison communications and presumably legal review after the WG 
> process concludes. (I understand frustration with this, but I also understand 
> the reasoning: if a draft doesn't have at least WG consensus, that 
> administrative machinery is not necessary.)
> 
> The chairs would like to hear it if anyone has anything new to say about such 
> a registry on its technical merits, including specific registry policy and 
> operational challenges with administering it if the non-technical risks could 
> be managed.
> 

In my opinion lots of technical justifications were given in the various
threads and those were not really addressed or refuted in any way but the
mentioned "non-technical risks" and "out of scope for dnsop" highlighted.
At the same time it appears to me that those risks do not (?) seem to manifest
themselves for .arpa. Is there an explanation or an indication why this would be
the case for .alt?

BR
Martin

> 
> Thanks,
> Suzanne
> 

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

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

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

[Martin Schanzenbach]

On 21.10.22 18:48, Tim Wicinski wrote:
> >
> >
> > Rather than placing "alt" in the TLD position, I think it might be better
> > as a scheme modifier: https+alt://...  This is a common pattern  for
> > modifications to URI schemes (c.f. git+ssh://), and informs the software
> > that this URI is special without overloading the DNS namespace.
> >
> >
> 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
> 

I am actually surprised by this as the primary concern reason for
a possible conflict was that the names in GNS and DNS can be conflated
by the user.
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?
It is as if we are chasing a moving target where the primary pont of
contention always seems to escape us. The goalpost seems to be moving.

BR


> tim

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

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

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

[Martin Schanzenbach]

On 20.10.22 12:05, Brian Dickson wrote:
> On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear  wrote:
> 
> > Hi,
> >
> > First, I would like us to continue to consult on the registry matter at
> > least through the London IETF, and would ask the chairs for some time in
> > London for this purpose.  I would also be available for side meetings
> > with any interested party, before or during the IETF.  If people would
> > like, we can grab a room for this purpose, if we can do so in the
> > morning so that Martin can participate remotely (he is far to the east
> > of London).
> >
> > As a matter of practicality, a registry surely will be form.  It is
> > simply a matter of whether the IANA will host it.  If the IANA does not
> > host it, then by shifting it elsewhere this group is actually weakening
> > the IANA function, and that would be sad.
> >
> 
> I spent quite a bit of time in the last couple of days reading all the
> threaded posts, as well as the two relevant drafts: the alt-tld one, and
> the gns one.
> 
> The latter (quite a large document, with lots of important nuances
> including additions related to dotALT conceptually) has some major
> challenges for whether/how it would even fit in such a registry.
> 
> I fear those challenges mean that GNS simply won't be possible to properly
> have registry entries, and without GNS, or possibly using GNS as an
> alternative namespace example, the registry makes no sense.
> 
> Here's the problem that the GNS draft includes (and maybe doesn't highlight
> well enough): GNS is not a namespace. There is no central administration of
> namespace(s) under GNS, or even a central anything. GNS has no global
> "anything", and no concept of global per se. At best, entities can publish
> their own equivalent of "root zone"s that assert to a population of
> consumers as to what namespace entities exist, without any authority over
> any aspect of namespaces. It is anarchy embodied.
> 
> Everything in GNS relies on mappings, and "petnames". While those can
> potentially be placed under some parent label, the existence of such a
> parent label (either ".alt" or ".gns.alt") is neither necessary nor
> sufficient to achieve any kind of global consistency.
> 
> There is also no ability to enforce any rules on using any parent label, or
> to prevent conflicting intra-GNS "petnames", or to prevent conflicts
> between GNS "petnames" and any other TLD namespaces (including DNS). GNS
> allows anyone (with local context) to instantiate any namespace (tree
> anchored anywhere), including instantiating new TLDs (contrary to ICANN's
> current role as exclusive entity responsible for administering the DNS
> namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs,
> or anything beneath those.

In GNS, you can expect that there will be default configurations of TLDs
(e.g. example.gns.alt with the alt suffix).
Those defaults (=root) will have to be governed similarly to what ICANN
does. And rules will, of cource, have to be enforced contractually, not
through the protocol. As is the case with DNS.

Yes the user can create local mappings, but you can do the same in DNS
(split horizon, RFC8375 etc etc)

> 
> The question that hasn't been addressed is, who SHOULD actually do
> registrations in this proposed registry?

Experts well versed in name system design?

> I don't believe the authors of the GNS draft have the actual authority to
> do so, as they do not administer any name space per se.

Not exclusively, no.

> If someone did want to instantiate a local namespace, or a kind-of, sort-of
> bigger-than-local namespace (with delegations) as the GNS draft generally
> describes, would they be the entities registering their namespace?
> Those namespaces are not required to be unique within GNS, as well, so even
> having an FCFS registry would not mirror the reality of GNS. There could
> easily be 1000 different instances of "lotr.gns.alt" within GNS, each with
> its own zone(s) with names like "frodo", "bilbo", "gandalf" etc.
> 

I do not understand the question. Isn't that exactly how home.arpa
works?
Names in .home.arpa are only locally unique. In practice, GNS will
actually have unique(r) deployments than .home.arpa.
But even if it does not, calling global uniqueness/consistency a
requirement is calling home.arpa not a namespace.

BR
Martin

> And if the GNS draft isn't included in the registry (because it does not
> administer ANY namespace), I don't see how the registry can function as
> envisioned.
> 
> It may possibly be reduced to definitions: what is a namespace? If it is
> not something that is global and consistent, I don't think it could
> accurately be called a namespace.
> 
> It basically suffers from the "Woody Allen" problem ("I wouldn't want to be
> a member of any club that would accept me as a member.")
> Creating a registry as a place to put GNS would be self-contradicting if
> GNS cannot be added to the registry.
> 
> Brian
> 
> 
> 
> >
> > Two more points below.

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

[Martin Schanzenbach]

On 20.10.22 01:31, Paul Hoffman wrote:
> (Well, *that* will teach me not to go on vacation and not look at work email. 
> Or maybe I should do that more often!)
> 
> > The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
> > draft-ietf-dnsop-alt-tld.
> > 
> > We’ve reviewed the current draft closely and have some concerns that we 
> > feel need to be resolved before any effort to move the draft forward. 
> > (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
> 
> Warren and I will put out a new document before the draft submission cutoff 
> next week to resolve the concerns given in the message and thus move the 
> draft forward.
> 
> > 1. As far as I can tell, this draft does not comply with RFC 6761.
> 
> Correct.
> 
> > This is a problem for two reasons. First, this creates a process problem in 
> > that RFC 6761 is the standards-track document that specifies how the SUDN 
> > registry is to be administered, so a request that doesn’t meet the 
> > requirements in 6761 can’t (or at least shouldn’t) go into the registry. 
> 
> As we have seen, the IESG seems happy to publish standards-track documents 
> for items that will go in the Special-Use Domain Names registry that do not 
> comply with RFC 6761. There is no reason to believe that this draft will have 
> a different fate.
> 
> Having said that, we can add the text required by RFC 6761 in a way that 
> meets the 6761 requirements that the IESG has been ignoring, but doesn't say 
> anything more interesting than what is in the draft now. The IESG can then 
> decide if it meets their requirements.
> 
> > RFC 6761 section 4 asserts:
> > 
> > The specification also MUST state, in each of the seven "Domain Name 
> > Reservation Considerations" categories 
> > below, what special treatment, if any, is to be applied. 
> > 
> > The alt-tld draft ignores this MUST, without explanation (unless I missed 
> > it).
> 
> That's a fair point; we can add that.
> 
> > The substantive issue is that the questions in Section 5 are there to make 
> > sure there’s a full description of the expected handling of a proposed name 
> > by the assorted components that take part in DNS operations and protocol. 
> > The draft answers at least some of the Section 5 questions, but the answers 
> > are largely implied.
> > 
> > For example, the draft says that DNS resolvers seeing .alt names "do not 
> > need to look them up in the DNS context”, but a big part of the point of 
> > codifying these names is the assumption that queries will leak and DNS 
> > servers will see them.
> 
> Exactly right. Because .alt will not be in the global DNS root, those 
> requests will be treated like every other request with a TLD that is not in 
> the global DNS root: resolvers do not need to look them up in the DNS 
> context. When I became co-editor on the draft, I removed Warren's 6761ish 
> text because  saying "treat this like every other name". I see now that I 
> should have instead fixed the 6761ish text; we'll do that soon in the next 
> draft.
> 
> > (“Do not need to” isn’t even “SHOULD not”.)
> 
> Exactly right. More importantly, it is not "MUST NOT". In the case of a TLD 
> that is not in the global DNS root, RFC 1035 is already completely clear, and 
> this document should not update RFC 1035. RFC 6761 does not require 
> SHOULD/MUST language.
> 
> > It’s implied that .alt is simply not in the public DNS root zone
> 
> That is not an "implication", it is explicit because the zone will be part of 
> the RFC 6761 registry. We will add a redundant sentence in the introduction 
> to make this clearer.
> 
> > and the root servers (or better yet, any intermediate resolver) should 
> > answer “name error”/NXDOMAIN for such queries.
> 
> Can you show where there is that implication? If so, we will certainly nuke 
> it from the draft. .alt should be treated by all systems just like any TLD 
> that is not in the global DNS root, and this draft should not update RFC 1035 
> to list the dos and don'ts for those systems. This is the same for every 
> other TLD in the 6761 registry.
> 
> > But this should probably be said explicitly, because people who configure 
> > DNS servers and services shouldn’t have to guess what’s being implied here. 
> > (The WG discussed the possibility that such queries should be blackholed 
> > and not answered at all, which is in some ways an obvious answer. 
> > Clarification of why this was discarded might also be helpful.)
> 
> I fully disagree that adding a section of "something we discussed that we 
> decided not to do" will be helpful: it will be confusing.
> 
> > So, the current draft isn’t meeting the requirements for the registry, and 
> > also doesn’t clearly answer substantive questions about what DNS operators 
> > are expected to do.
> 
> It meets the requirements of the IESG; it does not meet the requirements of 
> the RFC because those requirements in that RFC is being actively ignored (for 
> good reason, 

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

[Martin Schanzenbach]

On OCT17@11:53, Paul Wouters wrote:
> On Mon, 17 Oct 2022, Eliot Lear wrote:
> 
> > Let's please leave Internet lawyering to lawyers.  If people want a
> > legal opinion on this draft, the IETF does have resources for that.
> 
> But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
> into ICANN territory.
> 
> > We cannot assume that DNS will forever be the only Good approach and
> > that all others will forever be Bad. Given that, we as a community are
> > obligated to search for better, and to try new things.
> 
> Sure. The IETF method is to start a BoF, form a WG, do your thing. See
> Speedy/QUIC. See SSL/TLS, See PGP/OpenPGP.
> 

I am a bit confused now. Let's say there is BoF and, eventually, a WG.
How is that WG supposed to "do it's thing" with respect to alternative
name spaces if there is literally no way to safely use and test it's
results alongside DNS?
Wouldn't such a WG need the .alt as a prerequisite to any actual work or
at least have .alt as its first work item?
Would especially dnsop not care if another WG starts defining a protocol
that is able to resolve names that look like/are DNS names because it is
designed to possibly replace it in the future?

BR

> > There exist many registries for things the IETF doesn't recommend.  One
> > need look no further than TLS 1.3 crypto-suites as an example.
> 
> These are not equivalent. For TLS to interop with non-IETF stuff, they
> need codepoints for within the IETF defined TLS protocol. They are not
> replacing TLS with something else on port 443. (and on top, non-TLS WG
> entries are marked as NOT RECOMMENDED)
> 
> > No matter what we say in the ALT draft, someone could burden the IETF
> > with a new draft.  People do so every day.  If it gains sufficient
> > support, it would have to be at least considered, no matter the topic.
> 
> Sure, but "replacing DNS with something else", would definitely not be
> in dnsop, or the ISE, but via BoF and a new WG. I dout any of the
> alternatives would follow that approach, especially as I cannot see us
> starting a new (replacement or not) naming scheme where there is a new
> landrush for domain names with all of its ICANNlike associated problems.
> 
> I can see DNS 2.0 that replaces all of DNS, but would still hook into
> the existing EPP and RRR ICANN model though. Again, that would not go
> via the ISE path.
> 
> Paul
> 
> ___
> 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] Possible alt-tld last call?

[Martin Schanzenbach]

On OCT17@07:11, Joe Abley wrote:
> On Oct 16, 2022, at 23:03, Christian Huitema  wrote:
> 
> > The main problem with "giraffe.org" and similar is that the subdomains are 
> > leased, not owned. A glitch in the renewal, and they are grabbed by some 
> > domain catcher and redirected to "my sexy giraffe" or some such.
> 
> On the face of it that seems like a compelling endorsement of the idea, that 
> the biggest risk is one that has proven not to be a significant problem in 
> aggregate for other lesser-known and marginal uses of the DNS such as, oh I 
> don't know, the web or e-mail.
> 
> The risks in this case are even lower than in those use-cases, since a 
> one-time payment secures a renewable ten year lease which is enough to exceed 
> the effective lifetime of any alternative naming scheme seen to date by quite 
> some margin,

Technically, GNS celebrated its 10th birthday in 2022 ;)
But back to business: You cannot think both that alternative name systems are
fleeting trends and at the same time are a serious threat to DNS namespace
consistency.
That does not make sense.

> 
> Despite your endorsement, however, I suspect people will continue to ignore 
> this approach in favour of squatting on top-level labels, a fate that seems 
> likely to be replicated faithfully with alt. That was the point I was 
> apparently not able to refrain from repeating, really.
> 

I know that is a valid opinion to hold and is difficult to refute
without epiric evidence. However, such a PoV also requires a lucid conclusion 
as consequence.
For example, if it is consensus that .alt is a pointless endeavour because
all/most/a lot of alternative name systems will squat TLDs, the question
becomes: Why do you they squat a TLD?

I think that most alternative name systems squat a specific TLD as a
unique identification. They do not try to squat and replace DNS on purpose.
At the same time I can think of no alternative name system that
could not technically squat on the whole DNS namespace in theory.
In conclusion (and I am repeating myself): You have the unique chance
here to funnel this phenomenon in safe and manageable bounds using .alt.
For that you need to understand why the squatting is happening.

What would you rather have? A document you can point to where you can
tell sqatting name systems that they are "doing it wrong" or a document
that cannot hope to have any effect whatsoever on alternative name systems
because it simply reserves a TLD and tells DNS implementations to "don't
go there".

BR
Martin


> 
> Joe
> ___
> 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] Possible alt-tld last call?

[Martin Schanzenbach]

On 16.10.22 12:03, Brian Dickson wrote:
> On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear  wrote:
> 
> > Hiya!
> >
> > Thanks to Suzanne and the chairs for moving things forward.  On this point:
> > On 16.10.22 17:22, Warren Kumari wrote:
> >
> >
> >
> >> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> >> basis that having the IETF “recognize” (if only by recording) such
> >> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> >> supposed recognition of alternate (non-DNS) namespaces as reservations of
> >> the namespace from the shared, common DNS root. We’re still being denounced
> >> in certain corners for .onion. It might be good to have a paragraph calling
> >> out specifically why .alt is not a delegation of a TLD from the DNS root by
> >> the IETF, even though it looks like one. (We didn’t invent this problem,
> >> because we didn’t make the decision that top-level domain labels should be
> >> used by other protocols in a way that led to confusion. But let’s not
> >> propagate it.)
> >>
> >
> >
> > Yup. This is (IMO) the area of the draft where the consensus was the least
> > clear. I still think that it would be useful to have a *purely*
> > informational list saying "Group A says it is using string B and their
> > documentation is at https://foo.example.com; and "Group X also says that
> > it is using string B and their documentation is at https://bar.example.
> > net". Enough people have pushed back on asking
> > IANA to host this that I think that it should be removed (and I was the one
> > most strongly arguing for it). Obviously it's the DNSOP WGs decision, but I
> > won't argue for keeping it :-)
> >
> >
> > A few points:
> >
> > First, absent at least an FCFS registry there will be no ability to
> > programmatically switch against the label.  If multiple entries exist this
> > is particularly painful.  If no registry exists, then perhaps multiple
> > unofficial registries will pop up and we're in the same boat.  Let's not
> > have that.  That programmatic switch is important.  It allows multiple
> > naming systems to co-exist all the way to the level of the application
> > (e.g., end-to-end) without any ambiguity being introduced.
> >
> > Second, people have been concerned about the possibility of vanity
> > registries.  Requiring an RFC puts an end to that.  I don't think we want
> > to *endorse* any particular approach, but IANA maintains many registries,
> > and nobody has ever taken any of their entries as endorsements.
> >
> > I suspect most of the burden here will fall on the Independent Submissions
> > Editor (currently me) with maybe a little falling on the IRTF, because I
> > doubt we will see a lot of consensus in the IETF for alternate naming
> > systems.  I think some are worried that this will change the nature of the
> > IETF, but to me this confuses names with naming systems.  Creating a naming
> > system is no mean fete.
> >
> > To address the possibility that we DO see a lot of requests, we can create
> > different types of failsafe mechanisms.  They could be any or all of the
> > following:
> >
> >1. If more than one assignment occurs within a year, no assignments
> >may occur in the following year.
> >2. After N assignments, the IAB MAY suspend this procedure if they see
> >evidence of abuse, and refer the matter back to the IETF for further
> >consideration.
> >3. This group can always amend the document based on whatever
> >experiences we see.
> >
> > I'm confident that there are other approaches as well.
> >
> The main problem that a registry is intended to solve, is the collisions
> among apex labels of various alternative naming systems.
> 
> This problem is rooted in the "naming system group chosen" aspect.
> 
> I think there is a relatively simple technological solution to the naming
> system label collision problem.
> 
> Consider what the registry would basically consist of:
> 
>- semantic label (what would currently be used as the apex label, e.g.
>"foo.alt")
>- project URI
> 
> Note the following characteristics of these elements:
> 
>- The apex label is a "switch", but is otherwise not actually used (or
>meaningful) within the naming system (i.e. it is an arbitrary element, and
>usage is basically limited to a binary "compare" to any input to the
>non-DNS resolution system of the project)
>- The URIs of different systems will, by definition, be distinct (i.e.
>unique to the system)
> 
> The obvious (to me at least) solution is to generate the apex label
> programmatically, e.g. encode the URI as the label to be used as the
> switch, rather than the name system's potentially ambiguous semantic name.
> For example, using a hash function, such as sha2-256, with output encoded
> as base32hex.
> (This is just an example; any suitable function that takes URI as input and
> produces an ASCII DNS-compatible label as output would 

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

[Martin Schanzenbach]

Hi,

FWIW: Triggered by the ADs mail on this ML and after re-reading -17 I would
like to make clear that the current draft looks pretty good to me with minor
nits as mentioned in this thread.

Br
Martin

Excerpts from Paul Hoffman's message of 2022-08-23 18:52:18 +:
> Thanks again for all the discussion; it is helping the document. You can see 
> from the diff at 
>  that we have 
> tightened the language, particularly around what is display format and what 
> is wire format. More comments are of course welcome.
> 
> --Paul and Warren


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

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

[Martin Schanzenbach]

Excerpts from Brian Dickson's message of 2022-08-03 18:09:32 -0700:
> Top-reply (not apologizing for doing so, either):
> 
> If I read the actual draft correctly, it is _not_ intended to be a DNS
> drop-in replacement.
> Instead, it is meant to be an _alternative_ to DNS.
>

It is intended to resolve RFC8499 "domain names".
It could be used as an alternative to DNS to resolve DNS domain names.
If you want, we can make that clearer in the draft.
Actually, I have been pondering over that the last few days.

> So, why even use DNS-compatible label strings? That is an obviously
> conflict-causing choice, which is entirely avoidable.
> 

Any (most?) domain names are DNS-compatible label strings.
How come that is no problem elsewhere?

> Most of the references in this thread to IETF documents or ICANN documents,
> are within the context of DNS-compatible naming schemes, that themselves
> lead to such conflicts.
> 
> The obvious choice, to me, would be for GNS to use a DNS-incompatible
> suffix, that is short and memorable in some way.

Please. The obvious choice is RFC6761.
You are hand-wavingly proposing to cripple the usability of the names
used in alternative name systems below which would also require us to define
in the draft what we mean by "name" instead of being able to point to
RFC8499.
How is that better than an established process that was applied very
recently. Twice.

> 
> (That rules out .alt  and something.arpa obviously, and probably anything
> that starts with underscore or even contains the asterisk character).
> 
> So, pretty much pick any other UTF-8 string that is not a potential DNS
> label, and is easy to type, short, and unambiguously "NOT DNS".
> 
> Choice is left as an exercise to those wanting to paint the bike shed.
> 
> The mnemonic of "!" would be clear, meaning "not", or possibly "~",
> which is a different kind of "not", or even "^" as another "not".
> Other non-shift key candidates ",/=;" or any of "[]\`'" (but less favorable
> due to interaction with the unix shell).
> Similar one-character shift-key options have various
> pros/cons: @#$%&():"{}|<>?"
> Basically, pick any of the above, but not any of ".+@-_*", and you are good
> to go.
> If it makes a DNS resolver complain, it is a good choice.
> (Even "**" would be okay, as it is not a legal DNS label.)
> 

The reason is usability and the often in this discussion invoked "user
expectation". A "." is just a lot easier to type, everything you propose
not only looks awkward but is also difficult to type.
Not to mention that a lot of applications that use domain names
expect domain names.

> At which point, no conflict exists, ISE and DNSOP are all happy, your draft
> can be published (with the proviso that this suffix MUST be used always)
> and we can stop having this discussion, permanently.

Should that[1] be(come) consensus/the outcome of the IESG review I think we need
to discuss internally if we'd rather take the conflict as that would
significantly change the purpose of GNS.
Such an outcome would likely also stop this discussion permanently I
think. I guess you should get rid of RFC 6761 as well then at some point.

Please note that it is not us requesting a sub-namespace or TLD with our
draft.
Our current version of the draft proposes a technical protocol to resolve 
domain names as defined in RFC8499.
Whether a deployment uses a sub-namespace or not is not really relevant.
In my opinion (but that is something that could be discussed), it is also a lot
cleaner to define the protocol in such a
way and not assigning a namespace along with it.
But, we would be happy to accomodate concerns regarding user safety
and namespace consistency *within reason*.
Note that .alt would not make it clear for an implementation if a given
name can or should be resolved in GNS as currently there is no registry for the
subdomains proposed.
So, while being adamant that this is a problem in DNS, it seems odd that
it would not immediate also be a concern for GNS.
In practice, I concede, this may not be a problem.
But in practice, I think the "DNS namespace in danger" discussion is smilarly 
not
a problem.

Anyway, going to ICANN in order to collect a TLD is not a reasonable process for
publishing our draft.
We would not even know what the process would be (after the RFC? before
writing it? While writing it? What if ICANN denies a request? All the
work is moot?)
Similarly using "www.example.com!gns" et al. is not a reasonable change.
As that impairs usability and is incompatible with applications that
expect domain names.

BR

[1] "that" being that alternative name systems are not welcome and are
required to bake into their technical spec

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

[Martin Schanzenbach]

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

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

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


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

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

[Martin Schanzenbach]

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

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

BR
Martin

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


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

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

[Martin Schanzenbach]

Hi,

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

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

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

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

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

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

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

g.nrs?
e.nrs?

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

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

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

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

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

BR
Martin

> ~Peter
> 

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

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

[Martin Schanzenbach]

Excerpts from Stephane Bortzmeyer's message of 2022-08-01 17:29:38 +0200:
> On Mon, Aug 01, 2022 at 02:31:48PM +0200,
>  Independent Submissions Editor (Eliot Lear)  wrote 
>  a message of 89 lines which said:
> 
> > Whether that means using TLD labels that begin with _ or whether
> > that means suffixing them with ".ALT", I leave to you experts to
> > sort.  I do agree with Martin that it would be helpful to have some
> > registration of names so that conflicts between name spaces can be
> > avoided.  This would also encourage formal documentation of those
> > projects.
> 
> I agree and I think publication of these drafts would be a good idea
> (may be with status Experimental since, as Joe Abley said, there is
> clearly no IETF consensus). Note that I am skeptical about their use:
> most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
> not read the RFC and, if they do, won't follow it. But at least we
> will be able to say that we tried and we have a solution (and not a
> ridiculous one such as "pay ICANN 185 000 US $").
> 

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.

---

Reasons:

With our draft you would have one system which references
this "solution", as opposed to specifying solution looking for a problem.
That being said, since our current draft is Informational, I do not
think the existence of an ".alt"-RFC would significantly alter our protocol
implementation or deployment for now.

There is just no benefit for a name system in using it. The benefit lies
solely with DNS and the existing infrastructure.
After all, a new "Standards Track" name system that could potentially be used as
a DNS-drop-in would not be designed or specified using ".alt", right?
That would be like requiring DoH servers to only process names under ".doh.alt".
But they do not and never have, because even though the technical
resolution process is different, it is still the same namespace.
So what if (yes I know very theoretical) ICANN and TLD-registrars
publish their zones in GNS? Is it still www.example.com.gns.alt or would
it be the _same_ namespace managed by the _same_ authorities resolved
through GNS and become www.example.com?
If the latter is the case, what is the purpose of ".gns.alt"?

Further, migration becomes more difficult with ".alt".
For example, is it possible to get X.509 certificates issued for those domains?
Not to mention that users have to deal with (significantly!) longer names as 
you need a
second-level indicator on which name system is asked for.
e.g.:
www.example.com.gns.alt vs
www.example.com

So unless IESG actually finds a conflict and we have to put it in the
specification as a requirement, I don't see why we (GNUnet) should use it
at all in practice for our implementation.
Since our draft is Informational, I also do not see any urgency.
But, I think it makes sense to have provisions in the draft that
discuss this issue and show how *in a deployment* this possible namespace
ambiguity may be avoided using ".alt" independently of how the currently
documented implementation operates.
Maybe we would add a ".alt"-RFC-compliance configuration option that
limits resolution to ".gns.alt" etc. (there would be no reason for any
user to set it, realistically)

Really, though, all this was just a matter of following RFC6761 IMO...

BR
Martin


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