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

[George Michaelson]

On Wed, 24 Aug 2022, 12:23 pm John Levine,  wrote:

>
> I don't see any reason why that is our problem.
>
> On my system at least, the only DNS queries that go through nsswitch
> are ones starting from calls like getaddrinfo() or gethostbyname(). If
> you're interested in MX or SRV or HTTPS or anything other than A and
>  records, you're on your own. The switch to .onion doesn't use
> nsswitch, but rather something a couple of levels up in a socket
> proxy.
>
> If people want to splice their stuff into this corner of the domain
> name space it's up to them to figure out how to make it work.


Said less directly that would be the intent of my proposed sentence or
paragraph: "how this works and consequences for other name spaces is not a
DNS consideration" but with an element of "... but we're pretty sure there
are heaps of problems coming"

G

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

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

[John Levine]

It appears that George Michaelson   said:
>>
>> > 4) Say in English prose that since the DNS ignores ASCII case
>> > distinctions, all versions of .alt are excluded from the DNS, but it's
>> > up to each non-DNS thing to choose which if any of the versions it
>> > uses and it how it interprets them.
>>
>> That feels best to me.
>>
>> --Paul Hoffman
>
>I don't see how this works in practice for the consequence of control
>moving to nsswitch.conf, and like processes.

I don't see any reason why that is our problem.

On my system at least, the only DNS queries that go through nsswitch
are ones starting from calls like getaddrinfo() or gethostbyname(). If
you're interested in MX or SRV or HTTPS or anything other than A and
 records, you're on your own. The switch to .onion doesn't use
nsswitch, but rather something a couple of levels up in a socket
proxy.

If people want to splice their stuff into this corner of the domain
name space it's up to them to figure out how to make it work.

R's,
John

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

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

[George Michaelson]

On Wed, Aug 24, 2022 at 11:45 AM Paul Hoffman  wrote:
>
> On Aug 23, 2022, at 5:52 PM, John Levine  wrote:
> >
> > It appears that Paul Hoffman   said:
>
> > 4) Say in English prose that since the DNS ignores ASCII case
> > distinctions, all versions of .alt are excluded from the DNS, but it's
> > up to each non-DNS thing to choose which if any of the versions it
> > uses and it how it interprets them.
>
> That feels best to me.
>
> --Paul Hoffman

I don't see how this works in practice for the consequence of control
moving to nsswitch.conf, and like processes. This feels like it moves
the problem from standards space, to PBCK: Users are going to stuff
this up because the difference between AlT and alT is moot to many
people.

I also don't see how this is going to work for applications-space,
given that two app developers in GNS or other spaces may make
different interpretations of meaning.

I also don't know what the right answer is. I just think this makes as
big a problem as it solves, moving the hole around basically.

(maybe not helpful)

Does this need words which go to the problem?

The lack of certainty around ASCII case is a problem which non-DNS
uses of .alt will have to confront and manage, the DNS does not
constrain the problem,

Something like that?

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

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

[Paul Hoffman]

On Aug 23, 2022, at 5:52 PM, John Levine  wrote:
> 
> It appears that Paul Hoffman   said:
 This document uses ".alt" for the pseudo-TLD in the presentation
 format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
 wire format.  The presentation and on-the-wire formats for non-DNS
 protocols might be different.
 "
 
 I had to read this 3 times and I am still not sure what is important and 
 what not.
>>> 
>>> Doesn't this text also imply that the alt label is case-sensitive?
>> 
>>  Yes. We have at least three options:
>> 
>> 1) Pick one capitalization of "alt" and use the binary representation of 
>> that; for example "alt".
>> 
>> 2) Pick two capitalizations of "alt" and use the binary representations of 
>> those; for example "alt" and "ALT".
>> 
>> 3) Use all nine possible representations ("alt", "Alt", "ALt", ... "ALT")
> 
> 4) Say in English prose that since the DNS ignores ASCII case
> distinctions, all versions of .alt are excluded from the DNS, but it's
> up to each non-DNS thing to choose which if any of the versions it
> uses and it how it interprets them.

That feels best to me.

--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] draft-ietf-dnsop-alt-tld-17

[John Levine]

It appears that Paul Hoffman   said:
>>> This document uses ".alt" for the pseudo-TLD in the presentation
>>>  format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
>>>  wire format.  The presentation and on-the-wire formats for non-DNS
>>>  protocols might be different.
>>> "
>>> 
>>> I had to read this 3 times and I am still not sure what is important and 
>>> what not.
>> 
>> Doesn't this text also imply that the alt label is case-sensitive?
>
> Yes. We have at least three options:
>
>1) Pick one capitalization of "alt" and use the binary representation of that; 
>for example "alt".
>
>2) Pick two capitalizations of "alt" and use the binary representations of 
>those; for example "alt" and "ALT".
>
>3) Use all nine possible representations ("alt", "Alt", "ALt", ... "ALT")

4) Say in English prose that since the DNS ignores ASCII case
distinctions, all versions of .alt are excluded from the DNS, but it's
up to each non-DNS thing to choose which if any of the versions it
uses and it how it interprets them.

R's,
John

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

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

[Brian Dickson]

On Tue, Aug 23, 2022 at 9:15 AM Paul Hoffman  wrote:

> On Aug 23, 2022, at 8:50 AM, Warren Kumari  wrote:
> > I think that is helpful to communicate expectations,
>
> Is the suggestion that the non-DNS protocol follow the DNS wire format
> and/or presentation format now an expectation? This seems like a long jump.
>
> The purpose of .alt is to let anyone do what they want with non-DNS
> protocols. Expecting them to use the DNS wire format and/or presentation
> format limits the value of .alt and will cause developers who don't use
> them to continue to want to squat on TLDs. This doesn't help the DNS
> community.
>
>
I disagree.

I see the situation like this:

   - For anyone developing non-DNS protocols, which do not have
   DNS-compatible wire format (or presentation format), no advice or
   registration is necessary at all. Go nuts.
   - For anyone developing non-DNS protocols *where they have already
   chosen to use DNS-compatible wire format* (and/or presentation format),
   please use this "alt" registry and use YOURLABELHERE.alt as a suffix.

