Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Wes Hardaker]

Tim Wicinski  writes:

> This starts a Call for Adoption for draft-arends-private-use-tld

TLDR: As is, I'm afraid I can't support this draft for adoption.  First,
this seems an end-run around two other organizations.  And second, I
think there are potential concerns with how the RSS is expected to
handle this increased load.  Both of these, I think, are fixable but as
is it's a no-go from me.

The more complete version:

I agree with your assessment that it is "extremely unlikely" that ISO
3166 Maintenance Agency or ICANN would change their position on the
usability of these codes.  But, this document still makes use of the
codes without even asking either organization "what do you think if we
do this?". All because asking is difficult?  Why would the IETF take on
this land-grab without even consulting these other two agencies.

You claim that these reservations don't require "special handling", and
are thus not part of the special use namespace.  You state that they're
"special on a policy level, but not on a technical or protocol level",
to which I must disagree.  You're asking for new non/never-TLDs to be
not-created and this requires no technical or code-changes.  That
appears true on the face of the situation, until you consider what
happens when these queries leak to the real DNS, which they assuredly
will (we have piles of data proving this as you know).

What happens when an organization/company full of .zz configured
devices, many mobile, start assuming they can query for something under
..zz and they're not behind their organization's resolver that knows to
forward those requests to somewhere internally-special?  They end up at
the root.

I'm sure you're aware that we already have a code-base out there
generating vast numbers of requests that leak to the root [1].  And
that's only on a network change.  Imagine if all of these devices were
generating queries that leak to the root only based on the negative TTL
cache value and how many more queries those might generate.  Now, the
large negative cache in the root should make me feel better, but there
is also a lot of evidence that many resolvers don't seem to follow that
SOA field guidance. Thus, I have a hard time estimating the impact of
this but I have fears it may be larger than ideal (0).

In the end, I think this proposal *does* require technical changes.
Resolvers should black-hole these types of queries.  Better yet, place
this new domain in a place that has public NS records pointing to
non-routable addresses spaces (127.53.53.53 as an example) so that they
can't leak.  This really is, IMHO, a case of a special-use domain.

Meanwhile, your draft talks about the need for this to be a TLD but
doesn't actually argue for it.  You argue extensively why these 2 letter
codes will never cause problems and are used by many other organizations
in different ways too in attempt to achieve [2] status, but you don't
ever argue why this must be at a TLD rather than under something like
..arpa which the IETF has exclusive control over.  I get that a TLD is
easier, more friendly to-users, etc and I don't even disagree.  But I
think if you want this document with its extensive arguing to succeed,
this argument should be included too.


[1]: https://blog.apnic.net/2020/04/13/whats-in-a-name/
[2]: https://xkcd.com/1170/
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Tim Wicinski  writes:

> This starts a Call for Adoption for draft-arends-private-use-tld

I think this is cute / clever, but a very bad idea.

Experience from IPv4 and IPv6 private use areas shows that there will be
collisions and they will be painful.

The first line of the abstract is wrong. Every properly registered domain
name is a private-use namespace. The desire for shortness is why the DNS
has search paths and unqualified domain names.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
East Sole: Cyclonic becoming northwesterly, 3 to 5. Slight, occasionally
moderate. Thundery showers. Good, occasionally moderate.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Brian Dickson]

On Mon, Jun 15, 2020 at 8:34 AM Tony Finch  wrote:

> Tim Wicinski  writes:
>
> > This starts a Call for Adoption for draft-arends-private-use-tld
>
> I think this is cute / clever, but a very bad idea.
>
> Experience from IPv4 and IPv6 private use areas shows that there will be
> collisions and they will be painful.
>
>
I think the comparison to v4 private use is flawed, specifically because
IPv4 addresses are a fixed quantity.

Private use DNS space is freeform and limited only by the 255 character
limit in DNS names.
Collisions in private use DNS space can trivially be prevented by use of an
in-fix (like a suffix but before the TLD) designed to be unique.
E.g. use an FQDN belonging to you (or your company), so the namespace would
be example.com.zz under which your private names are instantiated.
(That's an example only, any arbitrary string could be used, even a GUID.)

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[John Levine]

In article  
you write:
>E.g. use an FQDN belonging to you (or your company), so the namespace would
>be example.com.zz under which your private names are instantiated.

The obvious question is if an organization is willing to use
example.com.zz, why wouldn't they use zz.example.com with split
horizon DNS to keep that subtree on their local network?

For whatever reason, people like short names where short means two components.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tim Wicinski]

(no hats here)


On Mon, Jun 15, 2020 at 1:48 PM John Levine  wrote:

> In article <
> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
> write:
> >E.g. use an FQDN belonging to you (or your company), so the namespace
> would
> >be example.com.zz under which your private names are instantiated.
>
> The obvious question is if an organization is willing to use
> example.com.zz, why wouldn't they use zz.example.com with split
> horizon DNS to keep that subtree on their local network?
>
>
or since domains are cheap, why not buy a new domain, and use that for the
namespace?
A wise person liked to remind me "Namespaces are architecture decisions".
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Scott Morizot]

On Mon, Jun 15, 2020 at 12:59 PM Tim Wicinski  wrote:

> On Mon, Jun 15, 2020 at 1:48 PM John Levine  wrote:
>
>> In article <
>> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
>> write:
>> >E.g. use an FQDN belonging to you (or your company), so the namespace
>> would
>> >be example.com.zz under which your private names are instantiated.
>>
>> The obvious question is if an organization is willing to use
>> example.com.zz, why wouldn't they use zz.example.com with split
>> horizon DNS to keep that subtree on their local network?
>>
>>
> or since domains are cheap, why not buy a new domain, and use that for the
> namespace?
> A wise person liked to remind me "Namespaces are architecture decisions".
> tim
>
>
Or use a combination of both approaches (separate second level domain and
distinct subdomains in a shared public/private domain tree) if that fits
your needs. The different aspects are for distinct needs. At work, for
instance, we use a completely separate second level domain tree for many of
our primary Active Directory forests and their constituent domains. We use
private subdomain trees under our public second level domain for many other
things. The appropriate internal/external boundaries require some thought
and ongoing management, but it's not especially difficult.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Brian Dickson]

On Mon, Jun 15, 2020 at 10:47 AM John Levine  wrote:

> In article <
> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
> write:
> >E.g. use an FQDN belonging to you (or your company), so the namespace
> would
> >be example.com.zz under which your private names are instantiated.
>
> The obvious question is if an organization is willing to use
> example.com.zz, why wouldn't they use zz.example.com with split
> horizon DNS to keep that subtree on their local network?
>

There are lots of reasons that are subtle.
The main one is failure modes and the implications.
I.e. Attempting to use a third-party resolver, or if a VPN disconnects,
etc. should only send queries to the root servers (and get NXDOMAIN
responses).
Similarly, any operational failure on the split-brain itself has the same
result (root servers only).

Another one is search lists. Using search lists with domains that terminate
in one of these non-TLDs (e.g. zz) ensures that the same semantics applies
(root only).

This is one place where QNAME minimization is also significantly beneficial.

Independent of this proposal, I think it would be good to delegate these
non-TLDs to the AS112++ servers (RFC 7535), to limit impact on the root
servers.

Also independent of that, I also think it might be worth considering
whether/how to upgrade RFC 7534 to use a signed zone and securely
delegating to that from as112.arpa.

One completely bonkers idea would be to deploy a wildcard delegation in the
root zone to AS112++ servers, rather than doing piecemeal delegations, but
that's not a hill I'm willing to die on. :-)


> For whatever reason, people like short names where short means two
> components.
>

Yes, and people like ponies.

The only time short names have any applicability is when connecting to
hosts directly, e.g. with SSH, and where some form of search list appends
the rest of the name.
That practice is better handled within SSH config files rather than in DNS
search lists.

Someone should write that up as a BCP. :-)

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Paul Vixie]

On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> (no hats here)
> 
> ...
> > 
> > The obvious question is if an organization is willing to use
> > example.com.zz, why wouldn't they use zz.example.com with split
> > horizon DNS to keep that subtree on their local network?
> 
> or since domains are cheap, why not buy a new domain, and use that for the
> namespace?

that makes internet viral, and private communications require global 
allocations for no necessary reason. the above quite describes centralization 
for the sake of centralization. nothing should be centralized unless there's 
no other way to do what needs doing.

reserving a corner of the namespace for decentralized operations makes sense.

-- 
Paul


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Suzanne Woolf]

Dear colleagues,


It will be helpful to the chairs in considering the future of this draft if 
folks could keep a few things in mind as we discuss it.

1. This draft as written takes no formal action to reserve anything for any 
particular purpose. It makes some observations about the administration of ISO 
3166 and its use in the ICANN context, and suggests to operators and 
implementers that the ISO3166 user-assigned 2-letter strings could be suitable 
for local use in domain names. It does not include any IANA actions to update 
any registry or protocol element. So claims that this draft reserves names or 
attempts to override ICANN policy about “TLDs” seem premature.

We’ve heard concerns that by encouraging people to use these strings in local 
DNS contexts, an RFC with no IANA actions could have the effect of constraining 
future ICANN policy. This brings us to:

2. If we want to know what ICANN-the-organization thinks of this proposal, 
there is a mechanism for asking that question. The IAB, on behalf of the IETF, 
maintains a liaison relationship with ICANN, in the form of a non-voting 
liaison to the ICANN Board of Directors, who can be asked to convey a question 
or statement about an issue of mutual interest. We’ve used this capability 
before, and intend to ask the IAB to make use of this liaison relationship 
again if the WG wants to proceed on this draft. 

As one of the draft authors already wrote to the list, the draft does not offer 
an official position or commitment by ICANN as an organization. (Under our 
process, affiliation of a draft author can’t be used to infer such statements, 
either.) That’s literally what liaisons are for: to allow the IETF to interact 
with a standards or policy body as an organization.

3. When several proposals came to the IETF more or less at once regarding 
“special use domain names”, which proponents were insisting had to be 
single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB 
and IESG — set those proposals aside in hopes of finding a less time-consuming, 
more scalable, and less dramatic way of considering changes to the special use 
names registry than having an open-ended IETF Last Call, since there’s almost 
no technical guidance in RFC 6761 to determine whether a specific request is 
useful or even valid. 

This did not happen. RFC 8244 was published in 2017, but several drafts 
attempting to solve parts of the problem it described met with very little 
interest from the WG.

The chairs are reluctant to spend WG time in this area unless there’s 
reasonably clear benefit.  If there is, we’re happy to work with the WG, the 
IAB, ICANN liaison, et. al. to manage any governance issues.


Best,
Suzanne, Tim, and Benno



> On Jun 12, 2020, at 11:12 AM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run 
> regular calls for adoptions over the next few months.   We are looking for 
> *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-arends-private-use-tld
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 26 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Wes Hardaker]

Suzanne Woolf  writes:

> 1. This draft as written takes no formal action to reserve anything
> for any particular purpose.

No, but it does make the recommendation to use unreserved space.  But it
"proposes that nay of them can be used by a network or application for
private use." [section 5].  Fundamentally, the end effect is the same:
we recommend you use these "unreserved" code points.  The net effect in
real world traffic will likely be the same (by design).  And the net
effect in policy will likely be the same: a potential collision that
forces other organizations to never register them because the defacto
standard created by this non-registration would be to treat it like it
was a registration.  [see .onion]

> 2. If we want to know what ICANN-the-organization thinks of this
> proposal, there is a mechanism for asking that question. The IAB, on
> behalf of the IETF, maintains a liaison relationship with ICANN, in
> the form of a non-voting liaison to the ICANN Board of Directors, who
> can be asked to convey a question or statement about an issue of
> mutual interest.

Yes, but they didn't do that.  I do suggest we do just that before
accepting this as a viable path forward.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Paul Vixie  wrote:
> On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> >
> > or since domains are cheap, why not buy a new domain, and use that for the
> > namespace?
>
> that makes internet viral, and private communications require global
> allocations for no necessary reason. the above quite describes centralization
> for the sake of centralization. nothing should be centralized unless there's
> no other way to do what needs doing.
>
> reserving a corner of the namespace for decentralized operations makes sense.

There are perhaps three contexts that you might want a private namespace:

* enterprisey setups

* home setups

* splendid isolation

For both the enterprise and home case, you're probably going to want to do
things beyond the DNS that are much easier if you're part of a global
namespace - TLS certs are probably the main one. For the enterprise case,
getting a suitable domain is normal. For the home case, it would make
sense for manufacturers of home gateways / access points to allocate a
per-customer subdomain. Then you can have IPv6 prefix delegation and
managed access to your devices at home without everything being proxied
via some cloud server. (I can dream?)

For splendid isolation, you're already committing to setting up your own
CA and distributing keys, so you can probably set up your own fake root
zone and whatever else. I don't think it's something that should be
encouraged as a standard thing to do, though. How could it be made to work
usefully for non-technical home users?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lands End to St Davids Head including the Bristol Channel: Variable 2 to 4.
Slight in west, smooth in east. Showers, thundery at times. Good, occasionally
poor.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Paul Wouters]

On Mon, 15 Jun 2020, Suzanne Woolf wrote:


1. This draft as written takes no formal action to reserve anything for any 
particular purpose. It makes some observations about the administration
of ISO 3166 and its use in the ICANN context, and suggests to operators and 
implementers that the ISO3166 user-assigned 2-letter strings could be
suitable for local use in domain names. It does not include any IANA actions to 
update any registry or protocol element. So claims that this draft
reserves names or attempts to override ICANN policy about “TLDs” seem premature.


In a way, this is even worse. It is "marking" some TLD strings in a
special way, without any official IANA registry or ICANN policy anywhere.

We have already seen discussion on how this could lead to increased root
zone traffic, privacy leaks to public DNS, and the possible requirement
of adding things to AS112.


3. When several proposals came to the IETF more or less at once regarding 
“special use domain names”, which proponents were insisting had to be
single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB 
and IESG — set those proposals aside in hopes of finding a less
time-consuming, more scalable, and less dramatic way of considering changes to 
the special use names registry than having an open-ended IETF Last
Call, since there’s almost no technical guidance in RFC 6761 to determine 
whether a specific request is useful or even valid. 


This has come up before, and I do feel I need to again correct
this. All but one proposal was set aside. The .onion was given a strange
exception. This came after the WG told the draft authors to split the
single draft into multiple versions for the different TLDs requested,
and so .onion appeared in a separate draft _after_ that instruction.

It seems a bit of rewriting history to now claim "several proposals came
to the IETF more or less at once".


The chairs are reluctant to spend WG time in this area


I concur. The DNSOP WG is not the proper place to discuss this, based
on the previous handling of Special Use Domains brought to the WG.
Furthermore, those discussions caused the WG quite some delay in handling
actual DNS protocol and operational issues.

Paul

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Paul Vixie]

On Monday, 15 June 2020 22:00:31 UTC Tony Finch wrote:
> Paul Vixie  wrote:
> > ...
> > 
> > reserving a corner of the namespace for decentralized operations makes
> > sense.
> There are perhaps three contexts that you might want a private namespace:
> 
> ...

there are perhaps more than three, and some might not be yet known by those who 
will 
want them. the reason why some part of the DNS namespace should be reserved in 
the 
form, "shall never be allocated by IANA", is not because we cannot think of a 
good 
enough and present cause why such a thing may be desirable.

setting a wildcard to point at AS112 makes perfect sense to me.

the document can remind that there's no uniqueness among unregistered domains, 
and 
that any name which might be partially or occasionally or eventually visible to 
a supplier, 
customer, partner, or acquirer should not be placed inside the reserved-name 
TLD due to 
unreachability and/or collision problems.

nothing should be centralized that does not have to be.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Paul Vixie  wrote:
>
> there are perhaps more than three, and some might not be yet known by those 
> who will
> want them. the reason why some part of the DNS namespace should be reserved 
> in the
> form, "shall never be allocated by IANA", is not because we cannot think of a 
> good
> enough and present cause why such a thing may be desirable.

Fair enough, but what you are suggesting seems to be quite different from
what this draft is suggesting. You seem to be talking about reserving for
future use, or for lab environments that never connects to any other part
of the Internet, whereas this draft is just suggesting that everyone
should use these ISO 3166 reserved codes as a 192.168 free-for-all instead
of .lan or .home or whatever they are currently squatting on.

I.e. the proposed use case is already widely deployed and known to be a
bad idea.

The intro to this draft talks about things like x- which has been
deprecated since RFC 6648. It mentions some situationw where .test or
..invalid would seem to be the right things to use, but it doesn't say why
not. It lists a bunch of TLDs that are being squatted by devices that
ought to move to home.arpa instead, but doesn't say why we have given up
on that idea after only a couple of years, or why we should expect them to
move to ISO 3166 reserved codes when they haven't moved to home.arpa.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Roy Arends]

Hi Mike,

> On 14 Jun 2020, at 21:12, Michael StJohns  wrote:
> 
> Roy et al - 
> 
> Is there a document from ICANN taking a position on the assignment of TLDs 
> based on  ISO3166 assignments?   

Yes: https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en

From that page:

"In 2000, the ICANN Board of Directors recognized the ISO 3166 Maintenance 
Agency as the authoritative entity for country code designations and officially 
adopted the use of ISO 3166-1 and the 3166-MA exceptional reserved list as the 
set of eligible designations for ccTLD assignment (September 2000)”

Please note that:

The ISO/TC46/WG2 “owns” ISO3166. Any substantial changes to it, need to go 
through TC46. The user-assigned two letter codes exist since the inception of 
the standard (15 december 1974).

TC46/WG2 has designated the User-Assigned two letter codes to users of the 
ISO3166-1 standard (not to the Maintenance Agency!)

TC46/WG2 refers the remaining codes to the Maintenance Agency for the 
assignment (Reserved, Assigned, Re-Assigned, Deleted, etc, etc) of two letter 
codes to country names.

The ISO3166/MA has no authority over the User-Assigned two letter codes.

It is naive to think that these policies, some of which pre-dates ICANN and 
even the Internet would be ignored by either ICANN or the ISO. 

I think it is safe to assume that these codes will never by delegated in the 
root zone.

> When Jon was doing this he was adamant about following their lead - rather 
> than having to make political decisions about what was a country.  The main 
> role he had was not the selection of the TLDs, but making sure that the 
> delegations went to the right organizations related to the countries 
> indicated by the TLD.   I would say that ICANN should probably have the same 
> role.   

