Subject: [DNSOP] ALT-TLD and (insecure) delgations.

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Feb 2017 15:28:29 -0500

Hi there all,

I have just posted a new version of alt-tld, which folds in a number
of suggestions and comments from various people -- thank you for
those. As the document was parked I held off making some of the larger
edits; if you sent comments and I missed them, I apologize - please
send them again (or point at them) and I'll try address them.

The largest outstanding issue is what to do about DNSSEC -- this is
(potentially) a problem for any / all 6761 type names.
The root is signed, so if a query leaks into the DNS (as they will),
an (unaware) validating resolver will try resolve it, and will expect
either a signed answer, or proof of an insecure delegation; without
this things will look bogus, and so resolvers will SERVFAIL.

Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
simply note that validation will fail, and that SERVFAIL will be
returned in many case (to me this seems "correct"), or 2: request that
the IANA insert an insecure delegation in the root, pointing to a:
AS112 or b: an empty zone on the root or c" something similar.

This is a fine thing to request in an IANA consideratons, but isn't
necessarily *useful* -- the IANA has the technical ability to add
stuff to the root zone, but not the mandate (this is like walking into
a bank and requesting the teller gives you a bunch of money - they may
be able to do so, but aren't actually allowed to.. :-)).

Some people have suggested "Well, we (or the IAB) can just ask ICANN
politely to do add this, they are in charge of the DNS root, they'll
help out, no worries...."
Unfortunately, this is only partly accurate -- adding an (insecure)
delegation to the root would make .alt be a "real" TLD. ICANN is just
an organization, they are driven by a multistakeholder[0] process, and
there is a huge amount of process and similar around creating a new
TLD -- go read the 300+ page gTLD Applicant Guidebook (Version
2012-06-04 ) for a fun taste of this.
This would likely require convincing "the naming community" that, for
some reason the IETF is special and should get a "free"[1] TLD, and
that it is exempt from, well, basically all of the existing
requirements.....

I'd started putting some strawman text into the draft[2], so that we
could have something concrete to discuss and poke holes in, but ripped
it out because it was clearly not going to fly / pure fiction...

So, what do we want to do here? This is a WG document, the authors
will (of course) do whatever the WG wants, but my personal view is
that asking for an insecure delegation, while technically superior, is
simply not realistic.

This discussion is somewhat about .alt, but other special use names
will likely have the same issues and concerns, and so we should
consider this in the larger context.

For example, homenet already has had some of this discussion -- see:
https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation

W
[0]: By law, all mentions of ICANN require the use of the word
"mutistakeholder"....Hey, this is no more crazy than some of the other
new rules....

[1]: Yeah, 'tis not a useable TLD in that you cannot sell names and
have them work in the DNS, but this is fairly subtle...

[2]:
------------------
[ Editor note: This section is a strawman (and so is more
conversational than expected for the final version) -- it is likely to
change significantly, or more likely, be removed entirely. ]

The point of adding this entry to the "Special-Use Domain Name"
registry is to create a namespace which can be used for alternate
resolution contexts, and which will not collide with entries in the
IANA DNS root.

Unfortunately, queries will still leak into the DNS, and, as the DNS
root zone is signed, validating resolvers which are unaware of .alt
will attempt to DNSSEC validate responses. If there is not an insecure
delgation for .alt, DNSSEC validation will fail, and validating
resolvers will return SERVFAIL, causing additional lookups or other
unexpected behavior.

In order to avoid this, the IANA is requested to add an insecure
delegation to the root-zone, delegating .alt to AS112 nameservers (or
to an empty zone on hosted by the root).
------------------

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

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 1 Feb 2017 15:44:55 -0500

> AS112 or b: an empty zone on the root or c" something similar.

Hi, Warren:

I'm kind of confused. If a .ALT query leaks into the DNS, and there's
neither a secure or insecure delegation in the root, isn't the result a
signed NXDOMAIN, not a SERVFAIL?

    ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

-- 
Robert Edmonds

---

From: Bob Harold <[email-masked]>
Date: Wed, 1 Feb 2017 15:47:18 -0500

On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/search/?email_list=
> homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation
>
>
> W
> It appears to me that requesting an insecure delegation is the right thing
to do, as a "technical use".  We have, so far, been very careful in what we
ask for.  If ICANN does not agree, then we can discuss other options.

-- 
Bob Harold

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Feb 2017 15:50:32 -0500

> On Feb 1, 2017, at 3:47 PM, Bob Harold <[email-masked]> wrote:
> 
> 
> On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <[email-masked] <mailto:[email-masked]>> wrote:
> Hi there all,
> 
> https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation <https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation>
> 
> 
> W
> It appears to me that requesting an insecure delegation is the right thing to do, as a "technical use".  We have, so far, been very careful in what we ask for.  If ICANN does not agree, then we can discuss other options.

I agree.

- Ralph

> 
> -- 
> Bob Harold
>  
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Feb 2017 07:56:56 +1100

In message <[email-masked]>, Warren K
> be able to do so, but aren't actually allowed to.. :-)).

Actually it isn't the same.

Implicit in the agreement that the IETF can get names in the root
namespace is the ability to use them.  Some uses require that there
be a entry in the root zone.

It doesn't say that the IETF can "RESERVE" a name.  The IETF gets
the name.

> that it is exempt from, well, basically all of the existing

ICANN has already agreed that the IETF is special.  Thats why there
is a agreement that the IETF can request names in the root namespace
outside of the regular process.  There is nothing in the agreement
that make the names the IETF requests gTLD.  They are a different
class.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2017 15:58:41 -0500

>> It appears to me that requesting an insecure delegation is the right thing to do, as a "technical use".  We have, so far, been very careful in what we ask for.  If ICANN does not agree, then we ca…

I'm confused.   The .ALT TLD is expected to be used for non-DNS name lookups.   So isn't a secure denial of existence exactly what we want for .ALT?   What is the utility in having an un-signed delegation?

---

From: Bob Harold <[email-masked]>
Date: Wed, 1 Feb 2017 16:09:24 -0500

On Wed, Feb 1, 2017 at 3:58 PM, Ted Lemon <[email-masked]> wrote:

> I'm confused.   The .ALT TLD is expected to be used for non-DNS name
> lookups.   So isn't a secure denial of existence exactly what we want for
> .ALT?   What is the utility in having an un-signed delegation?
>
> As I understand it, the idea is that if someone incorrectly looks up a
.alt name in DNS, we want an answer that causes the requester and recursive
resolver to not ask again, both to reduce traffic to the roots, and to
minimize leakage of information.  If querying 'something.alt', a delegation
would be cached at the '.alt' level, but an NXDOMAIN would be cached as
'something.alt', and 'other.alt' would not be covered.

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2017 16:32:53 -0500

On Feb 1, 2017, at 4:09 PM, Bob Harold <[email-masked]> wrote:
> As I understand it, the idea is that if someone incorrectly looks up a .alt name in DNS, we want an answer that causes the requester and recursive resolver to not ask again, both to reduce traffic to the roots, and to minimize leakage of information.  If querying 'something.alt', a delegation would be cached at the '.alt' level, but an NXDOMAIN would be cached as 'something.alt', and 'other.alt' would not be covered.

Hm, I thought we just solved that problem with the aggressive negative caching draft.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Feb 2017 08:42:26 +1100

In message <[email-masked]>, Ted Lemon writes:
> >> It appears to me that requesting an insecure delegation is the right
> >> thing to do, as a "technical use".  We have, so far, been very careful in
> >> what we ask for.  If ICANN does not agree, then we can discuss other
> >> options.
> >
> > I agree.
>
> .ALT?

No.

>   What is the utility in having an un-signed delegation?

Alt can be used for whatever purpose that the user wants to use it
for including names served using the DNS protocol.

The only requirement is that leaked queries for "<name>.alt" get
NXDOMAIN and that queries for 'alt.' get a NODATA response other
than for SOA and NS.  Signing those answers would further constrain
how the namespace is used.  Additionally such leaked queries should
be answered as early as possible in the resolution processes to
reduce the privacy exposure.

The simple way to achieve that is to recursive server serve a "empty"
'alt.' zone.  If there is a secure delegation then every recursive
server would need to continually transfer a copy of that zone from
some designated servers as the contents would need to be re-signed
periodically.  If there is a insecure delegation then no transfer
of zone contents is needed as the entire contents can be hard coded
into the server with only the decision about whether to serve the
zone or not being needed to be made.

We do this for 10.IN-ADDR.ARPA today.  The rest of the configuration
of the server decides if 10.IN-ADDR.ARPA is automatially served
with a way to explictly disable the serving.  For 10.IN-ADDR.ARPA
we actually constuct a entire zone automatically as people configure
zones like 0.0.10.IN-ADDR.ARPA and the intermediate names need to
get a NODATA response.

Mark

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Feb 2017 17:11:35 -0500

> On Feb 1, 2017, at 4:42 PM, Mark Andrews <[email-masked]> wrote:
> 
> 

The draft restricts use of .alt as follows:

   This label is intended to be used as
   the final (rightmost) label to signify that the name is not rooted in
   the DNS, and that normal registration and lookup rules do not apply.

...which would lead me to believe .alt would not be used for names served using the DNS protocol.

However, the phrase "not rooted in the DNS" might need some clarification.

In particular, would ".homenet.alt" be OK, as it is a locally-served zone, not a subdomain of the root zone?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Feb 2017 17:12:51 -0500

> On Feb 1, 2017, at 3:58 PM, Ted Lemon <[email-masked]> wrote:
> 

Sorry, I misinterpreted	what I was responding to.  I think I agree with Ted that what we want is a signed delegation for secure denial of existence.

- Ralph

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Feb 2017 17:37:48 -0500

I'm sorry, I apparently did some overly aggressive editing of my mail
before sending it (or I'm completely confused, which is ALWAYS a
possibility).

In order to try and stop leaks, the draft requests that the domain be
added to the "Locally Served Zones" registry. This means that, when a
validating stub A goes off and queries it's recursive server B for
'foo.alt', it will get back an (authoritative) answer from B, saying
that there is nothing under .alt -- e.g:
# dig foo.alt @204.194.23.4

; <<>> DiG 9.11.0-P2 <<>> foo.alt @204.194.23.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36039
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0797210975d60eb10da3940d58926228926455130e02e825 (good)
;; QUESTION SECTION:
;foo.alt.                       IN      A

;; AUTHORITY SECTION:
alt.                    604800  IN      SOA     alt. alt. 1 604800
86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 204.194.23.4#53(204.194.23.4)
;; WHEN: Wed Feb 01 17:33:12 EST 2017
;; MSG SIZE  rcvd: 100

I **think** (perhaps incorrectly!), that when the validating stub (A)
tries to validate this, it will see that there is an NSEC at the root
which says that there is nothing between 'alstom' and 'am'.
This makes it look like someone has tried to make .alt sprint into
existence -- I had thought that the correct error for that is
SERVFAIL, not NXD, but it is entirely possible that I'm wrong....

W

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Feb 2017 18:46:50 -0500

>     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

Yup, but if a resolver has a (empty) local zone for .alt, and someone
queries it and validates, then I think you get SERVFAIL -- the root
says .alt doesn't exist, but here you have an answer apparently from
inside the zone -- 'tis an empty / NXD answer, but still looks like
shenanigans are happening...

W

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Feb 2017 11:02:35 +1100

In message <[email-masked]>, Ted Lemon writes:
> lookups.

The .ALT TLD is a sandbox to play in.  It is a place where people
can graft on alternative namespaces to play with.  The names in it
are not expected to be reachable in the DNS following normal DNS
delegations from the root zone.  This does NOT mean they are non-DNS
names.

I would expect all the names used in it to be syntactially valid
DNS names (able to be converted to DNS wire format) but there is
nothing we can do to enforce that.  If they aren't convertable
tools will fail to parse the names if they leak.

They may be looked up using the DNS (e.g. like homenet).
They may be looked up using other protocols (e.g. something like TOR).

Its a place where people know that there is a risk of namespace
collisions as there is no registry to prevent that.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Feb 2017 21:57:38 +0100

On Wed, Feb 01, 2017 at 03:28:29PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 103 lines which said:

> or 2: request that the IANA insert an insecure delegation in the
> root, pointing to a: AS112 or b: an empty zone on the root or c"
> something similar.

Here, people may be interested by draft-bortzmeyer-dname-root (expired
but could be revived). The main objection was the privacy issue
(sending user queries to the "random" operators of AS112.)

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 3 Feb 2017 15:12:04 -0500

> On Feb 1, 2017, at 3:56 PM, Mark Andrews <[email-masked]> wrote:
> 
> 

Can you please cite a source for this belief, so that it can be added to the “relevant documents” discussion in the problem statement draft?

It seems to me that your interpretation of the situation has never been discussed, and there’s considerable reason to believe it wouldn’t have consensus support across the affected groups (Warren provided an overview of some of the reasons in his original post), but of course I may be overlooking something.

thanks,
Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 3 Feb 2017 15:49:10 -0500

Hi,

To sharpen the question slightly….

> On Feb 1, 2017, at 5:11 PM, Ralph Droms <[email-masked]> wrote:
> 
> 

As a slightly broader question, what does the WG want .ALT to do?

More specifically, perhaps, what problems discussed in draft-ietf-dnsop-sutld-ps-02.txt do we want it to solve?

The WG can agree to change the current text, but I think the WG needs to agree on the purpose of ALT, as that seems likely to make it easier to decide what behavior we want to specify for it and, in turn, how it should be implemented.

Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 3 Feb 2017 16:01:17 -0500

Mark,

> It doesn't say that the IETF can "RESERVE" a name.  The IETF gets

Can you suggest a citation for this belief that can be included in the problem statement draft?

It’s not a view that’s ever been discussed as far as I can recall and it seems to me that it would be difficult to get consensus on it across the affected communities. But I’m always willing to be wrong.

thanks,
Suzanne

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Feb 2017 16:17:48 -0500

> On Feb 3, 2017, at 3:49 PM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi,
> 

Here's a starting point:

The .alt subdomain is to be used for names that are not expected to be resolved with the DNS protocol, and names that are expected to be resolved with the DNS protocol through a context other than the root zone (e.g., locally served zones).
> More specifically, perhaps, what problems discussed in draft-ietf-dnsop-sutld-ps-02.txt do we want it to solve?

Roughly speaking, and open for debate:

Reduces potential conflict between IETF and ICANN assignment of names in the Domain Namespace root.
Obviates the need for (most?) interpretations of "technical use".
Addresses some (but not all) of the reasons an entity might commandeer a domain name.
Mitigates the problem that newly utilized special use names are assumed to use DNS for resolution by most existing software.
Helps separate the regions of the Domain Namespace over which IETF and ICANN have authority.
Allows for ad hoc assignment of special use names.

This list might change depending on:

* whether IETF is still allowed to declare names in the Domain Namespace root for "technical use"
* there is a registry (and associated process) for names in the .alt subdomain

For example, how do we accommodate both "sitenet.alt." as designated by an Internet Standard and "mynewresolver.alt" as used in a local, experimental naming system?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Feb 2017 16:31:24 -0500

> Allows for ad hoc assignment of special use names.

I would really strongly object to adding either of these statements.   You are essentially adding policy to a draft that is not a policy draft, and I think that's a really bad idea.

I'm not sure I buy this one either.   This only works for experimental special-use names.   I would be okay with this:

> Mitigates the problem that experimental special use names are assumed to use DNS for resolution by most existing software.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Feb 2017 20:51:58 -0500

> shenanigans are happening...

If the resolver "has a local zone for alt" -- I think this means it is
authoritative for that zone -- why would it ask the root about it at
all?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Feb 2017 20:54:59 -0500

> authoritative for that zone -- why would it ask the root about it at

This is a rehash of the .homenet discussion we had a few weeks ago.   As long as the stub resolver isn't validating, it's no problem. If it is validating, then the recursive resolver can't fool the stub resolver if there's a secure denial of existence.

---

From: George Michaelson <[email-masked]>
Date: Fri, 3 Feb 2017 20:58:43 -0500

sorry to be thick, but.. can we have both on a case-by-case basis somehow?
it feels like no, because the sign over the zone state implicitly
carries either denial of all false, or denial of none. I can't see how
it can be in a dualistic middle ground.

but if we could do it somehow, cleverly, it would be neat: those that
need to exist with DNSSEC as alternate namespaces can, while more
normal odd names, just exist, and those who want to be denied out of
all existence, are repudiated.

-g

On Fri, Feb 3, 2017 at 8:54 PM, Ted Lemon <[email-masked]> wrote:
> This is a rehash of the .homenet discussion we had a few weeks ago.   As
> long as the stub resolver isn't validating, it's no problem. If it is
> validating, then the recursive resolver can't fool the stub resolver if
> there's a secure denial of existence.
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Feb 2017 21:13:53 -0500

On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote:
> As long as the stub resolver isn't validating, it's no problem. If it is validating, then the recursive resolver can't fool the stub resolver if there's a secure denial of existence.
> 

Right, that's always been the problem with using this _for the DNS_.
Homenet has no choice in that, because the whole point of the homenet
name is precisely to enable in-homenet DNS without reference to the
global DNS.  I think you're quite correct that we need to decide
whether alt is to be used for those purposes.  I'm not convinced
that's so useful.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Feb 2017 21:16:19 -0500

> sorry to be thick, but.. can we have both on a case-by-case basis somehow?

Well, if the stub that is going to query in this namespace _knows_
that it's special, then it also knows not to validate it too.  So
that's not a problematic case, and the provable denial of existence
from the root isn't an issue.

So the only question is whether this has to work properly for any
random resolver doing normal operations -- is this like RFC 1918 for
the DNS?  If we want that (and for homenet, for instance, that's
basically the use case) then we have a problem.  But if we don't think
that's necessary -- and I'm not sure it is -- then we don't have to
care about this.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Sat, 4 Feb 2017 09:46:15 +0000

> whether alt is to be used for those purposes.  I'm not convinced

If it turns out that we can't get the insecure delegation that we need
for .homenet, then I'd (personally) be reasonably happy with
.homenet.alt, except that the current proposals for the use of .alt
wouldn't seem to permit that.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 Feb 2017 00:29:43 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> > As long as the stub resolver isn't validating, it's no problem. If it is validating, t
> hen the recursive resolver can't fool the stub resolver if there's a secure denial of ex
> istence.
> > 
> 

It's a problem for ALL special names.  BOGUS / SERVFAIL isn't the
response leaked names should get.  Its bad engineering.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 4 Feb 2017 09:13:00 -0500

> wouldn't seem to permit that.

.alt doesn't allow for reserved allocations, so I don't think this would fly.   Also, there won't be a .alt zone (correct me if I am wrong), so it doesn't actually solve the problem.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 4 Feb 2017 09:14:21 -0500

> response leaked names should get.  Its bad engineering.

What is the response leaked names should get, and why is that the correct response?   Why is SERVFAIL not the correct response?

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 Feb 2017 01:43:51 +1100

In message <[email-masked]>, Ted Lemon writes:
> What is the response leaked names should get, and why is that the correct
> response?   Why is SERVFAIL not the correct response?

SERVFAIL indicates something went wrong.  Clients try alternative
servers on SERVFAIL.  It isn't a property of the name.  It the
property of a server when looking up the name.

Mark

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 4 Feb 2017 16:55:34 -0500

> wouldn't seem to permit that.

The other question to keep in mind, perhaps particularly for HOMENET, is how long are you/we willing to wait?

The IETF has no process for requesting a change to the root zone (it’s not one of the protocol parameter registries under the change control of the IETF) and ICANN has no process for evaluating such a request..

Generallly when iCANN is asked to do something for which they have no process, their answer is Yes; No; or “We have to think about that,” and it often takes years, particularly in the last case.

(no hats, just lots of experience.)

Suzanne

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 5 Feb 2017 21:51:11 -0500

> wouldn't seem to permit that.

What is wrong with homenet.arpa ? 
you can have that next month and no-one will complain 

Olafur

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Feb 2017 21:54:41 -0500

> What is wrong with homenet.arpa ? 

homenet.arpa sounds like a service out there on the arpanet somewhere, not something local.

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2017 04:05:16 -0000

>homenet.arpa sounds like a service out there on the arpanet somewhere, not something local.

Why would that be important?  It's mostly managed automatically.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Feb 2017 23:09:23 -0500

I'm pretty sure I've explained it enough times on this mailing list and in
the relevant documents by now. If you don't agree, maybe we should just
accept that. If you don't remember the explanation, it's in the homenet
naming architecture doc I wrote.

---

From: "John R Levine" <[email-masked]>
Date: 5 Feb 2017 23:18:18 -0500

> naming architecture doc I wrote.

Well, OK, I took another look, and from what I can see, it's a belief that 
people will find toaster.homenet.arpa harder or more confusing to type 
than toaster.homenet.

Just out of curiosity, how long is it worth waiting to get .homenet rather 
than .homenet.arpa?  If it took five more years, which at the current rate 
seems optimistic, would homenet still be relevant?

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Feb 2017 23:22:35 -0500

The working group has consensus to give it a try.  We may change our minds
of it takes too long, but it seems worth exploring from a process
perspective anyway.

On Feb 5, 2017 11:18 PM, "John R Levine" <[email-masked]> wrote:

> people will find toaster.homenet.arpa harder or more confusing to type than
> toaster.homenet.
>

---

From: Ólafur Gudmundsson <[email-masked]>
Date: Mon, 06 Feb 2017 09:29:58 -0600

Ted,

What RFC are you referring to?

Why do you think .ARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure.

It is waste of time arguing if name A or B is better take the one you can get faster.

Ólafur

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Feb 2017 15:36:11 +0000

> On 6 Feb 2017, at 15:29, Ólafur Gudmundsson <[email-masked]> wrote:
> 

+100

Says he wishing the arguments over A or B (for some definition of both) would just go away and never return.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Feb 2017 10:52:53 -0500

> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson <[email-masked]> wrote:
> 
> Ted,
> 

The WG has considered the alternatives, and WG consensus is to specify ".homenet"

- Ralph

>> The working group has consensus to give it a try.  We may change our minds of it takes too long, but it seems worth exploring from a process perspective anyway. 
>> 
>>> Well, OK, I took another look, and from what I can see, it's a belief that people will find toaster.homenet.arpa harder or more confusing to type than toaster.homenet.
>>> 
>>> Just out of curiosity, how long is it worth waiting to get .homenet rather than .homenet.arpa?  If it took five more years, which at the current rate seems optimistic, would homenet still be relevant?
>>> 
>>> R's,
>>> John
> 
> --

---

From: Ray Bellis <[email-masked]>
Date: Mon, 6 Feb 2017 15:56:01 +0000

> It is waste of time arguing if name A or B is better take the one you

It really isn't.

If I type "arpa" into Google (without the leading dot) I don't get the
new "Address and Routing Parameter Area" definition.

I get a big side bar with the DARPA logo and mention of the US DoD
everywhere.

That might well be fine for us "in the know" techies, but as far as I'm
concerned it's not fine for the residential users that are the target
market for Homenet.

That's even more true now than it was before November.

Ray (no hat)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Feb 2017 10:56:59 -0500

> What RFC are you referring to?

I wasn't referring to an RFC—I was referring to the homenet naming architecture document that we've been working on.

> It's for infrastructure and homenet wants to join the infrastructure.

What made you think I though that.   What I mean is that it sounds like it's something global, not something local, because of the .arpa subdomain.

> It is waste of time arguing if name A or B is better take the one you can get faster.

This is your opinion.   I don't recall hearing you express it when I asked the working group which option they preferred.   We have a substantial amount of time to waste; the working group decided to waste it.   I don't see a problem with that.   If we need to revisit this later, when it becomes a pressing issue, I think we have a pretty clear expedient solution, as you say, so there is no harm in trying for the solution that we want, and that we thing produces the better result for end users.

---

From: Ólafur Gudmundsson <[email-masked]>
Date: Mon, 06 Feb 2017 09:57:15 -0600

Ralph, 
A WG can come to a consensus on a topic without all information available.
Now go back and see if reality changes consensus.

Just my .02 cents.

Ólafur

On February 6, 2017 9:52:53 AM CST, Ralph Droms <[email-masked]> wrote:
>>> The working group has consensus to give it a try.  We may change our
>minds of it takes too long, but it seems worth exploring from a process
>perspective anyway. 
>>> 
>>>> Well, OK, I took another look, and from what I can see, it's a
>belief that people will find toaster.homenet.arpa harder or more
>confusing to type than toaster.homenet.
>>>> 
>>>> Just out of curiosity, how long is it worth waiting to get .homenet
>rather than .homenet.arpa?  If it took five more years, which at the
>current rate seems optimistic, would homenet still be relevant?
>>>> 
>>>> R's,
>>>> John
>> 
>> --

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Feb 2017 10:59:09 -0500

> Now go back and see if reality changes consensus.

I presented a detailed explanation of the tradeoffs, which the working group considered.   If you think something has changed, you should first review the discussion, since it sounds like you never read that detailed explanation.  In that explanation, I made the precise point you are making: that homenet.arpa would be more expedient than .homenet.

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 6 Feb 2017 11:12:01 -0500

Hi,

Before this goes any further, I’m not sure an incomplete rehashing of the consensus in another WG is a good use of our time.

For now, let’s keep it relevant to the decision this WG has to make, about what to do with .alt and whether it’s important to us to accommodate cases like .homenet. So far, it seems that the .homenet case is much like “locally-served zones”.

thanks,
Suzanne

> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Ted,
>> 
>> On February 5, 2017 10:22:35 PM CST, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 5, 2017 11:18 PM, "John R Levine" <[email-masked] <mailto:[email-masked]>> wrote:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> --

---

From: Ray Bellis <[email-masked]>
Date: Mon, 6 Feb 2017 16:15:18 +0000

On 06/02/2017 16:12, Suzanne Woolf wrote:
> Hi,
> 
> Before this goes any further, I’m not sure an incomplete rehashing of
> the consensus in another WG is a good use of our time.

+1 :)