There is no expectation that they will use DNS format. However, if they
have self-selected to do so, the document is designed for them to be able
to easily understand and do the right thing.


> > and also help minimize people accidentally hurting themselves on sharp
> corners.
>
> If someone is reading this document before they develop their non-DNS
> protocol, we would be much better off telling them to use the DNS. THey are
> already in sharp corner land.
>
>

The issue isn't them hurting themselves on sharp corners; it is them
building apartment blocks with entrance halls that lead to rotating knives
and us accidentally stumbling into those.
(https://www.lyricsfreak.com/m/monty+python/the+architect_21031433.html)

:-)

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

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

[Brian Dickson]

On Tue, Aug 23, 2022 at 11:52 AM Paul Hoffman 
wrote:

> Thanks again for all the discussion; it is helping the document. You can
> see from the diff at <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-17> that we
> have tightened the language, particularly around what is display format and
> what is wire format. More comments are of course welcome.
>

One group of thoughts that might be helpful, is about the nature of any
"protocol" (for lack of a better term) that is added to the registry.

It may be helpful to add some things along the lines of:

   - Any registered "thing" needs to be completely independent of the DNS
   (at least for any namespace underneath .alt itself).
   - Any registered "thing" should ensure its identifier (e.g "foo.alt") is
   not the only method of confirming the namespace and protocol are what are
   intended.
  -  E.g. independent of the registered name "foo.alt", some shared
  information can be used to allow multiple users of the "thing"
to know that
  "foo" means what they think it means.
  - The example from DNS would be the set of pre-configured IP
  addresses of the ICANN Root Name Servers. All DNS systems assume they are
  in the same ICANN name space, but are also able to validate that by
  communicating with the Root Servers.
   - Any registered "thing" is encouraged to preserve its identifier as
   part of its domain names, but is also encouraged to not attach or associate
   any data with the topmost two labels of domain names (e.g. "foo.alt" would
   not have any sort of data associated with either "foo.alt" or "alt" wtihin
   the system of "thing" itself.) This ensures any leaks outside of "thing"
   can safely be identified and ignored by any other similar registered system
   which is aware of the "alt" registry and scheme.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Stephen Farrell]

Hiya,

On 23/08/2022 23:52, Martin Thomson wrote:

On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote:

Currently chromium and firefox disagree on whether ECH is setup
correctly for one of my test pages


I'm fairly confident that that is a bug on the Firefox end.  The
person looking into it has been on leave, but as far as I can tell
the DNS and server side is OK.


Sure, that may be the entirety of things. And to be clear: I
wasn't al all trying to imply there's any delay here, (e.g. I
know it took me months before I asked the right person and
then learned that what I was publishing as HTTPS RRs was
wrong;-) but the fact that both I and someone in browser
development misinterpreted stuff around ports != 443 may
indicate that a bit more clarity on that topic could be
useful, if there's a window open for a bit of text polishing.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Timothy Mcsweeney]

> On 08/23/2022 5:00 PM EDT Joe Abley  wrote:
> 
> I may have missed something (I have been trying very hard) but it seems a 
> little weird for the wire format for a definitively non-existent domain name 
> to be specified at all, to be honest;

I agree with Joe and its already been pointed out that this shouldn't be in 
DNSOPS because of it doesn't fit the charter.  And it seems the draft changes 
every day now.  I think there should be a gns-ops working group.  I would like 
to work on this; Spend some quality time on it.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Martin Thomson]

On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote:
> Currently chromium and firefox disagree on whether ECH is
> setup correctly for one of my test pages

I'm fairly confident that that is a bug on the Firefox end.  The person looking 
into it has been on leave, but as far as I can tell the DNS and server side is 
OK.

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

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

[Joe Abley]

On Aug 23, 2022, at 18:07, Peter Thomassen  wrote:

> Unaware applications: yes, perhaps mixed; but as they're unaware, they'll 
> ignore the carve-out regardless of case
> 
> Aware applications: ... will produce only what's compliant. And the question 
> here is what we want to define as compliant with the carve-out.

So your suggestion is that this document should specify behaviour for QNAMEs 
whose final label is exactly "alt" but that names with different capitalisation 
should be leaked to the DNS?


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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Stephen Farrell]

Hiya,

On 23/08/2022 22:51, Brian Dickson wrote:

The differences in interpretation, and the client behavior under one of
those interpretations, are the problem.


I've seen a different client-behaviour issue related to ports
other than 443 and ECH, but I'm unsure if that's a problem
with this spec or simply an implementation issue that'll be
fixed in short order.

Currently chromium and firefox disagree on whether ECH is
setup correctly for one of my test pages [1]. Initially, I
had misinterpreted what to publish in an HTTPS RR for [1] and
neither browser liked that, but even after I fixed that,
(thanks to one of the browser folk educating me), only one
seems to work, and the other still thinks that ECH isn't
properly setup for [1]. Surprisingly though, both work for
another page [2], but I wonder if that may be because ECH is
also enabled for the same name on the default port. [3]

If people are going to take another look at this spec, it may
be useful to also see if the text relating to ports other
than 443 is sufficiently clear - I know I got what to publish
wrong, and the fact that browsers haven't yet landed on the
same interpretation of what's needed for ECH away from port
443, may indicate a bit more clarity would be beneficial.

To be clear: I'd be fine with the RFC being issued and us
figuring out any useful clarifications as experiments with
ECH continue over the next while - my guess is there'll be
more than just this aspect of ECH to document better.

Cheers,
S.

PS: In case you're clicking the links below - both browsers
require a recent(ish) build, use of DoH and turning on a flag
before they attempt ECH so you'll only see the difference if
you've all that setup on your client.

PPS: Some of the relevant folk were vacating recently (me
included) so it could be this just gets fixed in the very
near future, but I figured if there's going to be a window
when some editorial/clarity text improvements might be made
it was worth raising, just in case.

[1] https://draft-13.esni.defo.ie:8413/stats
[2] https://my-own.net:8443/ech-check.php
[3] https://my-own.net/ech-check.php


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter Thomassen]

On 8/23/22 17:43, Paul Hoffman wrote:

On Aug 23, 2022, at 2:00 PM, Joe Abley  wrote:

I may have missed something (I have been trying very hard) but it seems a 
little weird for the wire format for a definitively non-existent domain name to 
be specified at all, to be honest; I'm not sure what imagined audience that is 
intended to help.


This is a very good point, one that I had not considered. Applications that 
know about the non-DNS will be getting input both from users or other 
applications, and thus get their input case-mixed. The same will be true for 
recursive resolvers.


I'm not sure why you conclude that input would be case-mixed.

Unaware applications: yes, perhaps mixed; but as they're unaware, they'll 
ignore the carve-out regardless of case

Aware applications: ... will produce only what's compliant. And the question 
here is what we want to define as compliant with the carve-out.

I see no problem with specifying one (1) lowercase variant only. All non-DNS 
would be invited to reside underneath. Am I missing something?


If this thinking is correct, the addition of "corresponding to a 0x03616c7400 suffix 
in DNS wire format" was wrong. However, I'm not sure what we want to say instead 
that will be clear enough for developers to act on.


We should decide what the set of carved-out binary TLD strings is, and then 
enumerate them for maximum clarity to DNS implementors who want to have an 
answer about what exactly to (not) forward upstream etc.

Best,
Peter

--
https://desec.io/

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Sat, Aug 20, 2022 at 10:07 AM Warren Kumari  wrote:

> Brian Dickson recently reached out to one of the DNSOP chairs to raise
> some technical concerns related to the AliasMode functionality in
> draft-ietf-dnsop-svcb-https.
>
> Although this document has already passed WGLC, IETF LC, IESG Eval, and
> was approved and sent to the RFC Editor, I want to make sure that the DNSOP
> working group has a chance to discuss any lingering concerns.  Accordingly,
> I have asked the RFC Editor to hold publication for now (note that the hold
> itself is not expected to delay publication of the document, which is
> blocked anyway due to missing references).
>
> As the document was already extensively discussed and approved, we should
> only make substantive changes if they are very clearly warranted (e.g
> something that would otherwise be an errata, or "OMG! That clearly doesn't
> work, 1+1 doesn't equal 17…") —  this is *not*  an opportunity to
> re-litigate existing  decisions, make non-required changes, etc.
>
> I believe that Brian is on vacation this week, and I wasn't really able to
> parse his issue with the document, so I ask him to clearly state the issue
> on-list when he returns. I would like to have whatever discussions wrapped
> up within 2 weeks from then so that I can release it back to the RFC
> Editor.
>
> Pausing publication is an unusual, but definitely not unprecedented, step.
> Although we are able to make changes until a document is published as an
> RFC, once it is approved and sent to the RFC Editor, we should only make
> (non-editorial) changes in exceptional circumstances…
>
> I'd like to also thank the authors and WG in advance for their time and
> for keeping this discussion focused,
> W
>
>
Thank you Warren.

I'll try to first raise the highest-level concern, which is that there are
some elements which appear to have some level of ambiguity, that result in
implementations doing different things.

The place where these ambiguities exist is on the client side of things,
meaning the procedures followed by clients, including how to interpret DNS
responses that originate from authoritative DNS servers (either directly,
or via resolvers, or via stub libraries).

To be clear: the wire format parts are fine, and what an zone administrator
should publish is not in any way impacted.

The differences in interpretation, and the client behavior under one of
those interpretations, are the problem.

The easiest way forward, I think, is to try to add enough clarification to
have a discussion about which interpretation has consensus. IMNSHO, the
draft needs to reach the point where only one interpretation is possible,
so that all implementations are in agreement, at least in the fundamental
aspect of the how clients should behave.

Once there is some clarification on the proposed text (e.g. with two
alternative approaches equally clearly described), then the conversation
can progress to "which of these is what DNSOP wants to be published"?

So, having prefaced things this way, here are the specific elements that
are apparently ambiguous.

I'll summarize as much as I can, but I will also include a couple of emails
from a thread between myself and the authors, chairs, one implementer,
included mostly to demonstrate that the interpretation in question is quite
specific and well articulated, i.e that I'm not possibly mis-interpreting
something someone said.

   - The problem is whether/when/how the DNS queries are considered
   failures, and whether/when/how some sort of fall-back procedure is followed
   in those cases.
   - This includes ambiguity over whether further DNS queries/responses are
   required, if HTTP connection failures occur with resolved TARGET values.
   - The ONLY concern is whether an AliasMode record (particularly at the
   zone apex) is treated EXACTLY the same as a constrained CNAME (i.e.
   unconditional QNAME rewrite if the RRTYPE is appropriate).
  - Unconditional would imply that an HTTPS-aware (or SVCB-aware, if
  you prefer) client never backtracks to the origin name to look up A/
  records for use, or more precisely, if the client does look up the A/
  records speculatively, if it gets an AliasMode record, it does not use
  those A/ records under any conditions.
  - Conditional would imply that there are conditions under which the
  client MIGHT use sibling A/ records instead of a valid AliasMode
  record, even if the AliasMode record was cryptographically protected and
  did not have a Chain-Length error. This situation, even if only "under
  certain circumstances", is the ANAME behavior.

Here is a longer description where the problems/ambiguities appear to
exist, which should be clarified first, and then discussed to decide what
to do about them.
There are some phrases or terms that are not defined, or inconsistently
used, or less than comprehensively enumerated:

   - In section 3, the term "SVCB-optional" 

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

[Paul Hoffman]

On Aug 23, 2022, at 2:00 PM, Joe Abley  wrote:
> 
> On Aug 23, 2022, at 16:03, Schanzenbach, Martin  
> wrote:
> 
>> "
>> 
>> This document uses ".alt" for the pseudo-TLD in the presentation
>>  format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
>>  wire format.  The presentation and on-the-wire formats for non-DNS
>>  protocols might be different.
>> "
>> 
>> I had to read this 3 times and I am still not sure what is important and 
>> what not.
> 
> Doesn't this text also imply that the alt label is case-sensitive?

 Yes. We have at least three options:

1) Pick one capitalization of "alt" and use the binary representation of that; 
for example "alt".

