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

[Timothy Mcsweeney]

> On 10/24/2022 10:17 AM EDT Ben Schwartz  
> wrote:
> 

> >- How might or should this be reflected in the browser bar?
> >
> > Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
> 
> >


Does the foo+alt:// uri only go to the .alt non-dns namespace?  or does it go 
to both dns and non-dns namespces at the same time?

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

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

[Paul Hoffman]

On Oct 24, 2022, at 1:23 PM, Brian Dickson  
wrote:
> What this points out is that ".alt" is intended to protect DNS (at the root 
> at least) from the effects of other namespaces.

This seems quite inaccurate. Where in the current draft does it hint at that 
statement? If it is there, we should certainly remove it.

> It is not (or at least has not been explicitly established for) use by other 
> namespaces to protect themselves from errors like this.

Yes, definitely.

--Paul Hoffman



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

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

[Brian Dickson]

On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters  wrote:

> On Mon, 24 Oct 2022, Brian Dickson wrote:
>
> > Just to expand on this idea (which I quite like), the original AS112 was
> enhanced to handle new/arbitrary names, so
> > that AS112 operators don't need to do anything to support being a sink
> for new domains.
> >
> > This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
> target for use via DNAME.
> > (The DNAME bit is so there isn't a delegation for which the AS112
> operator would need to have a zone configured.)
> >
> > Using this via the root zone would be a new kind of entry for the root
> zone, but is otherwise non-controversial
> > (IMHO).
> > It would basically look like:
> >   alt. DNAME empty.as112.arpa
>
> this is dangerous. Anyone who runs an as112 node, or an attacker who
> compromises one, can then serve a "real" .alt to a percentage of
> queriers. Imagine millions being lost in some cryptocurrency .alt
> non-dns scheme.
>
>
This is accurate. It is dangerous to other namespaces if they don't take
appropriate safeguards.

What this points out is that ".alt" is intended to protect DNS (at the root
at least) from the effects of other namespaces.

It is not (or at least has not been explicitly established for) use by
other namespaces to protect themselves from errors like this.

In the jargon of mathematics, "alt" is necessary, but not sufficient.

Any namespace that would fall under the "please use .alt" umbrella, would
be wise to build into the protocol(s) or implementation(s) some guard-rails
against leakage.

So, another reason for "MUST NOT", but perhaps out of scope for dnsop
itself to say (other than to indicate,  "here be dragons".)

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

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

[Ben Schwartz]

On Mon, Oct 24, 2022 at 12:47 PM Timothy Mcsweeney 
wrote:
...

> You can't use the "+" in the scheme component of the uri scheme.  It's a
> reserved sub-delim.
>

RFC 3986, Section 3.1:

   Scheme names consist of a sequence of characters beginning with a
   letter and followed by any combination of letters, digits, plus
   ("+"), period ("."), or hyphen ("-").

Worked example: https://www.rfc-editor.org/rfc/rfc8323.html#section-8

I'm not a URI expert but that seems pretty clear.


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

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Ben Schwartz]

Thanks for this update.  I think the DoC draft is much improved by this
separation.

On DoC:

0. Why isn't DoH via CoAP gateway sufficient?  The draft should explain.
If the answer is message size overhead, please put a number on it.

1. The TTL rewriting proposed here is notably different from DoH.  I think
I understand the reason for the divergence but it's not explained in the
draft.

2. Does DoC live at a URI path?  I assume it does, but I couldn't tell from
the draft.  If so, consider defining a default path, if this is a common
practice in CoAP.  In HTTP, default paths are generally forbidden, so DoH
doesn't have one.  This has been inconvenient.

3. I recommend adding a section describing how to bootstrap DoC in a
SVCB-DNS record.  I think this may require you to allocate a new ALPN ID
for CoAP/DTLS (e.g. "coap-dtls").



I don't think the "compact DNS" proposal is worthwhile, at least in the
current framing.  The normal DNS message format is already quite well
optimized for compactness, and recursive resolvers rarely return something
that is unlikely to be useful.  I think this draft would have a really
minimal impact on the typical message size distribution.  Also, DNS is
typically used to bootstrap something else, so a small savings in DNS
overhead becomes negligible for the system as a whole.