> For now, let’s keep it relevant to the decision this WG has to make,
> about what to do with .alt and whether it’s important to us to
> accommodate cases like .homenet. So far, it seems that the .homenet case
> is much like “locally-served zones”.

Yes, that's right, with the caveat that all existing locally served
zones are in the reverse space - there's no forward zones registered (yet).

Ray

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 6 Feb 2017 11:18:38 -0500

> On Feb 6, 2017, at 11:15 AM, Ray Bellis <[email-masked]> wrote:
> 

Could you clarify why that’s relevant?

Does it just come down to the assumption that reverse zones are not supposed to have human-visible/human-friendly names? Or is there some other characteristic of how those names are used that’s important here?

thanks,
Suzanne

---

From: Ray Bellis <[email-masked]>
Date: Mon, 6 Feb 2017 16:24:58 +0000

On 06/02/2017 16:18, Suzanne Woolf wrote:

>> Yes, that's right, with the caveat that all existing locally
>> served zones are in the reverse space - there's no forward zones
>> registered (yet).
> 
> Does it just come down to the assumption that reverse zones are not
> supposed to have human-visible/human-friendly names? Or is there some
> other characteristic of how those names are used that’s important
> here?

In the back of my mind I was recalling some conversations I've heard
that perhaps some other "reserved" forward names should be treated like
locally served zones (e.g. ".invalid") but currently aren't.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 6 Feb 2017 16:55:19 +0000