2) Pick two capitalizations of "alt" and use the binary representations of 
those; for example "alt" and "ALT".

3) Use all nine possible representations ("alt", "Alt", "ALt", ... "ALT")

I picked #1 but the WG might want something else, if we want to say anything 
about the wire format at all.

> I may have missed something (I have been trying very hard) but it seems a 
> little weird for the wire format for a definitively non-existent domain name 
> to be specified at all, to be honest; I'm not sure what imagined audience 
> that is intended to help.

This is a very good point, one that I had not considered. Applications that 
know about the non-DNS will be getting input both from users or other 
applications, and thus get their input case-mixed. The same will be true for 
recursive resolvers.

If this thinking is correct, the addition of "corresponding to a 0x03616c7400 
suffix in DNS wire format" was wrong. However, I'm not sure what we want to say 
instead that will be clear enough for developers to act on.

--Paul Hoffman

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

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

[Joe Abley]

On Aug 23, 2022, at 16:03, Schanzenbach, Martin  wrote:

> "
> 
> This document uses ".alt" for the pseudo-TLD in the presentation
>   format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
>   wire format.  The presentation and on-the-wire formats for non-DNS
>   protocols might be different.
> "
> 
> I had to read this 3 times and I am still not sure what is important and what 
> not.

Doesn't this text also imply that the alt label is case-sensitive?

I may have missed something (I have been trying very hard) but it seems a 
little weird for the wire format for a definitively non-existent domain name to 
be specified at all, to be honest; I'm not sure what imagined audience that is 
intended to help.


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

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

[Schanzenbach, Martin]

Hi,

"

This document uses ".alt" for the pseudo-TLD in the presentation
   format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
   wire format.  The presentation and on-the-wire formats for non-DNS
   protocols might be different.
"

I had to read this 3 times and I am still not sure what is important and what 
not.
Is it important what the DNS wire format specifically is? If yes, for whom?
Also, if the presentation format of ".alt" is the presentation format of DNS 
but the non-DNS protocol presentation format differs then... what?
I think we may need to agree that no matter what the presentation format is 
".alt" is always presented as ".alt", no?
Maybe it is just too late here...

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

This was already in before but I do not understand the significance of the 
first statement. What is it supposed to tell me?
The second statement is now a duplication of the statement in a paragraph above 
(?)

BR

> On 23. Aug 2022, at 20:52, Paul Hoffman  wrote:
> 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

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

[Paul Hoffman]

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



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-alt-tld-17.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   : The ALT Special Use Top Level Domain
Authors : Warren Kumari
  Paul Hoffman
  Filename: draft-ietf-dnsop-alt-tld-17.txt
  Pages   : 10
  Date: 2022-08-23

Abstract:
   This document reserves a TLD label, "alt" to be used in non-DNS
   contexts.  It also provides advice and guidance to developers
   developing alternative namespaces.

   [ This document is being collaborated on in Github at
   .  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests. ]


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

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

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


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] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 23/08/2022 16:45, Peter Thomassen wrote:

I think their point is that the application (e.g. browser) may be 
agnostic of the resolution system (= accept the name), but resolution

 may fail because something switching layer like nsswitch would choke
on a non-DNS-style name, *even when* the downstream non-DNS resolver
would be available.

So, by making the non-DNS names DNS-style, one can allow for more 
agnostic intermediate layers in the process that make DNS-like

assumptions.


Yes, that's in part what I was trying to say, although it may also apply 
to stub-resolver-like functionality that is part of a userspace library.


Ray

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

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

[Ray Bellis]

On 23/08/2022 17:14, Paul Hoffman wrote:


Is the suggestion that the non-DNS protocol follow the DNS wire
format and/or presentation format now an expectation? This seems like
a long jump.


The dot-separated form of a domain name _is_ a "presentation format", 
even if it's not precisely that of a zone file.


I don't care about the wire protocol, or how any "rdata" is presented
and/or encoded.

Ray

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

Re: [DNSOP] Use of CNAMEs for NS Records

[Grant Taylor]

On 8/23/22 7:00 AM, Tobias Fiebig wrote:
Context: I am currently dealing with academic reviewers claiming that 
not using CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] 
also commonly ignored in practice.


Obeying the speed limit is "[...] by the spec, [...] true, [but] also 
commonly ignored in practice" doesn't mean that speeding is legal.


It /MAY/ be an indication that the law / speed limit or RFC / CNAME spec 
needs to be changed.


However there is a process to go about doing both of those things.  In 
the mean time, don't speed.  Or at least don't be upset when you get 
stopped or your CNAME NS records fail to operate as desired.


I would personally argue "RFC says no" still holds, and I think you 
already gave me another good argument to make why exclusion of CNAME 
NS is valid in our case.


I want to say "be liberal in what you accept and conservative in what 
you send" but "brown M".


I do encourage you to stand your ground and not support CNAMEs for NS 
records.  Or at most call it out as an "undefined behavior" that you 
will not expend effort to make work.




--
Grant. . . .
unix || die



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

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

[Peter Thomassen]

On 8/23/22 12:31, Warren Kumari wrote:

But my question would still be: Should the registry pose limitations, then, 
on the 2LD? Because you cannot really have the one without the other?


I don't think that it can (or should). This is just a suggestion… I had considered wording it as  
"it is recommended that…", but that sounded stronger and that people might confuse it 
with "RECOMMENDED".


I think if you suggest/recommend to non-DNS protocol designers that their names 
(third level and below) ideally would LDH domain names, then the 2LD IANA 
registry at least SHOULD, perhaps MUST only accept such names.

Otherwise you get into inconsistent territory, because you'd allow a protocol 
that uses only LDH names under its namespace to be registered in the .alt 
registry under a non-LDH name.