I agree.

> Given that ISO has indicated a range of specifically NOT issued 2 letter 
> codes, and that these codes will never (should never?) be added to the root 
> zone, I would suggest that it's probably not an ICANN role to weigh in on 
> this interpretation.

I agree.

> That said, I'd prefer it if the document selected a few (<=10) codes from 
> these ranges so that filtering may be built into various servers and clients 
> to prevent leakage.  

With all due respect, I’ll wait with responding about specifics until the WG 
has adopted the document (if at all).

Warmly, 

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Paul Vixie]

On Monday, 15 June 2020 22:46:17 UTC Tony Finch wrote:
> Paul Vixie  wrote:
> > there are perhaps more than three, and some might not be yet known by
> > those who will want them. the reason why some part of the DNS namespace
> > should be reserved in the form, "shall never be allocated by IANA", is
> > not because we cannot think of a good enough and present cause why such a
> > thing may be desirable.
> 
> Fair enough, but what you are suggesting seems to be quite different from
> what this draft is suggesting. You seem to be talking about reserving for
> future use, or for lab environments that never connects to any other part
> of the Internet, whereas this draft is just suggesting that everyone
> should use these ISO 3166 reserved codes as a 192.168 free-for-all instead
> of .lan or .home or whatever they are currently squatting on.

i expect the problem statement and proposed solution to be subject to the usual 
WG 
process. it's possible that the ISO 3166 reservations _should_ stand. or else, 
that a new 
IETF-reserved code should be created. i'm not using .local at the moment, but i 
remember 
collision studies around .corp and .home. i'm not sure i care how the IETF 
promises never 
to allow some tld to be delegated (other than as a wildcard pointing to AS112, 
or similar), 
but i'd like to see it.

> I.e. the proposed use case is already widely deployed and known to be a
> bad idea.

known by whom, and how? (got URL?) 

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Geoff Huston]

> On 16 Jun 2020, at 8:12 am, Paul Wouters  wrote:
> 
> On Mon, 15 Jun 2020, Suzanne Woolf wrote:
> 
>> 1. This draft as written takes no formal action to reserve anything for any 
>> particular purpose. It makes some observations about the administration
>> of ISO 3166 and its use in the ICANN context, and suggests to operators and 
>> implementers that the ISO3166 user-assigned 2-letter strings could be
>> suitable for local use in domain names. It does not include any IANA actions 
>> to update any registry or protocol element. So claims that this draft
>> reserves names or attempts to override ICANN policy about “TLDs” seem 
>> premature.
> 
> In a way, this is even worse. It is "marking" some TLD strings in a
> special way, without any official IANA registry or ICANN policy anywhere.
> 
> We have already seen discussion on how this could lead to increased root
> zone traffic, privacy leaks to public DNS, and the possible requirement
> of adding things to AS112.

+1

Geoff

(I must admit to being more confused than enlighted after Suzanne’s post!)


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Roy Arends]

> On 15 Jun 2020, at 22:51, Wes Hardaker  wrote:
> 
> Suzanne Woolf  writes:
> 
>> 1. This draft as written takes no formal action to reserve anything
>> for any particular purpose.
> 
> No, but it does make the recommendation to use unreserved space.

No.

This is not unreserved space. This is space reserved, for the user. By the ISO, 
blessed by RFC1591.

>  But it
> "proposes that nay of them can be used by a network or application for
> private use." [section 5].

Yes, as designed by the original drafters of the ISO3166 standards and used 
today, as intended, by a wide variety of organisations, including the IETF.

>  Fundamentally, the end effect is the same:
> we recommend you use these "unreserved" code points.

Not unreserved.

>  The net effect in
> real world traffic will likely be the same (by design).

Sure.

>  And the net
> effect in policy will likely be the same: a potential collision that

What?

> forces other organizations to never register them because the defacto
> standard created by this non-registration would be to treat it like it
> was a registration.  [see .onion]

The can never be registered. There is no collision. That is the point of all of 
this.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Paul Vixie  wrote:
>
> > I.e. the proposed use case is already widely deployed and known to be a
> > bad idea.
>
> known by whom, and how? (got URL?)

Gosh well I thought this was widely agreed folklore / common sense since
the 1990s and I'm not in the habit of collecting links to essays on "why X
is a bad idea" when it seems from my perspective that approximately nobody
writes essays like that because X is obviously a bad idea... :-)

But, we know that overlapping name spaces and address spaces are a
nightmare for mergers and acquisitions.

It's incompatible with private interconnects, such as organizations
collaborating without mergeing, or home-to-home VPNs.

We know that non-unique namespaces are incompatible with the web security
model.

We know that it's incompatible with PKIX. (You can do private x.509 but
not public.)

We know it's incompatible with DNSSEC. (You can set up a private root, but
then we're back to splendid isolation and arcane technical expertise.)

Overall it scuppers much of the protocols that support end-to-end
connectivity and security.

And the breakage is unnecessary because we know there are straightforward
alternatives that avoid the problems.

[ I am maybe exaggerating a bit about the 1990s, because back then, when
Microsoft Small Business Server was encouraging everyone and their dog to
squat on .local, domain names were 10x more expensive than now and 100x
more difficult to obtain, so they had a reasonable excuse, but it was
still terrible. ]

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Channel Islands: South to southeast 2 to 4, becoming variable 1 to 3 by early
afternoon, then northwest 1 to 3 by midnight. Smooth or slight. Scattered
thundery showers, mainly near French coasts, risk of mist or fog patches,
mainly in the north of the area. Moderate or good, occasionally poor, perhaps
locally very poor.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Christian Huitema]

On 6/15/2020 4:30 PM, Geoff Huston wrote:
>> On 16 Jun 2020, at 8:12 am, Paul Wouters  wrote:
>>
>> On Mon, 15 Jun 2020, Suzanne Woolf wrote:
>>
>>> 1. This draft as written takes no formal action to reserve anything for any 
>>> particular purpose. It makes some observations about the administration
>>> of ISO 3166 and its use in the ICANN context, and suggests to operators and 
>>> implementers that the ISO3166 user-assigned 2-letter strings could be
>>> suitable for local use in domain names. It does not include any IANA 
>>> actions to update any registry or protocol element. So claims that this 
>>> draft
>>> reserves names or attempts to override ICANN policy about “TLDs” seem 
>>> premature.
>> In a way, this is even worse. It is "marking" some TLD strings in a
>> special way, without any official IANA registry or ICANN policy anywhere.
>>
>> We have already seen discussion on how this could lead to increased root
>> zone traffic, privacy leaks to public DNS, and the possible requirement
>> of adding things to AS112.
> +1