> zones are in the reverse space - there's no forward zones registered (yet).

There are several :-) RFC 6761 specifies localhost, invalid, test as
locally served zones. RFC 6762 specifies local. RFC 7686 specifies onion.

RFC 7534 says that the AS112 DNAME target zones should be locally served,
though they are not listed in the special use registry.

The example domains are special use but not locally served.

BIND currently has empty.as112.arpa as its only built-in locally-served
forward domain.

My servers have some awkwardness to sink .local mDNS queries without
making Avahi think there is a private non-multicast DNS .local domain.
This does not conform to the requirements of RFC 6762 but it is necessary
for interop :-/
	zone local {
		type master; file "/zm/null";
		allow-query { !0.0.0.0/0; !::/0; };
	};

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire, Forties, Cromarty: Southeasterly 7 to
severe gale 9, perhaps storm 10 later in Viking. Rough or very rough becoming
very rough or high. Rain or sleet. Moderate or good, occasionally poor.

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2017 17:19:27 -0000

>Could you clarify why that’s relevant?

Perhaps because the management rules follow more or less mechanically
from the management rules for the corresponding IP space.

R's,
John

PS: I don't think that's hugely compelling.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 6 Feb 2017 18:12:31 +0000

> The example domains are special use but not locally served.

The "locally served zones" and "special use domains" registries are
different.  There is potentially scope for overlap.