Now, I see no shortage of 2LD names in the IANA registry, and requiring those to be LDH 
does not mandate anything for the names below. (The last label, "alt", is 
already LDH, and there's no harm whatsoever in making the 2nd label LDH as well.)

I'm much more inclined to mandate LDH for the IANA registry on the 2nd level 
than recommending it for the 3rd level and below.

Best,
Peter

--
https://desec.io/

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

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

[Warren Kumari]

On Tue, Aug 23, 2022 at 12:09 PM, Martin Schanzenbach <
mschanzenb...@posteo.de> wrote:

> On 23. Aug 2022, at 16:47, Warren Kumari  wrote:
>
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen  wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there that do not know about
> ".alt".
>
> How would those systems respond when passed a domain-style name that does
> not meet domain-style syntax rules (specifically those for total length and
> label lengths) ?
>
> Designers of that other non-DNS protocol will have to consider all kinds
> of interoperability issues, including what kind of strings are permissible
> under their branch of .alt, and what consequences would arise from that.
>
> IMO, that is within the realm of the specification of that other non-DNS
> protocol, just like any other protocol consideration that occurs when
> evolving a specification while implementing it; we DNS people don't have to
> mandate fences for the general case.
>
> Mandate no, but I do think that we should "helpfully suggest".
>
> There are many ways to refer to a host — for example, I recently had to
> ask someone to swap a drive in a server for me, and I resolved the identity
> with: "it's the Dell server towards the bottom of the rack near the door."
> Clearly this is a pathological case, but putting ".alt" at the end of that
> doesn't really help :-).
>
> Much of the reason for needing something like .alt is that the context
> isn't explicit, and so we expect that these names will be used in places
> that generally expect something like a "DNS name". I think that some text
> suggesting that for interoperability with existing applications (which may
> do some sort of checks or processing on the user input) people may want to
> constrain themselves to LDH / DNS syntax. There are no protocol police, and
> so we cannot actually enforce this even if we wanted to — I can technically
> put  weird looking pyramid thingie emoji>.kumari.net into my zonefile, and
> there is nothing you can to do stop me…  — but it
> sure won't work well…
>
> So, I'd think something like: "For compatibility with existing
> applications and to maximize interoperability, it is recommended that names
> that end in .alt follow DNS name syntax." (or something similar but better
> worded).
>
> Who is this recommendation supposed to be for? The user
> "registering/creating" a name or the protocol? I think that the
> specification of the protocol may recommend to users that they should
> carefully consider the name chosen when it is supposed to be used with
> ".alt".
>


What I put in my pull request is: "To maximize compatiblity with existing
applications, it is suggested that non-DNS protocols using names that end
in .alt follow DNS name syntax." - it is just a suggestion, there is no
"force" behind it...

But my question would still be: Should the registry pose limitations, then,
> on the 2LD? Because you cannot really have the one without the other?
>

I don't think that it can (or should). This is just a suggestion… I had
considered wording it as  "it is recommended that…", but that sounded
stronger and that people might confuse it with "RECOMMENDED".

W


> BR
> Martin
>
> W
>
> Best,
> Peter
>
> --
> https://desec.io/
>
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Paul Hoffman]

On Aug 23, 2022, at 8:50 AM, Warren Kumari  wrote:
> I think that is helpful to communicate expectations,

Is the suggestion that the non-DNS protocol follow the DNS wire format and/or 
presentation format now an expectation? This seems like a long jump.

The purpose of .alt is to let anyone do what they want with non-DNS protocols. 
Expecting them to use the DNS wire format and/or presentation format limits the 
value of .alt and will cause developers who don't use them to continue to want 
to squat on TLDs. This doesn't help the DNS community.

> and also help minimize people accidentally hurting themselves on sharp 
> corners.

If someone is reading this document before they develop their non-DNS protocol, 
we would be much better off telling them to use the DNS. THey are already in 
sharp corner land.

> I see no downside to suggesting using names that are more likely to work (I 
> also personally think that it is cleaner and easier for developers and humans 
> to be able to more easily recognize names than "oh, here is a string that 
> ends in .alt… I wonder where it begins :-))

If it's just a suggestion, it should go into its own document. This document is 
how .alt works, not how we want folks to develop non-DNS protocols.

--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] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 23. Aug 2022, at 16:47, Warren Kumari  wrote:
> 
> 
> 
> 
> 
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen  wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
> 
> There will be a very long tail of systems out there that do not know about 
> ".alt".
> 
> How would those systems respond when passed a domain-style name that does not 
> meet domain-style syntax rules (specifically those for total length and label 
> lengths) ?
> 
> Designers of that other non-DNS protocol will have to consider all kinds of 
> interoperability issues, including what kind of strings are permissible under 
> their branch of .alt, and what consequences would arise from that.
> 
> IMO, that is within the realm of the specification of that other non-DNS 
> protocol, just like any other protocol consideration that occurs when 
> evolving a specification while implementing it; we DNS people don't have to 
> mandate fences for the general case.
> 
> 
> 
> Mandate no, but I do think that we should "helpfully suggest".
> 
> There are many ways to refer to a host — for example, I recently had to ask 
> someone to swap a drive in a server  for me, and I resolved the identity 
> with: "it's the Dell server towards the bottom of the rack near the door." 
> Clearly this is a pathological case, but putting ".alt" at the end of that 
> doesn't really help :-).
> 
> Much of the reason for needing something like .alt is that the context isn't 
> explicit, and so we expect that these names will be used in places that 
> generally expect something like a "DNS name". I think that some text 
> suggesting that for interoperability with existing  applications (which may 
> do some sort of checks or processing on the user input) people may want to 
> constrain themselves to LDH / DNS syntax. There are no protocol police, and 
> so we cannot actually enforce this even if we wanted to — I can technically 
> put  weird looking pyramid thingie emoji>.kumari.net into my zonefile, and there 
> is nothing you can to do stop me…  — but it sure 
> won't work well…
> 
> So, I'd think something like: "For compatibility with existing applications 
> and to maximize interoperability, it is recommended that names that end in 
> .alt follow DNS name syntax." (or something similar but better worded).
> 

Who is this recommendation supposed to be for? The user "registering/creating" 
a name or the protocol?
I think that the specification of the protocol may recommend to users that they 
should carefully consider the name chosen when it is supposed to be used with 
".alt".
But my question would still be: Should the registry pose limitations, then, on 
the 2LD?
Because you cannot really have the one without the other?

BR
Martin

> W
> 
> 
> 
> Best,
> Peter
> 
> --
> https://desec.io/
> 
> ___
> 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



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

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