Geoff,

I am old enough to know that we should never challenge worse, as in
"root traffic cannot possibly get much worse than what it already is".
But then, I truly wonder whether Roy's suggestion would make the problem
worse. At worse, the IETF position would be shifting from "we don't
recognize the need for private domains so use whatever you think of" to
"if you really want to use a private domain, use one of these reserved
2-letter codes." It would seem that using a small set of code would
increase the efficacy of negative caching, and would thus tend to
diminish the traffic to the root.

And now, for a "Carthago delenda est" moment, let's point out that
almost 50% of the traffic to the root comes from the Chrome browser
making up randomly named TLD to probe whether the local ISP is hijacking
NXDomain replies. If we really want to reduce the leaks to the root,
there is that.

-- Christian Huitema

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Wes Hardaker]

Roy Arends  writes:

> The can never be registered. There is no collision. That is the point
> of all of this.

Then why does your draft say "unlikely" in multiple places rather than
the strength of your wording above: "can never"?
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Roy Arends]

> On 16 Jun 2020, at 01:18, Wes Hardaker  wrote:
> 
> Roy Arends  writes:
> 
>> The can never be registered. There is no collision. That is the point
>> of all of this.
> 
> Then why does your draft say "unlikely" in multiple places rather than
> the strength of your wording above: "can never"?

I use unlikely twice (2, two times, not more).

The first time I use the term “extremely unlikely” because the generally 
accepted term for “never", without having to say “never” is “Highly unlikely” 
was not strong enough IMHO.

The second time I use the term unlikely was: "It is unlikely that the 
user-assigned range will change.” which refers to the probability of the range 
changing. 

I had “extremely unlikely” here as well at first, but then noticed that “OO” 
can be utilised to indicate that code elements other than those defined in the 
ISO 3166 are used, If the number of user-assigned code elements in 8.1.3 is not 
sufficient to cover a particular user requirement. I will fix that in the next 
release to say “extremely unlikely”, and explicitly exclude “OO” from the list.

I hope that works for you,

Thanks

Warmly,

Roy







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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Brian Dickson]

On Mon, Jun 15, 2020 at 3:00 PM Tony Finch  wrote:

> Paul Vixie  wrote:
> > On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> > >
> > > or since domains are cheap, why not buy a new domain, and use that for
> the
> > > namespace?
> >
> > that makes internet viral, and private communications require global
> > allocations for no necessary reason. the above quite describes
> centralization
> > for the sake of centralization. nothing should be centralized unless
> there's
> > no other way to do what needs doing.
> >
> > reserving a corner of the namespace for decentralized operations makes
> sense.
>
> There are perhaps three contexts that you might want a private namespace:
>
> * enterprisey setups
>
> * home setups
>

No. Just No.

At most, home setups may not want dedicated registered domains (that they
pay money for directly to a registrar and indirectly to a registry).
However, they absolutely need to have functioning global DNS ability,
regardless of the parent domain(s) they might use.

As long as they are able to have a workable FQDN, regardless of whether it
is ephemeral or a stable name, that is the minimum requirement.

As your argument below points out, any decentralized thing can't be used
for this (regardless of whether it's anchored in 2-letter ISO space or
underneath some arpa child).


>
> * splendid isolation
>
> For both the enterprise and home case, you're probably going to want to do
> things beyond the DNS that are much easier if you're part of a global
> namespace - TLS certs are probably the main one. For the enterprise case,
> getting a suitable domain is normal. For the home case, it would make
> sense for manufacturers of home gateways / access points to allocate a
> per-customer subdomain. Then you can have IPv6 prefix delegation and
> managed access to your devices at home without everything being proxied
> via some cloud server. (I can dream?)
>

The enterprise case is not a single case, and is the exception that proves
the point.
As much as it may require more technically savvy operations, if there is a
need for both an internet-reachable
and a non-internet-reachable subsection of their infrastructure, having
different name spaces with different properties
is the answer that best fits their needs.

Internal-only use is not only satisfied with non-delegated name spaces, it
actually is a much better fit for everything.
Both DNSSEC and PKIX (or more likely, DANE/TLSA for X.509 certs) are better
fits for the internal-only case.
The goal for internal only, is to ensure it CANNOT work over the internet,
not just that it isn't guaranteed to work over the internet.
You WANT resolution to fail. You WANT certificate validation to fail. You
WANT DNSSEC validation to fail.
Anchoring all of these things in a non-global namespace (which is still
sufficiently well-defined to be highly collision resistant) is the ideal
choice.

This has NOTHING to do with the parts of an enterprisey setup for the parts
that are meant to be internet-reachable.

Trying to force the two things together for some perceived benefit is
unwise in the extreme.
As Randy Bush often says, to paraphrase, I encourage my competitors to do
this.
Except I'm not Randy, and I wouldn't encourage ANYONE to do this. That's
just mean.


>
> For splendid isolation, you're already committing to setting up your own
> CA and distributing keys, so you can probably set up your own fake root
> zone and whatever else. I don't think it's something that should be
> encouraged as a standard thing to do, though. How could it be made to work
> usefully for non-technical home users?
>

You don't want home users doing this, ever.
Even the most extreme cases in homenet WG still envision having their stuff
linked below the DNS equivalent of a prefix delegation, optionally.

If there is any ambiguity in the draft to the effect that anyone other than
the non-internet-reachable enterprisey or the splendid isolation use cases,
let's make the document better to that effect.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Joe Abley]

On Jun 15, 2020, at 18:46, Tony Finch  wrote:

> The intro to this draft talks about things like x- which has been
> deprecated since RFC 6648. It mentions some situationw where .test or
> ..invalid would seem to be the right things to use, but it doesn't say why
> not. It lists a bunch of TLDs that are being squatted by devices that
> ought to move to home.arpa instead, but doesn't say why we have given up
> on that idea after only a couple of years, or why we should expect them to
> move to ISO 3166 reserved codes when they haven't moved to home.arpa.

I don't remember any text in the document that talked about people changing 
what they are doing. I thought the point of it was to provide some guidance for 
people who have decided (for whatever reason) that they have a use for a 
private namespace anchored by a TLD but who haven't decided what to use yet.

Personally, I think the right advice for most people is that if you must use 
private namespace you should anchor it at a domain name in the global namespace 
that you control, so that your namespace is both private and unique. Someone 
should write that document. I'll help, if someone is interested.

But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that kind 
of general advice; it provides specific advice for the case where people have 
decided that a TLD is definitely needed by pointing out that the 3166 people 
have already reserved a label for them to use and that current ICANN policy is 
that such label will never clash with a real (non-private) TLD.

Note that without this document, the above will still be true. The 
two-character codes mentioned in this document will still be available for use 
for whatever purpose people can dream up, and will still not be delegated by 
ICANN. This document just writes it down so that people don't have to do the 
consderable homework to reach that conclusion themselves.

I continue to think that using policy that already exists to solve a problem 
that apparently some poeple have without asking anybody to change anything at 
all is a thing of great and enduring beauty, and I'm quite surprised that so 
many people are trying to hard to turn it into something more difficult to 
agree with.

Perhaps we've all been deprived of mic lines for long enough that we have some 
pent-up need to make things complicated.


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Brian Dickson  wrote:

> Internal-only use is not only satisfied with non-delegated name spaces, it
> actually is a much better fit for everything.

Yes, I agree, but why does the point of non-delegation have to be a
squatted collision-prone TLD, rather than a guaranteed collision-free
subdomain of a properly registered domain?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, North Thames: Variable 2 to 4. Smooth, occasionally slight. Fog banks.
Moderate, occasionally very poor.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Brian Dickson]

On Mon, Jun 15, 2020 at 5:59 PM Tony Finch  wrote:

> Brian Dickson  wrote:
>
> > Internal-only use is not only satisfied with non-delegated name spaces,
> it
> > actually is a much better fit for everything.
>
> Yes, I agree, but why does the point of non-delegation have to be a
> squatted collision-prone TLD, rather than a guaranteed collision-free
> subdomain of a properly registered domain?
>

Precisely because you want a non-TLD (we should remember this is NOT an
actual TLD), for a number of reasons:

   - You want to be able to limit the places any leaked traffic goes
  - Currently this would be the Root Servers
  - I think it would make sense for non-TLDs to be DNAME'd to AS112++'s
  empty zone (which generates an NXDOMAIN)
 - Either as specific names, or as a wildcard
  - The typical content of enterprisey internal-only names (the DNS
   queries themselves) are sensitive in nature
  - I have had the opportunity to view DITL data from ISP resolvers,
  and the nature of these kinds of queries was unsettling
  - In addition to leaking information, these names generally should
  not have any presence in DNS caches, which makes them excellent
candidates
  for easy poisoning
   - As I pointed out elsewhere in this thread, collision avoidance without
   revealing information can be done easily enough,
  - E.g. with use of a 12-character random string of letters and digits
  - 36^12 is pretty collision-resistant.
  - Use one of these, enterprise-wide
  - Or even site-wide at a sub-enterprise level if site-site isn't a
  requirement.

You can only squat on a property. This is a non-property, so technically it
is not squatting, appearances notwithstanding.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Joe Abley  wrote:
> On Jun 15, 2020, at 18:46, Tony Finch  wrote:
>
> > The intro to this draft talks about things like x- which has been
> > deprecated since RFC 6648. It mentions some situationw where .test or
> > ..invalid would seem to be the right things to use, but it doesn't say why
> > not. It lists a bunch of TLDs that are being squatted by devices that
> > ought to move to home.arpa instead, but doesn't say why we have given up
> > on that idea after only a couple of years, or why we should expect them to
> > move to ISO 3166 reserved codes when they haven't moved to home.arpa.
>
> I don't remember any text in the document that talked about people
> changing what they are doing.

Yes, that's why I pointed it out. The intro fairly explicitly says it's a
replacement for .lan (etc.), but that raises questions about how this
draft relates to other efforts to fix the .lan problem. I think people
will read this draft as saying, don't do that home.arpa thing, don't do
that .lan thing, do this.

> Personally, I think the right advice for most people is that if you must
> use private namespace you should anchor it at a domain name in the
> global namespace that you control, so that your namespace is both
> private and unique. Someone should write that document. I'll help, if
> someone is interested.

I agree that is the right advice.

> But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that
> kind of general advice; it provides specific advice for the case where
> people have decided that a TLD is definitely needed by pointing out that

Can't we continue to point out that they are wrong and there are better
ways of solving their problems?

I also appreciate that this draft is very clever, but speaking as an IOCCC
winner, very clever things can also be things you should never do in
production.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Mainly westerly or northwesterly, 3 to 5, occasionally 6 in
southeast. Moderate, occasionally slight. Showers in north. Good.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Brian Dickson  wrote:
>
> Precisely because you want a non-TLD (we should remember this is NOT an
> actual TLD), for a number of reasons:
>
>- You want to be able to limit the places any leaked traffic goes
>   - Currently this would be the Root Servers

And any resolvers in between there and roaming users.

>   - The typical content of enterprisey internal-only names (the DNS
>queries themselves) are sensitive in nature
>   - I have had the opportunity to view DITL data from ISP resolvers,
>   and the nature of these kinds of queries was unsettling
>   - In addition to leaking information, these names generally should
>   not have any presence in DNS caches, which makes them excellent
> candidates
>   for easy poisoning

These issues happen in exactly the same way whether you squat on a tld or
use a private subdomain.

The draft doesn't talk about random subdomains; instead it says that part
of the point is to make names as short as possible. And our experience
with telling people to use random parts of private address space (as in
RFC 1918, and IPv6 GUA) is that they don't.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Foreland to Selsey Bill: Southerly or southwesterly, becoming variable
at times, 2 or 3, occasionally 4 until later. Smooth, occasionally slight. Fog
patches for a time near shore. Moderate or good, occasionally very poor for a
time near shore.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Joe Abley]