It's possible that some special use domains might benefit from special
treatment in the root zone, too (".localhost" ?)

Ray

---

From: "Woodworth, John R" <[email-masked]>
Date: Tue, 7 Feb 2017 03:44:29 +0000

> > RFC 7534 says that the AS112 DNAME target zones should be locally
> > served, though they are not listed in the special use registry.
> >
> The "locally served zones" and "special use domains" registries are different.
> There is potentially scope for overlap.
>

I know I am late to the game but as I understand the issue (still catching up)
the .alt is intended for both non-DNS and special-use DNS (expected to be
resolved locally).

Just spitballing but what about a new RR type to actively flag the owner as
officially not-existing (e.g. NXD).  These RRs could be used in *any* zone
including root and combined with the special use registry (for policy)
could flag the namespace as both reserved and non-existent.

I tend to agree with Mark on this, SERVFAIL feels wrong.

/John

> Ray

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 09:43:14 +0100

On Mon, Feb 06, 2017 at 06:12:31PM +0000,
 Ray Bellis <[email-masked]> wrote 
 a message of 28 lines which said:

> different.

Why are they different, by the way? I really do not understand
that. The "locally served zones" registry should be a strict subset of
the "special use domains" registry, for the case where RFC 6761 says
"4. Caching DNS Servers: Are developers of caching domain name servers
expected to make their implementations recognize these names as
special and treat them differently?  If so, how?" and the answer is
"serve locally".