The draft also seems to contain a misconception about what is optional in
CNAME handling: there is no situation in which a stub resolver will chase a
CNAME chain.  That is always the recursive resolver's job.

On Mon, Oct 24, 2022 at 2:25 PM Martine Sophie Lenders <
m.lend...@fu-berlin.de> wrote:

> Hi!
>
> Am 21.09.22 um 21:31 schrieb Ben Schwartz:
> > Preparing a separate document on compact DNS seems like a fine start to
> me.
>
> We just published Version -01 of the draft [1]. The most significant
> change in regard to this discussion is that Section 5.1 was now moved to
> its own draft [2]. We are happy to discuss this, e.g., in the DNSOP WG
> meeting or F2F during a break at IETF 115, if the WG meeting agenda does
> not allow for this anymore.
>
> The full listing of changes to the DoC draft can be found in Appendix A
> of [1].
>
> Cheers
> Martine
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/
> [2] https://datatracker.ietf.org/doc/draft-lenders-dns-cns/
>
> >
> > On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders
> > mailto:m.lend...@fu-berlin.de>> wrote:
> >
> > Hi Ben, Hi Carsten,
> >
> > thanks for your suggestions, Ben! It seems a good idea to clarify
> > options for compactification of DNS messages in a separate document,
> > since the compactification is indeed not bound to CoAP. We will
> > prepare such a draft until the cut-off for IETF 115, so we can
> > discuss whether we keep or remove Section 5.1 at the IETF meeting in
> > London. Would that work for you?
> >
> > I tend to agree with Carsten. At least with the current wording (or
> > the proposed), the restatements may lead to confusion, but some
> > guidelines for the constrained use case should IMHO be part of the
> > document, even if only in reference to the new document proposed.
> >
> > Best
> > Martine
> >
> > Am 20.09.22 um 18:17 schrieb Carsten Bormann:
> >> I think we are falling into the restatement antipattern.
> >>
> >> This antipattern happens when documents restate mandates from
> >> their references, invariably creating confusion if this is just a
> >> restatement or actually new normative text that replaces or
> >> updates text from the dependency. Don’t do that.
> >>
> >> Examples can be put into their own section and clearly marked as
> >> such.
> >>
> >> Grüße, Carsten
> >>
> >> Sent from mobile, sorry for terse
> >>
> >>> On 20. Sep 2022, at 17:12, Ben Schwartz
> >>> 
> >>>  wrote:
> >>>
> >>> 
> >>> Martine,
> >>>
> >>> Thanks for the proposed updated text regarding CNAMEs.  I agree
> >>> that it is an improvement, but I still think it would be better
> >>> to omit entirely.  By writing that implementations SHOULD follow
> >>> RFC 1034, you imply that they are permitted not to, which seems
> >>> objectionable.  I think it would be much clearer to simply say
> >>> that use of DoC does not alter the DNS message contents.
> >>>
> >>> I feel similarly about the Additional section.  If you think that
> >>> it would be useful to deviate from ordinary practices regarding
> >>> the Additional section, I think this should be in a separate
> >>> draft on compact DNS responses, not coupled to DoC.  For example,
> >>> such compactification might be even more relevant to UDP Do53
> >>> than to DoC.
> >>>
> >>> --Ben
> >>>
> >>> On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders
> >>> mailto:m.lend...@fu-berlin.de>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Sorry 

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

[paul=40redbarn . org]

Either we worry about impact on the root servers and consider not reserving the 
name at all because of infinite peaks through ignorance of legacy software... 


... Or we worry about it and consider doing something about it and decide 
whether what we can do will be good enough ... 


... Or we just decide not to worry about it at all. 


We should choose exactly one of those paths. Right now the debate has them all 
in a blender set to Frappe. 


p vixie 


On Oct 24, 2022 12:09, Paul Hoffman  wrote: 

The discussion about AS112 changes the document from "don't ever put this in 
the root zone" to "put this in the root zone this special way". 

I believe the former is wy easier than the latter, particularly for the 
very limited used we expect this name to have. 

--Paul Hoffman 

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

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

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

[Paul Wouters]

On Mon, 24 Oct 2022, Brian Dickson wrote:


Just to expand on this idea (which I quite like), the original AS112 was 
enhanced to handle new/arbitrary names, so
that AS112 operators don't need to do anything to support being a sink for new 
domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa" target 
for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator 
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root zone, 
but is otherwise non-controversial
(IMHO).
It would basically look like: 
  alt. DNAME empty.as112.arpa