On Jun 15, 2020, at 21:21, Tony Finch  wrote:

> Yes, that's why I pointed it out. The intro fairly explicitly says it's a
> replacement for .lan (etc.), but that raises questions about how this
> draft relates to other efforts to fix the .lan problem.

I think your reading of the text just indicates that it could be tightened up 
to be clearer, since I read it differently (it's a replacement choice, is my 
understanding).

I think the presence of ambiguity is an indication that a working group could 
improve thiss document.

>> But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that
>> kind of general advice; it provides specific advice for the case where
>> people have decided that a TLD is definitely needed by pointing out that
> 
> Can't we continue to point out that they are wrong and there are better
> ways of solving their problems?

I have wondered that myself, but I suppose there will always be people for whom 
registering a domain and keeping it registered is a worse answer than simply 
configuring something.

I also don't find the technical arguments that apparently make a fake TLD a 
better choice than a registered domain very compelling. I have wondered aloud 
whether there is data to support the asssertion that people are squatting on 
TLDs because of a need, or by accident or for some other reason; whether or not 
using a non-delegated TLD is in fact more common than using a registered domain 
at an anchor today; whether use of non-delegated TLDs is growing along axes 
that strongly indicates that this is a widespread problem and not something 
isolated to a handful of vendors; whether that growth still looks like growth 
when it's normalised against other variables that are trending up and to the 
right, etc, etc, etc.

However, given that this document only points out an option that already exist 
and doesn't actually recommend using a TLD versus any other anchor, I don't 
think any of that matters. I think it's up to another document to provide that 
kind of advice. It's hard to see any advantage in shoe-horning that advice into 
this one -- and the chances of such a document converging any time soon, 
regardless of venue. seem slim

> I also appreciate that this draft is very clever, but speaking as an IOCCC
> winner, very clever things can also be things you should never do in
> production.

I think the most clever thing about it is that it describes what is already 
there and doesn't ask any difficult questions or require any difficult 
decisions to be made. (Maybe your C code does that too, but if it does I 
presume that's not why you wouldn't run it in production :-)


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Brian Dickson]

On Mon, Jun 15, 2020 at 6:30 PM Tony Finch  wrote:

> Brian Dickson  wrote:
> >   - In addition to leaking information, these names generally should
> >   not have any presence in DNS caches, which makes them excellent
> > candidates
> >   for easy poisoning
>
> These issues happen in exactly the same way whether you squat on a tld or
> use a private subdomain.
>

Actually, no, or rather, it (susceptibility to poisoning) might depend.
Here's why:

The root zone is DNSSEC signed with NSEC.
It is literally impossible for anyone to poison any name at or below a
non-TLD.

A private subdomain of a real domain, only has the same properties if the
real domain is DNSSEC signed (chained from the root), and the public
version of that domain's zone denies the existence of the private subdomain.
I.e. that isn't going to be 100% true ever, and today has only a small
statistical chance of being true (DNSSEC uptake globally being about 1%).

In any case, the argument I'm making is 100% is tautologically optimal, and
the best any single enterprise can do is match that.

It's likely more reliable and easier to go the non-TLD route for all but
the most technically savvy enterprises (who probably won't rely on this
document regardless.)

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

Re: [DNSOP] SVCB ALPN value presentation format

[Mark Andrews]

> On 14 Jun 2020, at 05:01, Larry Campbell 
>  wrote:
> 
> I think there's an implementation difficulty. Consider:
> 
> 1.  alpn=h2   ; clear enough
> 2.  alpn="h2" ; should be equivalent
> 3.  alpn=\h\2 ; should also be equivalent
> 4.  alpn=h2,h3; ok (two values)
> 5.  alpn="h2","h3"; should be equivalent

No, as it is key=quoted-string as per 2.1.1 not 
key=quoted-string(,quoted-string\)*

> 6.  alpn="h2,h3"  ; malformed? or a single alpn value of h2,h3? or two 
> three-character values, "h2 and h3”?

this is correct

> 7.  alpn=h2\,h3,h4; how should this be parsed?

0x05 0x68 0x32 0xc2 0x68 0x33 0x02 0x68 0x34

> Section 2.1.1 tempts one to build the obvious implementation of using one's 
> existing character-string parser, and then passing the parsed 
> character-string to the individual handler for each key type. The alpn and 
> ipv*hint handlers are going to want to split that character-string on comma. 
> That would treat #6 as two two-character values (h2,h3). But #7 is 
> problematic: the generic character-string parser would remove the backslash, 
> and then the alpn handler would treat this as three alpn values when you 
> probably wanted just two

When you are also parsing domain names you have to deal with \. being a literal 
period not a domain separator.
exa\.mple.com and “exa\.mple.com” aree being two labels ‘exa.mple’ and ‘com’.  
This is not really different.

That said we do need to address this issue.

In BIND we extract quoted-string preserving the escapes (except for ‘\”’) then 
pass the token to a domain name parser or a text parser. Having ‘key=‘ 
preceding the quoted-string is more of a issue and we have to shift modes 
mid-token.

> We could make a special character-string parser for alpn and ipv*hint, that 
> handles commas, but it feels odd to have to use a special parser just for 
> certain key types. However, if we must allow commas in alpn names, then we 
> have no choice.

You need to reparse value for port, alpn, ipv*hint,

> Perhaps it would be clearer to simply remove the three paragraphs of section 
> 2.1.1 beginning with "The presentation for for SvcFieldValue is..." and 
> ending with "...not limited to 255 characters.)". Since the previous 
> paragraph says "Values are in a format specific to the SvcParamKey", perhaps 
> it would be best to leave the description of each value format in the 
> appropriate part of section 6 and for section 2.1.1 to discuss only how to 
> represent and parse unrecognized keys.