[Warren Kumari]

On Tue, Aug 23, 2022 at 11:45 AM, Peter Thomassen  wrote:

> On 8/23/22 11:38, Paul Hoffman wrote:
>
> On Aug 23, 2022, at 7:47 AM, Warren Kumari  wrote:
>
> So, I'd think something like: "For compatibility with existing
> applications and to maximize interoperability, it is recommended that names
> that end in .alt follow DNS name syntax." (or something similar but better
> worded).
>
> An application that understands a non-DNS protocol already is compatible
> with that naming scheme.
>
> I think their point is that the application (e.g. browser) may be agnostic
> of the resolution system (= accept the name), but resolution may fail
> because something switching layer like nsswitch would choke on a
> non-DNS-style name, *even when* the downstream non-DNS resolver would be
> available.
>
> So, by making the non-DNS names DNS-style, one can allow for more agnostic
> intermediate layers in the process that make DNS-like assumptions.
>
> Given that, I can see why a sentence like the one suggested by Warren
> could make sense.
>
> OTOH, it's possible that a given non-DNS protocol comes with its own
> application layer (i.e. no legacy pieces with DNS-like assumptions
> involved), and it's questionable whether a name syntax recommendation would
> cause undue restrictions for these cases.
>
> All in all, I think either way is fine (weak suggestion/recommendation, or
> nothing at all).
>


I think that is helpful to communicate expectations, and also help minimize
people accidentally hurting themselves on sharp corners. I see no downside
to suggesting using names that are more likely to work (I also personally
think that it is cleaner and easier for developers and humans to be able to
more easily recognize names than "oh, here is a string that ends in .alt… I
wonder where it begins :-))

W



> Peter
>
> --
> https://desec.io/
>
> ___
> 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] draft-ietf-dnsop-alt-tld-16: please review

[Peter Thomassen]

On 8/23/22 11:38, Paul Hoffman wrote:

On Aug 23, 2022, at 7:47 AM, Warren Kumari  wrote:

So, I'd think something like: "For compatibility with existing applications and to 
maximize interoperability, it is recommended that names that end in .alt follow DNS name 
syntax." (or something similar but better worded).


An application that understands a non-DNS protocol already is compatible with 
that naming scheme.


I think their point is that the application (e.g. browser) may be agnostic of 
the resolution system (= accept the name), but resolution may fail because 
something switching layer like nsswitch would choke on a non-DNS-style name, 
*even when* the downstream non-DNS resolver would be available.

So, by making the non-DNS names DNS-style, one can allow for more agnostic 
intermediate layers in the process that make DNS-like assumptions.

Given that, I can see why a sentence like the one suggested by Warren could 
make sense.

OTOH, it's possible that a given non-DNS protocol comes with its own 
application layer (i.e. no legacy pieces with DNS-like assumptions involved), 
and it's questionable whether a name syntax recommendation would cause undue 
restrictions for these cases.

All in all, I think either way is fine (weak suggestion/recommendation, or 
nothing at all).

Peter

--
https://desec.io/

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

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

[Paul Hoffman]

On Aug 23, 2022, at 7:47 AM, Warren Kumari  wrote:
> So, I'd think something like: "For compatibility with existing applications 
> and to maximize interoperability, it is recommended that names that end in 
> .alt follow DNS name syntax." (or something similar but better worded).

An application that understands a non-DNS protocol already is compatible with 
that naming scheme.

An application that doesn't understand a non-DNS protocol will fail on the name 
just as it would fail on a DNS name that does not exist.

There is no reason for this document to suggest to non-DNS protocols what to 
do; the developers of those protocols are aware of the DNS and can make their 
own design choices based on the pros and cons they see, without us.

--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] draft-ietf-dnsop-alt-tld-16: please review

[Warren Kumari]

On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen  wrote:

> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there that do not know about
> ".alt".
>
> How would those systems respond when passed a domain-style name that does
> not meet domain-style syntax rules (specifically those for total length and
> label lengths) ?
>
> Designers of that other non-DNS protocol will have to consider all kinds
> of interoperability issues, including what kind of strings are permissible
> under their branch of .alt, and what consequences would arise from that.
>
> IMO, that is within the realm of the specification of that other non-DNS
> protocol, just like any other protocol consideration that occurs when
> evolving a specification while implementing it; we DNS people don't have to
> mandate fences for the general case.
>


Mandate no, but I do think that we should "helpfully suggest".

There are many ways to refer to a host — for example, I recently had to ask
someone to swap a drive in a server  for me, and I resolved the identity
with: "it's the Dell server towards the bottom of the rack near the door."
Clearly this is a pathological case, but putting ".alt" at the end of that
doesn't really help :-).

Much of the reason for needing something like .alt is that the context
isn't explicit, and so we expect that these names will be used in places
that generally expect something like a "DNS name". I think that some text
suggesting that for interoperability with existing  applications (which may
do some sort of checks or processing on the user input) people may want to
constrain themselves to LDH / DNS syntax. There are no protocol police, and
so we cannot actually enforce this even if we wanted to — I can technically
put .kumari.net into my zonefile, and there
is nothing you can to do stop me…  — but it sure
won't work well…

So, I'd think something like: "For compatibility with existing applications
and to maximize interoperability, it is recommended that names that end in
.alt follow DNS name syntax." (or something similar but better worded).

W


> Best,
> Peter
>
> --
> https://desec.io/
>
> ___
> 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] draft-ietf-dnsop-alt-tld-16: please review

[David Conrad]

Hi,

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

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

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

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

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

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

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

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

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

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

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

Yes.

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

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

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

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

Regards,
-drc



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

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

[Peter Thomassen]

On 8/23/22 07:02, Ray Bellis wrote:

There will be a very long tail of systems out there that do not know about 
".alt".

How would those systems respond when passed a domain-style name that does not 
meet domain-style syntax rules (specifically those for total length and label 
lengths) ?

Designers of that other non-DNS protocol will have to consider all kinds of 
interoperability issues, including what kind of strings are permissible under 
their branch of .alt, and what consequences would arise from that.