this is dangerous. Anyone who runs an as112 node, or an attacker who
compromises one, can then serve a "real" .alt to a percentage of
queriers. Imagine millions being lost in some cryptocurrency .alt
non-dns scheme.

Paul

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

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

[Paul Hoffman]

The discussion about AS112 changes the document from "don't ever put this in 
the root zone" to "put this in the root zone this special way".

I believe the former is wy easier than the latter, particularly for the 
very limited used we expect this name to have.

--Paul Hoffman



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

Re: [DNSOP] [Ext] 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?

[Joe Abley]

Op 24 okt. 2022 om 14:18 heeft David Conrad  het volgende 
geschreven:

> Given the AS112 approach doesn’t result in code change, would you be ok with 
> using it with .alt?

As Brian mentioned, there are two AS112 approaches. One involves some amount of 
lame delegation, and the other involves DNAME in the root zone. 

I think DNAME in the root zone is a lovely idea and I would very much like to 
see some junk queries handled that way, but it's worth remembering that it does 
involve a new and exciting RRTYPE in the root zone and presumably, therefore, 
multiple years of meetings before it can happen, because Root Zone.

Perhaps there's no rush and meetings are fine. 

I also think trying hard not to send the queries and simultaneously 
acknowledging that there will be some mess so we still need to stock up on 
cleaning supplies is fine. I don't think code changes and as112 are mutually 
exclusive. We can do both. 

All this sounds like a lot of work for something that I think will wind up 
being quite useless, but it would hardly be the first time that has happened. 


Joe

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

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi!

Am 21.09.22 um 21:31 schrieb Ben Schwartz:

Preparing a separate document on compact DNS seems like a fine start to me.


We just published Version -01 of the draft [1]. The most significant 
change in regard to this discussion is that Section 5.1 was now moved to 
its own draft [2]. We are happy to discuss this, e.g., in the DNSOP WG 
meeting or F2F during a break at IETF 115, if the WG meeting agenda does 
not allow for this anymore.


The full listing of changes to the DoC draft can be found in Appendix A 
of [1].


Cheers
Martine