[Speaking of this, the lack of a formal language in the "special use
domains" registry, allowing a resolver to be compiled with automatic
inclusion of all the special cases, is the only really serious problem
in RFC 6761. I regret that draft-ietf-dnsop-sutld-ps-02 does not even
mention it.]

> It's possible that some special use domains might benefit from
> special treatment in the root zone, too (".localhost" ?)

Let me advertise again my draft :-) draft-bortzmeyer-dname-root

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 09:46:32 +0100

On Mon, Feb 06, 2017 at 04:55:19PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 36 lines which said:

> locally served zones.

De facto, yes. But it does not use this language, and these names are
not in
<https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 09:53:07 -0500

On Feb 8, 2017, at 3:43 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> Why are they different, by the way?

There is more than one way to handle a special-use name.   That's why we're debating which way to handle .alt, after all!   :)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 17:23:46 +0100

On Wed, Feb 08, 2017 at 09:53:07AM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 37 lines which said:

> There is more than one way to handle a special-use name.

Yes, but "serve it locally" is just one way, and it has its own
registry, which is not the case with the other ways. And it is
inconsistent: the semantics of ".localhost" in RFC 6761 are "serve it
locally" but it is not in the registry of locally-served zones.

I'm glad I don't maintain a DNS resolver, it seems messy to just get a
comprehensive list of domains that a resolver has to know by default,
with the rules to follow.