IMO, that is within the realm of the specification of that other non-DNS 
protocol, just like any other protocol consideration that occurs when evolving 
a specification while implementing it; we DNS people don't have to mandate 
fences for the general case.

Best,
Peter

--
https://desec.io/

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

Re: [DNSOP] Use of CNAMEs for NS Records

[Mark Andrews]

CNAMEs cannot be installed as glue which makes 

@ SOA . . 0 0 0 0 0
@ NS ns1
ns1 CNAME host
host A 1.2.3.4

problematic.

Also named refuses to follow NS records that refer to CNAMEs as they can’t be 
used reliably and no we are not going to try and make them work in the cases 
where they could potentially.  Manage your delegations correctly.  Named will 
also refuse to load a zone if it detected NS referring to a CNAME.  I just wish 
other vendors would do the same thing.

Similarly stop loading zones with CNAME at the apex, or CNAME and other data 
generally.  Resolvers shouldn’t have to put up with that sort of garbage.  Nor 
should resolver developers have to deal with bug reports caused by different 
responses depending upon cached content.  STD 13 said not to allow CNAME and 
other data.

> On 23 Aug 2022, at 23:00, Tobias Fiebig  
> wrote:
> 
> Heho,
>> Vladimír Čunát wrote:
>> I believe that's a wrong approach in principle and risky in practice.
> 
> Oh, i am fully with you on this one; I just try to make sure I did not miss a 
> development that outdated RFC2181.
> 
> Context: I am currently dealing with academic reviewers claiming that not 
> using CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] also 
> commonly ignored in practice. This is trivial to demonstrate with a test 
> domain and queries against major public DNS resolvers." This statement refers 
> to me/'us' excluding all NS records that are CNAME instead of A/ in a 
> work looking at delegation issues (which is not broken delegation in 
> general), while citing RFC2181 Sec 10.3 as the reason for doing so. This is 
> what prompted me to dig into it in the first place as I will have to make an 
> argument why we are not considering CNAME NS as a source for potentially 
> successful resolution in the future.
> 
> I would personally argue "RFC says no" still holds, and I think you already 
> gave me another good argument to make why exclusion of CNAME NS is valid in 
> our case. 
> 
> With best regards,
> Tobias
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Use of CNAMEs for NS Records

[Tobias Fiebig]

Heho,
> Vladimír Čunát wrote:
> I believe that's a wrong approach in principle and risky in practice.

Oh, i am fully with you on this one; I just try to make sure I did not miss a 
development that outdated RFC2181.

Context: I am currently dealing with academic reviewers claiming that not using 
CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] also commonly 
ignored in practice. This is trivial to demonstrate with a test domain and 
queries against major public DNS resolvers." This statement refers to me/'us' 
excluding all NS records that are CNAME instead of A/ in a work looking at 
delegation issues (which is not broken delegation in general), while citing 
RFC2181 Sec 10.3 as the reason for doing so. This is what prompted me to dig 
into it in the first place as I will have to make an argument why we are not 
considering CNAME NS as a source for potentially successful resolution in the 
future.

I would personally argue "RFC says no" still holds, and I think you already 
gave me another good argument to make why exclusion of CNAME NS is valid in our 
case. 

With best regards,
Tobias


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

Re: [DNSOP] Use of CNAMEs for NS Records

[Vladimír Čunát]

On 23/08/2022 14.15, Tobias Fiebig wrote:

Is there something I missed/should CNAME in NS be considered valid now?  [...]  
However, it seems odd that RFC2181 and operational practice seem to diverge 
here.


This sounds like running a few tests in the wild might imply that such 
setup is OK.  (compliant/valid/reliable)  I believe that's a wrong 
approach in principle and risky in practice.


DNS servers are not even *obliged* to fail on non-compliant input, 
except for explicit requirements like in DNSSEC validation.  They're 
*allowed* to fail, which is a thing depending on particular 
implementation and can change over time.


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

[DNSOP] Use of CNAMEs for NS Records

[Tobias Fiebig]

Heho,
I am currently doing some measurement work related to DNS delegation. In this 
work, we initially decided to exclude names listed in NS that only contain a 
CNAME, following RFC2181 Sec. 10.3., which--as far as I can see--has not been 
updated, stating:

10.3. MX and NS records

   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.

The reviewers now claimed that this is, indeed, no longer true, which made me 
setup a test-case; Indeed, I find that even though a default unbound 1.15.0 
does _not_ resolve a CNAME based delegation, major other operators (q1/q8, my 
local ISP) indeed _do_ resolve these names. (Testcase below.)

I also ran some quick atlas measurements, using probe resolvers, once with 
resolve-on-probe and once with defaults:

Resolve on probe:
https://atlas.ripe.net/frames/measurements/44061850/

data/RIPE-Atlas-measurement-44061850.json
resolving: 263 not resolving: 180

Default:
https://atlas.ripe.net/frames/measurements/44061849/ 

data/RIPE-Atlas-measurement-44061849.json
resolving: 264 not resolving: 179

In both cases only counting unique configured resolvers, i.e., +- some noise 
for 1918/::1 et al.

Is there something I missed/should CNAME in NS be considered valid now? I will 
take a look at the prevalence of CNAME in NS (but crunching the data takes some 
more time). However, it seems odd that RFC2181 and operational practice seem to 
diverge here.

With best regards,
Tobias

---
Test case:

RR to resolve (A/): 
www.dns-test-cname.wybt.net, which is:
www.dns-test-cname.wybt.net. IN A 195.191.197.4
www.dns-test-cname.wybt.net. IN  2a06:d1c0:dead:1::4

dns-test-cname.wybt.net. IN NS authns.dns-test.wybt.net.
dns-test-cname.wybt.net. IN CNAME authns.dns-test2.wybt.net.

authns.dns-test2.wybt.net. IN A 195.191.197.27
authns.dns-test2.wybt.net. IN  2a06:d1c0:dead:1::27

With:
dns-auth-test.wybt.net. IN A 195.191.197.25
dns-auth-test.wybt.net. IN  2a06:d1c0:dead:1::25
dns-auth-test2.wybt.net. IN A 195.191.197.25
dns-auth-test2.wybt.net. IN  2a06:d1c0:dead:1::25
dns-auth-test3.wybt.net. IN A 195.191.197.25
dns-auth-test3.wybt.net. IN  2a06:d1c0:dead:1::25