[1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/
[2] https://datatracker.ietf.org/doc/draft-lenders-dns-cns/



On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders 
mailto:m.lend...@fu-berlin.de>> wrote:


Hi Ben, Hi Carsten,

thanks for your suggestions, Ben! It seems a good idea to clarify
options for compactification of DNS messages in a separate document,
since the compactification is indeed not bound to CoAP. We will
prepare such a draft until the cut-off for IETF 115, so we can
discuss whether we keep or remove Section 5.1 at the IETF meeting in
London. Would that work for you?

I tend to agree with Carsten. At least with the current wording (or
the proposed), the restatements may lead to confusion, but some
guidelines for the constrained use case should IMHO be part of the
document, even if only in reference to the new document proposed.

Best
Martine

Am 20.09.22 um 18:17 schrieb Carsten Bormann:

I think we are falling into the restatement antipattern.

This antipattern happens when documents restate mandates from
their references, invariably creating confusion if this is just a
restatement or actually new normative text that replaces or
updates text from the dependency. Don’t do that.

Examples can be put into their own section and clearly marked as
such.

Grüße, Carsten

Sent from mobile, sorry for terse


On 20. Sep 2022, at 17:12, Ben Schwartz

 wrote:


Martine,

Thanks for the proposed updated text regarding CNAMEs.  I agree
that it is an improvement, but I still think it would be better
to omit entirely.  By writing that implementations SHOULD follow
RFC 1034, you imply that they are permitted not to, which seems
objectionable.  I think it would be much clearer to simply say
that use of DoC does not alter the DNS message contents.

I feel similarly about the Additional section.  If you think that
it would be useful to deviate from ordinary practices regarding
the Additional section, I think this should be in a separate
draft on compact DNS responses, not coupled to DoC.  For example,
such compactification might be even more relevant to UDP Do53
than to DoC.

--Ben

On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders
mailto:m.lend...@fu-berlin.de>> wrote:

Hi,

Sorry for the late reply, I was away from any keyboard for
the past two weeks.

I think there might be a misunderstanding regarding the CNAME
behavior, due to some poor wording in our draft: The CNAMEs
should, of course, only be resolved in such a way, if the
queried record was an A or  record. This does not, to my
understanding, contradict the behavior described for CNAMEs
in RFC 1034. We propose a different wording for the first
sentence in 5.1 to prevent such misunderstandings in the future:

    In the case of CNAME records in a DNS response to an A or
 record query, a DoC server SHOULD follow common DNS
resolver behavior [RFC1034

]
 by resolving a CNAME until the originally requested resource record type is reached.

Regarding the population of the additional section, we also
follow recommendations in RFC 1034, to only include records
useful to the client. We deem this particularly noteworthy
when it comes to DNS, as from our analysis of DNS traffic,
responses can become quite large due to an abundance of
records in the Additional section. With the message size
constraints in LLNs, it might thus be necessary to prune the
DNS message for records actually useful to the querying DoC
client.

Lastly, mind, that, at least in our model for DoC, a DoC
client does not further distribute the information it
gathered via DoC.

Regards
Martine

Am 06.09.22 um 17:06 schrieb Ben Schwartz:

Some further notes on this draft.

Section 5.1 says that a DoC server "SHOULD" follow CNAMEs. 
This is a misunderstanding of the nature of DNS transports. 
DoC is a DNS transport, like DoT and DoH.  The choice of

transport is 

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?

[Wes Hardaker]

David Conrad  writes:

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

Hi David,



The IAB discussed a while back about "when" to send a statement to the
ICANN board about this issue.  The decision was that if the WG didn't
have consensus yet (we have a bit more of one now than then), it sure
seem appropriate to send ICANN a note with a "maybe we might if we can
ever come to internal agreement".  In other words, it's just wasting
their time if we haven't even decided something is a good idea.  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.

That being said, the IAB is also aware of this issue and will be further
discussing it in the next few weeks.  If you wish to make arguments
about why the previous decision about whether the question should be
asked immediately, and what the nature of that question should be: I'm
all ears and will pass it on (at least in aggregated consensus form)
during future IAB discussions.

-- 
Wes Hardaker
USC/ISI

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

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

[Brian Dickson]

On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie  wrote:

>
>
> David Conrad wrote on 2022-10-23 12:00:
> > Rob,
>
> not rod, but i have three comments.
>
> > 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.
>
> first, +1 to the above and to the elided text formerly below.
>
> second, it's worth a bit of puttering to figure out how to prevent more
> pollution (queries of non-DNS namespaces or non-global-DNS namespaces)
> from hitting the root. delegating .ALT the same way 10.in-addr.arpa is
> delegated (prisoner.iana.org and so on) may be a fine idea.
>
>
Just to expand on this idea (which I quite like), the original AS112 was
enhanced to handle new/arbitrary names, so that AS112 operators don't need
to do anything to support being a sink for new domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
target for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root
zone, but is otherwise non-controversial (IMHO).
It would basically look like:

alt. DNAME empty.as112.arpa

Any query for foo.alt would be rewritten by the resolver doing resolution
to foo.empty.as112.arpa, which would result in an NXDOMAIN from the
topologically closest AS112 instance.

(Separate conversation that might be time to raise: is it time to sign
empty.as112.arpa, so these NXDOMAIN results have full DNSSEC proofs, and to
enable aggressive NSEC support on resolvers?)

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

[DNSOP] URI (scheme or other) future work (was Re: [Ext] Possible alt-tld last call?)

[Brian Dickson]

On Mon, Oct 24, 2022 at 7:18 AM Ben Schwartz  wrote:

>
>
> On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear  wrote:
>
>> Hi Ben and Wes,
>> On 21.10.22 20:45, Ben Schwartz 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.
>>
>> How would this work in practice?
>>
> Thinking about this more, I can imagine having both "+alt" and ".alt".  In
> this world, ".alt" would be for "the system's alternate DNS root",
> providing DNS-equivalent functionality but not in IANA-controlled space.
> "+alt" would be for "the system's alternative interpretations of URI
> schemes", with no further requirement that the authority be domain-shaped
> at all.
>
>>
>>- Would this require a re-registering of each and every URI scheme
>>with +alt, and monitoring the URI scheme registry for new ones?
>>
>>  I don't think so.  We could define it as a universal scheme modifier.
>
>>
>>-   (I'll note that git+ssh isn't registered.)
>>
>> Unfortunately, most URI schemes outside of the RFC process are not
> registered.  I think there's a general lack of awareness that registration
> is required or easy.
>
>>
>>- What is the value of +alt at this point?  Why not use +gns or
>>+onion or +eliotsfavoritenamespace?
>>
>> That sounds like a very intriguing idea, and might be better than +alt.
>
>>
>>- How might or should this be reflected in the browser bar?
>>
>> Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
>

 As noted by Timothy Mcsweeney in the original thread, sub-delim characters
are not permitted in the scheme.

However, my view on potential parsing and encoding is something that the
current URI specification already supports.

I think the namespace indicator definitely is something that should be
coupled with the "authority" portion of the URI. We're talking about how to
resolve the host portion of a URI, and while that might be expanded outside
of DNS, the URI spec already lists other non-DNS ways that a name might be
resolved. In Seciton 3.2.2 (Host) of RFC 3986) and specifically and
explicitly supports whatever is needed by resolution mechanisms in the
"reg-name" syntax, with the expectation that parsing and resolving a
"reg-name" is handled outside of the scope of URI parsing, so long as the
extraction of the "reg-name" works (i.e. that "reg-name" complies with the
URI specification).

And "reg-name" is essentially the normal characters from DNS, plus
"sub-delim" characters.
That list of characters includes the "!" character, which I think would
best enable encoding to indicate new name systems, e.g. using GNS as an
example:
gns!some.gns.name.gns.alt
(The suffix gns.alt is to ensure that if for any reason leakage to DNS does
happen by the GNS resolver, it won't get a real DNS answer. Yes, that is
redundant, but by design.)

Brian
___
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?

[Timothy Mcsweeney]

> On 10/24/2022 10:17 AM EDT Ben Schwartz  
> wrote:
> 
> >- How might or should this be reflected in the browser bar?
> >
> > Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
> 


You can't use the "+" in the scheme component of the uri scheme.  It's a 
reserved sub-delim.

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

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

[libor.peltan]

Hi,

Dne 23. 10. 22 v 21:00 David Conrad napsal(a):


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.


I personally don't like any suggestions that recursive and/or 
authoritative server software has some hard-wired handling of special 
TLDs. Especially (but not limited to!) RFC7686 (.onion), which requires 
even non-root auth servers to answer NXDOMAIN for names out of their 
configured bailiwicks (which is being ignored by auth software vendors 
AFAIK).


Libor

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

Re: [DNSOP] [Ext] Lars Eggert's Discuss on draft-ietf-dnsop-dnssec-bcp-05: (with DISCUSS and COMMENT)

[Paul Hoffman]

On Oct 20, 2022, at 5:02 AM, Lars Eggert via Datatracker  
wrote:
> --
> DISCUSS:
> --
> 
> # GEN AD review of draft-ietf-dnsop-dnssec-bcp-05
> ## Discuss
> 
> ### "Abstract", paragraph 1
> ```
> This document describes the DNS security extensions (commonly called
> "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
> others.  One purpose is to introduce all of the RFCs in one place so
> that the reader can understand the many aspects of DNSSEC.  This
> document does not update any of those RFCs.  Another purpose is to
> move DNSSEC to Best Current Practice status.
> ```
> I don't understand what "move DNSSEC to Best Current Practice status" means in
> terms of the standards track. I'm all for advancing the RFC set that makes up
> DNSSEC along the standards track, but BCP it not part of that track. 
> Publishing
> a BCP that normatively references some DNSSEC RFCs isn't doing anything in 
> terms
> of moving them forward.
> 
> ### Section 1.1, paragraph 2
> ```
> The DNSSEC set of protocols is the best current practice for adding
> origin authentication of data in the DNS.  To date, no standards-
> track RFCs offer any other method for such origin authentication of
> data in the DNS.
> ```
> Just because no other standards track RFCs compete with DNSSEC does not mean 
> it
> is a BCP. A BCP is something else, i.e. "The BCP subseries of the RFC series 
> is
> designed to be a way to standardize practices and the results of community
> deliberations." [RFC2026]
> 
> ### Section 1.1, paragraph 1
> ```
> However, this low level of implementation does not affect whether
> DNSSEC is a best current practice; it just indicates that the value
> of deploying DNSSEC is often considered lower than the cost.
> ```
> Protocols aren't BCPs. HTTP isn't the "best current practice" for transporting
> HTML either.
> 