> 
> To keep the implementation simple, the alpn value could be defined as a 
> comma-separated list of sequences of printing ASCII characters, with embedded 
> comma represented as \, backslash as \\, and all nonprinting and non-ASCII 
> characters reprsented as \nnn. (In other words, the full generality of 
> character-string, particularly double-quotes, is not needed here.
> 
> The other comma-separated value types -- ipv4hint and ipv6hint -- do not have 
> this difficulty; they also don't need the full generality of character-string 
> handling, because the individual values can contain only hex digits, periods, 
> and colons, so their specification and implementation can be much simpler.
> 
> And I think section 2.1.1 would be clearer if
> 
>using decimal escape codes (e.g. \255) when necessary
> 
> were replaced by
> 
>using decimal escape codes (e.g. \255) for all nonprinting and non-ASCII 
> characters, and using \\ to represent backslash
> 
> - lc
> 
> 
>> On Jun 13, 2020, at 11:25, Ben Schwartz  
>> wrote:
>> 
>> Larry,
>> 
>> I think that's the intent of the current text, especially the ABNF for 
>> "element".  If you think it's unclear, we should adjust it.  Please suggest 
>> text!
>> 
>> --Ben Schwartz
>> 
>> On Sat, Jun 13, 2020, 10:53 AM Larry Campbell 
>>  wrote:
>> Seciont 6.1 says:
>> 
>>> The presentation value of "alpn" is a comma-separated list of one or more 
>>> "alpn-id"s. Any commas present in the protocol-id are escaped by a 
>>> backslash:
>>> 
>>>escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
>>>escaped-id = 1*(escaped-octet)
>>>alpn-value = escaped-id *("," escaped-id)
>> 
>> If I read this correctly, the presentation value is allowed to contain nulls 
>> and control characters. This seems likely to make such records very 
>> difficult to edit. Wouldn't it be better to require these to be encoded as 
>> \nnn?
>> 
>> - lc
>> 
>> ___
>> 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

-- 
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] Call for Adoption: draft-arends-private-use-tld

[Tony Finch]

Joe Abley  wrote:
>
> However, given that this document only points out an option that already
> exist and doesn't actually recommend using a TLD versus any other
> anchor, I don't think any of that matters. I think it's up to another
> document to provide that kind of advice. It's hard to see any advantage
> in shoe-horning that advice into this one -- and the chances of such a
> document converging any time soon, regardless of venue. seem slim

The existence of this document and the lack of any better advice will mean
that the IETF recommendation is clear that the best setup for RFC 1918
networks is to use a reserved alpha-2 TLD. It isn't just pointing out
something that's already there, it's a massive shove encouraging people to
occupy this namespace.

As opposed to the current situation where the implicit advice is that you
should only use properly registered domain names, and reserved alpha-2
TLDs are only used by people like JP Mens in his test lab.
https://jpmens.net/2010/09/28/performing-dynamic-dns-updates-on-your-dns/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
democracy, participation, and the co-operative principle

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

[DNSOP] Hybird Resolver/ DNS invariants

[Davey Song]

Hi folks,

I happened to run into a discussion of behaviors of  Hybrid Resolver/ DNS
invariants where some of the non-typical uses of DNS are listed, especially
on the resolver. I'm encouraged to put them down as a requirement draft of
these uses of DNS and ask the mailing list whether it is a good idea. I
hope it is helpful to provide information including risk for people who are
doing or going to the same thing.

There are some existing cases in the discussion:
1. A resolver syncs (pull or receive server push) with an authoritative
server. It reduces the recursion and resolves the very-short TTL
requirement. RFC7706 provides an approach. Other resolveless approaches are
used as well..
2. A resolver can forward queries to another resolver if the load is high
to reduce the recursion.
3. A resolver/authoritative server mode serving Apps via DoH or other
Application-level DNS.  Operators of apps can edit each response on demand
and propagate the changes of DNS RR in seconds. It also provides a private
zone and names for each Apps.
4. A Hybrid DNS which is used  as a name server but cache and pull the
authoritative data from another authoritative server. It provides an
approach to easily scale the system without any change of existing
authoritative DNS.

Do you think it is a useful effort for DNSOP WG? Any suggestions or
observed related discussions on the DNS invariants?

Best regards,
Davey
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Olafur Gudmundsson]

Thom 
As I have before stated in the past, adding new DNSSEC algorithm is bad for 
interoperability, 
I oppose the adoption of this document unless there are better reasons put 
forward why this algorithm is better than
the 4 ECC algorithms that have been standardized so far. 
Better in this case could be stronger, faster, better post-quantum resistance 
etc 

Also I want to point out this last call did not specify track so my opposition 
is against all tracks, at this point. 

Olafur




> On Jun 3, 2020, at 5:07 PM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.  
> We are looking for *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 15 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> 
> ___
> 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] Hybird Resolver/ DNS invariants

[Ralf Weber]

Moin!

On 16 Jun 2020, at 4:23, Davey Song wrote:
> I happened to run into a discussion of behaviors of  Hybrid Resolver/ DNS
> invariants where some of the non-typical uses of DNS are listed, especially
> on the resolver. I'm encouraged to put them down as a requirement draft of
> these uses of DNS and ask the mailing list whether it is a good idea. I
> hope it is helpful to provide information including risk for people who are
> doing or going to the same thing.
>
> There are some existing cases in the discussion:
> 1. A resolver syncs (pull or receive server push) with an authoritative
> server. It reduces the recursion and resolves the very-short TTL
> requirement. RFC7706 provides an approach. Other resolveless approaches are
> used as well..
> 2. A resolver can forward queries to another resolver if the load is high
> to reduce the recursion.
> 3. A resolver/authoritative server mode serving Apps via DoH or other
> Application-level DNS.  Operators of apps can edit each response on demand
> and propagate the changes of DNS RR in seconds. It also provides a private
> zone and names for each Apps.
> 4. A Hybrid DNS which is used  as a name server but cache and pull the
> authoritative data from another authoritative server. It provides an
> approach to easily scale the system without any change of existing
> authoritative DNS.
>
> Do you think it is a useful effort for DNSOP WG? Any suggestions or
> observed related discussions on the DNS invariants?
Some of these are the same old combination of authoritative and recursive
function. Mixing these has caused a lot of problems, please don’t suggest
to do that again. How DoX (T, H, Q) changes the DNS landscape is yet to be
seen, but I don’t understand how answering via a different network protocol
makes a server different. The DNS tree still is the same.

What you describe is mix of observed behaviour and local implementations,
and IMHO not the best way to deploy DNS, but others may have different
opinions here. So if you want to describe these deployments, so that we can
discuss them go ahead. But I don’t think that we want to require DNS being
build that way.

So long
-Ralf
—--
Ralf Weber

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