wybt.net, dns-test.wybt.net and dns-test2.wybt.net, dns-test-cname.wybt.net are 
all on different machines:

wybt.net.   IN  NS  robotns2.second-ns.de.
wybt.net.   IN  NS  robotns3.second-ns.com.
wybt.net.   IN  NS  dns.aperture-labs.org.
wybt.net.   IN  NS  dns2.aperture-labs.org.
wybt.net.   IN  NS  ns1.first-ns.de.

dns-test.wybt.net.  IN  NS  dns-auth-test.wybt.net.

dns-test2.wybt.net. IN  NS  dns-auth-test2.wybt.net.

dns-test-cname.wybt.net. IN NS  authns.dns-test.wybt.net.
dns-test-cname.wybt.net. IN NS  authns.dns-test.wybt.net.
dns-test-cname.wybt.net. IN CNAME authns.dns-test2.wybt.net.
authns.dns-test2.wybt.net. IN   A   195.191.197.27
authns.dns-test2.wybt.net. IN   2a06:d1c0:dead:1::27


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

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

[Ray Bellis]

On 23/08/2022 12:18, Schanzenbach, Martin wrote:


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

If that were the case then we do not need .alt at all.

Arguably you do not, but unless there is some _other_ indicator that a
name is a GNS name (e.g. https+gns://) then we have a problem. 
non-GNS-aware clients will send all those queries to the DNS.


But if the carve-out is done using the rightmost one or two labels as 
proposed with ".alt", then existing code has to cope.  Any application 
that wants to parse a name _even if the nsswitch is .alt aware_ might 
need to be modified to allow these domain-style names to get as far as 
the system's resolver.


Conforming to a couple of (IMHO not particuarly onerous) restrictions on 
total length and label length would go a long way to mitigate that.



For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant 
wire format.


DNS does not require LDH, or ASCII.


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

Applications (to some degree) have to deal with malformed names anyway as part 
of the user input handling.
If they consider the given .alt-name malformed because they only expect DNS 
names, then that is within the expected behaviour.
If the application crashes because of such a name, it would also crash because 
of data corruption or faulty user input.
And that is a bug in the application, possibly even a security issue if it 
leads to a buffer overflow etc.


I am not so concerned with crashes.  I am concerned that there is a 
semantic difference in the errors generated when a name cannot be parsed 
vs when it does not exist.


Yes, the net result is that the resource cannot be found, but over the 
years there have been significant issues caused by misinterpretation of 
errors.


Ray

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

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

[Schanzenbach, Martin]

> On 23. Aug 2022, at 13:02, Ray Bellis  wrote:
> 
> 
> 
> On 23/08/2022 10:22, Andrew McConachie wrote:
> 
>> The only restriction that seems reasonable to me is prohibiting zero length 
>> strings. This list convinced me other restrictions would be a bad idea.
> 
> There will be a very long tail of systems out there that do not know about 
> ".alt".
> 
> How would those systems respond when passed a domain-style name that does not 
> meet domain-style syntax rules (specifically those for total length and label 
> lengths) ?
> 
> If the answer is that they return something other than EAI_NONAME (or 
> HOST_NOT_FOUND for gethostbyname) then this needs to be considered further.
> 
> IMHO, if you want to be in a carve-out of the domain name space, you still 
> need to play by the domain name space's technical rules, in a way that's 
> backwards compatible with systems that don't know about the carve-out and 
> will assume that veryverylonglabel.foo.alt _is_ a domain name.

I think the notion that there is strict "format" of a name and that if it is 
not in that format is not actually part of the same namespace is already behind 
us.
If that were the case then we do not need .alt at all.
For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant 
wire format.

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

Applications (to some degree) have to deal with malformed names anyway as part 
of the user input handling.
If they consider the given .alt-name malformed because they only expect DNS 
names, then that is within the expected behaviour.
If the application crashes because of such a name, it would also crash because 
of data corruption or faulty user input.
And that is a bug in the application, possibly even a security issue if it 
leads to a buffer overflow etc.

BR
Martin


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



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

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

[Ray Bellis]

On 23/08/2022 10:22, Andrew McConachie wrote:



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




There will be a very long tail of systems out there that do not know 
about ".alt".


How would those systems respond when passed a domain-style name that 
does not meet domain-style syntax rules (specifically those for total 
length and label lengths) ?


If the answer is that they return something other than EAI_NONAME (or 
HOST_NOT_FOUND for gethostbyname) then this needs to be considered further.


IMHO, if you want to be in a carve-out of the domain name space, you 
still need to play by the domain name space's technical rules, in a way 
that's backwards compatible with systems that don't know about the 
carve-out and will assume that veryverylonglabel.foo.alt _is_ a domain name.


Ray

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

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

[Andrew McConachie]

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

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

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


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




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


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

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


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


--Andrew

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

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

[Schanzenbach, Martin]

> On 22. Aug 2022, at 20:33, Paul Hoffman  wrote:
> 
> On Aug 22, 2022, at 11:24 AM, Schanzenbach, Martin  
> wrote:
>> But I also think that if it is expected that name systems may "go rogue" 
>> e.g. use a new innovative new string encoding, then the registry might have 
>> trouble listing/registering the 2LD "byte string" chosen by the name system?
> 
> This should not be a problem: that's what we have the \DDD notation for. (See 
> the list toward the end of Section 5.1 of RFC 1035.)
> 

I just now read this, sorry. So that was a pointless tangent by me and and 
theoretically byte strings could be registered using \DDD-notations as is.

>> So maybe Unicode provides sensible guide lines for acceptable strings under 
>> .alt _for the registry_?
> 
> It does not. You truly don't want to deal with byte sequences that are not 
> allowed in the various encodings of Unicode. Specifying the names in a format 
> that DNS folks recognize (ASCII and \DDD) should suffice for someone looking 
> at the registry. If they have a further question, there is a link to the 
> specification.

You convinced me.

BR

> 
> --Paul Hoffman
> 



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