I have just submitted -06 which I believe addresses your concerns. If so, 
please lift the DISCUSS position and let the draft wing its way towards the RFC 
Editor. If not, please let me know which parts still could be clarified, and I 
will do so after the draft cutoff window opens again.

--Paul Hoffman



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

[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-06.txt

[internet-drafts]

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

Title   : DNS Security Extensions (DNSSEC)
Author  : Paul Hoffman
  Filename: draft-ietf-dnsop-dnssec-bcp-06.txt
  Pages   : 11
  Date: 2022-10-24

Abstract:
   This document describes the DNS security extensions (commonly called
   "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
   others.  One purpose is to introduce all of the RFCs in one place so
   that the reader can understand the many aspects of DNSSEC.  This
   document does not update any of those RFCs.  A second purpose is to
   state that using DNSSEC for origin authentication of DNS data is the
   best current practice.  A third purpose is to provide a single
   reference for other documents that want to refer to DNSSEC.

   This document is currently maintained at
   https://github.com/paulehoffman/draft-hoffman-dnssec.  Issues and
   pull requests are welcomed.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-bcp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bcp-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[Ben Schwartz]

On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear  wrote:

> Hi Ben and Wes,
> On 21.10.22 20:45, Ben Schwartz 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.
>
> How would this work in practice?
>
Thinking about this more, I can imagine having both "+alt" and ".alt".  In
this world, ".alt" would be for "the system's alternate DNS root",
providing DNS-equivalent functionality but not in IANA-controlled space.
"+alt" would be for "the system's alternative interpretations of URI
schemes", with no further requirement that the authority be domain-shaped
at all.

>
>- Would this require a re-registering of each and every URI scheme
>with +alt, and monitoring the URI scheme registry for new ones?
>
>  I don't think so.  We could define it as a universal scheme modifier.

>
>-   (I'll note that git+ssh isn't registered.)
>
> Unfortunately, most URI schemes outside of the RFC process are not
registered.  I think there's a general lack of awareness that registration
is required or easy.

>
>- What is the value of +alt at this point?  Why not use +gns or +onion
>or +eliotsfavoritenamespace?
>
> That sounds like a very intriguing idea, and might be better than +alt.

>
>- How might or should this be reflected in the browser bar?
>
> Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
make the distinction clear to users

>


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

[DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-03.txt

[internet-drafts]

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

Title   : DNS Error Reporting
Authors : Roy Arends
  Matt Larson
  Filename: draft-ietf-dnsop-dns-error-reporting-03.txt
  Pages   : 10
  Date: 2022-10-24

Abstract:
   DNS Error Reporting is a lightweight error reporting mechanism that
   provides the operator of an authoritative server with reports on DNS
   resource records that fail to resolve or validate, that a Domain
   Owner or DNS Hosting organization can use to improve domain hosting.
   The reports are based on Extended DNS Errors [RFC8914].

   When a domain name fails to resolve or validate due to a
   misconfiguration or an attack, the operator of the authoritative
   server may be unaware of this.  To mitigate this lack of feedback,
   this document describes a method for a validating recursive resolver
   to automatically signal an error to an agent specified by the
   authoritative server.  DNS Error Reporting uses the DNS to report
   errors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[Rob Wilton (rwilton)]

Hi David,

Thanks, again with no hats, except for my comment on the first question.  
Please see inline …

From: David Conrad 
Sent: 23 October 2022 20:01
To: Rob Wilton (rwilton) 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?

Rob,

On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> 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.

RW:
With a “responsible AD for this document hat on”, I would like to ask the WG to 
consider this question as being out of scope for the moment, and assume that 
this work is within the scope of the IETF.  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.


  1.  whether there will be a registry of .alt uses (i.e., non-DNS name 
resolution systems) and if so, who will operate that registry.

RW:
The document should only define a registry of .alt uses if the registry is 
managed by IANA.


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.

RW:
I’ll defer answering that one to the experts, on which I am not one.


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.

RW:
If this 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.


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.

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

Regards,
Rob


Regards,
-drc

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