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

[Warren Kumari <[e-mail]>]

On Thu, Jun 18, 2020 at 1:47 PM Ted Lemon <[e-mail]> wrote:
>
> It can be solved with a trust anchor as well, but that relies on there being a central validating resolver rather than validating stub resolvers on hosts, and personally I don’t find that deployment model very compelling anymore—I think that stub resolvers should validate.  If I get my way, then we’re going to see these “private” domains start to fail.

... and I should point out that this was one of the arguments in
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3
for an (insecure) delegation (just like home.arpa has). Currently
operating system vendors (and similar) cannot realistically ship
validating stub resolvers - having BYOD users suddenly unable to
resolve www.corp on your shiny new phone/tablet/laptop results in
outrage, and customers buying your competitors widget instead.

The presentation at
http://slides.com/wkumari/deck-f68ee558-abac-4af2-9357-5669734d3445-5-8#/3/0/0
(slide 6) only briefly touched on it:
Has to be a TLD for non-technical / aesthetic reasons
DNSSEC requires that this be added to the root (with a DNSSEC insecure
delegation).
-happy to cover the reasons off-line
  -no process for this.
    - Will require creating one!


People (rightly IMO) said that this isn't DNSOP work, and should be
taken to ICANN instead.



The above presentation also said:
Users want an internal / disconnected namespace
... but we told them not to do this.

Squatting on TLDs causes various issues like:
pollution of the namespace  e.g .home, .corp, .mail, ...
potentially collisions
  excess root / recursive lookups
  somewhat mitigated by Aggressive NSEC
  leaking of "internal" names

Actually we say "Use something under a registered domain"
We are the adults, this is risky behavior, you don't actually want to do this
We also preach abstinence
Regardless of what we think of the behavior, we can't stop people
doing this - but we can make it less risky.


This seems to be related to much of what was said earlier --
regardless of what we think of people using a private/internal name,
there are no protocol police, and we cannot prevent it - but we can
posibly coral the badness into fewer places...

I'm limiting my involvement in this thread - I'm also working on the
SSAC .internal document
(https://mm.icann.org/pipermail/ncap-discuss/2020-June/000432.html),
and take the ICANN SSAC confidentiality agreement seriously.
While I have asked my co-AD to be responsible for the document
(https://mailarchive.ietf.org/arch/msg/dnsop/13iQFI6V3yJ90SxbqSy8UubQ6bU/)
I'm being extra cautious in this thread...

W



>
> Sent from my iPad
>
> On Jun 18, 2020, at 1:36 PM, Vladimír Čunát <[e-mail]> wrote:
>
> 
> On 6/18/20 7:22 PM, Ted Lemon wrote:
>
> I suspect it will work like every other locally-served domain or every other private namespace that exists today, i.e. just fine with no configuration changes expected or required on dependent (downstream) DNS clients. And if there are new species of resolver that need to be accommodated (e.g. validating, hybrid stub/full service resolvers embedded in applications), whatever configuration or auto-discovery mechanisms are required to support those other locally-served zones can surely be easily extended to these ISO-3166-2 codes if they are used in any particular private network.
>
>
> What I’m getting at is that the secure denial of existence will mean that a DNSSEC-aware resolver, when asked to look up a name under .xa, for example, will always return NXDOMAIN.
>
> Yes, but squatting is usually done at root names already, so the issue isn't new.
>
> Modifying DNS past the last validator is generally troublesome.  Modifying it inside the last validating resolver can be fine, as the implementation can "prioritize" the modifications over validation and aggressive caching (but as an implementor I still find this troublesome).
>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf