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

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Feb 2017 12:02:47 -0800

Stephane wrote:

> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>  Warren Kumari <warren at kumari.net> 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.)
>
>
My opinion on these issues are as follows, roughly:

   - I am in favor of AS112 for ALT
   - For AS112, I prefer the AS112++ method (DNAME)
   - I do not see why the DNAME would/should not be DNSSEC signed
   - Any local use of ALT can be served locally and signed using an
   alternative trust anchor
   - I don't think there is any issue with having both the NXD from the
      root, and the local assertion of existence, both present (in cache and in
      authoritative data respectively)
      - Maybe there are issues with specific implementations?
      - If anyone knows of such problems, it would be helpful to identify
      them along with the implementation and version
   - For AS112 privacy, perhaps someone should write up a recommendation to
   set up local AS112 instances, to provide privacy, as an informational RFC?
      - Even simply through resolver configurations, without a full AS112
      "announce routes"?
      - Do any resolver packages offer such a simple AS112 set-up?
      - Maybe the efforts for privacy should start there (implement first,
      then document)?
      - Do any stub resolver packages include host-local AS112
      features/configurations?

Overall, I'm obviously in favor of use of ALT, and for signing whatever is
done for ALT, and for use of DNAME for ALT.

Brian "DNAME" Dickson

---

From: Steve Crocker <[email-masked]>
Date: Fri, 3 Feb 2017 12:06:05 -0800

Are you also expecting ALT will never be delegated in the root?  If it were to be delegated in the root, what impact would that have on the uses you have in mind?

Steve Crocker
[I am having trouble sending from [email-masked], but I am receiving mail without trouble.  Please continue to send mail to me at [email-masked]]

> On Feb 3, 2017, at 12:02 PM, Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Stephane wrote: 
>  Warren Kumari <warren at kumari.net <http://kumari.net/>> wrote 
> I am in favor of AS112 for ALT
> For AS112, I prefer the AS112++ method (DNAME)
> I do not see why the DNAME would/should not be DNSSEC signed
> Any local use of ALT can be served locally and signed using an alternative trust anchor
> I don't think there is any issue with having both the NXD from the root, and the local assertion of existence, both present (in cache and in authoritative data respectively)
> Maybe there are issues with specific implementations? 
> If anyone knows of such problems, it would be helpful to identify them along with the implementation and version
> For AS112 privacy, perhaps someone should write up a recommendation to set up local AS112 instances, to provide privacy, as an informational RFC?
> Even simply through resolver configurations, without a full AS112 "announce routes"?
> Do any resolver packages offer such a simple AS112 set-up?
> Maybe the efforts for privacy should start there (implement first, then document)?
> Do any stub resolver packages include host-local AS112 features/configurations?
> Overall, I'm obviously in favor of use of ALT, and for signing whatever is done for ALT, and for use of DNAME for ALT.
> 
> Brian "DNAME" Dickson
> _______________________________________________
> DNSOP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Feb 2017 12:18:30 -0800

The DNAME has an effect similar to delegation, except that in the case of
the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a
well-known & published empty zone (as112.arpa.)

(Delegation and DNAME cannot coexist for the same owner name - that is one
of the edicts for DNAME, similar to CNAME.)

Any local configuration of something.alt (as an authoritatively served
zone) would be matched before checking the cache or attempting recursive
resolution, per 103[345].

I don't have any desire or intention of local something.alt, I'm just
pointing out that the existence of a signed NXD result (via DNAME to an
empty zone) doesn't break such a set-up.

The reason for DNAME instead of delegation, is that it avoids the operators
of AS112 instances from having to configure the new zone(s) whenever a new
"delegation" occurs.

If, instead, a delegation were done, the specific zone (.alt) would need to
be configured and served somewhere.

RFC7535 is designed to avoid the need for coordination in configuring such
zones.

(RFC7535 also allows authorities for other places in the DNS tree to make
use of AS112, but that is a non-sequitur.)

Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <[email-masked]>
wrote:

> Are you also expecting ALT will never be delegated in the root?  If it
> were to be delegated in the root, what impact would that have on the uses
> you have in mind?
>
> Steve Crocker
> [I am having trouble sending from [email-masked], but I am receiving
> mail without trouble.  Please continue to send mail to me at
> [email-masked]]
>
>
> On Feb 3, 2017, at 12:02 PM, Brian Dickson <[email-masked]>
> wrote:
>
> Stephane wrote:
>
>    - For AS112 privacy, perhaps someone should write up a recommendation
>    to set up local AS112 instances, to provide privacy, as an informational
>    RFC?
>       - Maybe the efforts for privacy should start there (implement
>       first, then document)?
> [email-masked]

---

From: Bob Harold <[email-masked]>
Date: Fri, 3 Feb 2017 15:19:27 -0500

On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson <[email-masked]

> done for ALT, and for use of DNAME for ALT.
I would prefer an UNsigned delegation.  If someone wants a signed zone,
they can add a trust anchor, I assume.  But if they want an unsigned zone
there needs to be a way to get that.

-- 
Bob Harold

---

From: Steve Crocker <[email-masked]>
Date: Fri, 3 Feb 2017 12:21:16 -0800

And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain?  Is it ok if we say yes and delegate the name?  If not, what is the basis for us to say no?

Steve Crocker

> On Feb 3, 2017, at 12:18 PM, Brian Dickson <[email-masked]> wrote:
> 
> The DNAME has an effect similar to delegation, except that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 <https://tools.ietf.org/html/rfc7535> ) , the target is a well-known & published empty zone (as112.arpa.)
> 
> (Delegation and DNAME cannot coexist for the same owner name - that is one of the edicts for DNAME, similar to CNAME.)
> 
> Any local configuration of something.alt (as an authoritatively served zone) would be matched before checking the cache or attempting recursive resolution, per 103[345].
> 
> I don't have any desire or intention of local something.alt, I'm just pointing out that the existence of a signed NXD result (via DNAME to an empty zone) doesn't break such a set-up.
> 
> 
> 
> The reason for DNAME instead of delegation, is that it avoids the operators of AS112 instances from having to configure the new zone(s) whenever a new "delegation" occurs.
> 
> If, instead, a delegation were done, the specific zone (.alt) would need to be configured and served somewhere.
> 
> RFC7535 is designed to avoid the need for coordination in configuring such zones.
> 
> (RFC7535 also allows authorities for other places in the DNS tree to make use of AS112, but that is a non-sequitur.)
> 
> Brian
> 
> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <[email-masked] <mailto:[email-masked]>> wrote:
> [I am having trouble sending from [email-masked] <mailto:[email-masked]>, but I am receiving mail without trouble.  Please continue to send mail to me at [email-masked] <mailto:[email-masked]>]
> 
> 
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> 
> 
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Feb 2017 12:28:55 -0800

On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <[email-masked]>
wrote:

> And just to stir the pot a bit, what would you have ICANN do if someone
> applies for .alt as a top level domain?  Is it ok if we say yes and
> delegate the name?  If not, what is the basis for us to say no?
>

The insertion of the DNAME record in the root, instantiates the ALT domain.
It says the ALT domain exists.

However, the DNAME target of an empty zone, assures (with DNSSEC
signatures) that no names below ALT exist.

So, a query to a root server for "alt." would get the DNAME (if the query
was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE.

And a query to a root server for "anything.alt" would get the DNAME to
AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa)
would get NXD.

As to the question about applying for "alt": it means no one can apply for
.alt as a TLD, because it is taken. That is the basis for saying "no".

Brian

> The reason for DNAME instead of delegation, is that it avoids the
> operators of AS112 instances from having to configure the new zone(s)
> whenever a new "delegation" occurs.
>
>>       - If anyone knows of such problems, it would be helpful to
>>       identify them along with the implementation and version
>>       - Even simply through resolver configurations, without a full
>>       AS112 "announce routes"?
>> Overall, I'm obviously in favor of use of ALT, and for signing whatever
>> is done for ALT, and for use of DNAME for ALT.
>>
>> Brian "DNAME" Dickson

---

From: Steve Crocker <[email-masked]>
Date: Fri, 3 Feb 2017 12:33:01 -0800

We (ICANN) have no mechanism or process for inserting a DNAME record into the root.  We do have a process for considering the general issue, but, so far as I know, no one has yet brought that idea into the ICANN/PTI arena.

Steve Crocker

> On Feb 3, 2017, at 12:28 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <[email-masked] <mailto:[email-masked]>> wrote:
> The insertion of the DNAME record in the root, instantiates the ALT domain. It says the ALT domain exists.
> 
> However, the DNAME target of an empty zone, assures (with DNSSEC signatures) that no names below ALT exist.
> 
> So, a query to a root server for "alt." would get the DNAME (if the query was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE.
> 
> And a query to a root server for "anything.alt" would get the DNAME to AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) would get NXD.
> 
> As to the question about applying for "alt": it means no one can apply for .alt as a TLD, because it is taken. That is the basis for saying "no".
> 
> Brian
>  
> 
> 
> Steve Crocker
>> On Feb 3, 2017, at 12:18 PM, Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2017 20:44:29 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>We (ICANN) have no mechanism or process for inserting a DNAME record into the root.  We do have a
>process for considering the general issue, but, so far as I know, no one has yet brought that idea
>into the ICANN/PTI arena.

There are ccTLDs that contain nothing but a DNAME (along with the
mandatory SOA and NS).  Maybe that's close enough.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Feb 2017 12:55:34 -0800

On Fri, Feb 3, 2017 at 12:19 PM, Bob Harold <[email-masked]> wrote:

>
> On Fri, Feb 3, 2017 at 3:02 PM, Brian Dickson <
> [email-masked]> wrote:
>
>> Stephane wrote:
>>

I think you would be able to do the following, via local configuration, to
create an unsigned zone under ALT:

Locally configure ALT.
Have delegations to WHATEVER.ALT with NS, but without DS.
Sign the resulting ALT zone.

WHATEVER.ALT is now an unsigned zone, whose existence is signed by the
local trust anchor for ALT.

(The ALT trust anchor would exist alongside the real root trust anchor; the
local stuff overrides the root stuff, for ALT.)

Brian

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Feb 2017 08:09:22 +1100

In message <[email-masked]>
> done for ALT, and for use of DNAME for ALT.

You need a insecure delegation for ALT for the purposes we want to
use ALT for.

Go setup a test rig where you have a signed root with ALT as you
described.  A validiting recursive server which also serves foo.alt.
A second validating recursive server which forwards all queries to
the first recursive server.  All servers are configured with a trust
anchor for the test root zone and are validating responses.  Try
to perform a lookup on foo.alt.

The second recursive server is the validating client that needs to
be able to get a answer other than BOGUS.  As we want to allow
foo.alt to be unsigned there can't be any other trust anchors,
including negative, configured.

Only solutions which allow content from the foo.alt zone to be
successfully resolved are acceptable.

The following will not work with the above rig:
* No delegation for ALT.
* A secure delegation for ALT.
* A DNAME for ALT in the root zone.

Mark
-- 
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: Fri, 3 Feb 2017 16:34:21 -0500

> You need a insecure delegation for ALT for the purposes we want to

I don't think there's consensus on what we want to use ALT for.   I see Ralph arguing that ALT is never used to resolve things using the DNS protocol, and I see you saying that that's one of the uses we have in mind.   We need to figure out which of these we are actually trying to do.

If you are right, we need an insecure delegation in the root, and ALT queries will by default be answered using DNS (in the sense that existing resolvers have no special-case handling for ALT).   If Ralph is right, you can still use the DNS protocol to resolve names in .ALT, but you have to use a specially modified resolver to do it: one that ignores the secure denial of existence from the root.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Feb 2017 09:19:28 +1100

In message <[email-masked]>, Ted Lemon writes:
> I don't think there's consensus on what we want to use ALT for.   I see
> Ralph arguing that ALT is never used to resolve things using the DNS
> protocol, and I see you saying that that's one of the uses we have in
> mind.   We need to figure out which of these we are actually trying to do.

I think there is a consensus for a play space.  I think there is
consenus on there not being any delegations under this play space
with iterating down from the root.  I think there is consenus that
leaked queries of the form foo.alt should be getting NXDOMAIN
responses from a recursive server which would otherwise be iterating
down from the root for this namespace.

> If you are right, we need an insecure delegation in the root, and ALT
> queries will by default be answered using DNS (in the sense that existing
> resolvers have no special-case handling for ALT).   If Ralph is right,
> you can still use the DNS protocol to resolve names in .ALT, but you have
> to use a specially modified resolver to do it: one that ignores the
> secure denial of existence from the root.

So you want to ban BYOD from the solution space?  Remember adding
a alt zone to a recursive server is modifying the resolver.  It is
changing its observed behaviour.  It isn't code but it is a
modification.

Why does this working group feel the need to add extra proscriptions
on how this play space is to be used?

I've been arguing for the broadest solution space.  Its also the
simplest.  A insecure delegation for ALT.  It is also the easist
one for recursive servers which are iterating from the root that
are not participating in the experiment to filter leaked queries
with.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Feb 2017 09:47:08 +1100

Also the ICANN's rule for signed TLD delegation for new gTLD is so
that delegations from those zones can be signed.  It is not so that
NXDOMAINS are secure or else NSEC3 with OPTOUT would be banned.
There are lots of insecure answers from the new TLDs including
delegations.  Only those using NSEC or NSEC3 without OPTOUT are
secure.

Alt doesn't have any delegations.  There is no reason for it to be
signed.  There is no reason for ICANN to object other than religious
arguments.  Technically they don't have a leg to stand on.

---

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

Mark, I don't think you've actually given an answer to my question.   I understood that .ALT was for alternative naming systems, not for DNS locally-served zones.   We simply need to decide whether or not that's true.   I think either answer is fine; we just need to pick one.   If the answer is that it should support locally-served zones with no stub resolver (just to be clear, I am not talking about recursive resolvers), then as you say, there needs to be an un-signed delegation.   If on the other hand it's really for alternative _naming systems_ then we want a secure denial of existence.

The last paragraph of the introduction seems to be saying that it's the latter.

---

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

> And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain?  Is it ok if we say yes and delegate the name?  If not, what is the basis for us to s…

If alt ends up in the 6761 special-use names registry, that seems a
reason for ICANN not to delegate the name.  For adding something to
the 6761 special-use names registry removes it from the possible pool
of names that can be in the root zone.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

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

Hi,

On Sat, Feb 04, 2017 at 09:47:08AM +1100, Mark Andrews wrote:
> that delegations from those zones can be signed.

I don't think that it is up to this WG or even the IETF to make any
determinations about why the names community decides the policies it
does for the root zone.  But in any case, there are two relevant
policy issues here:

    1.  We are not the authority for delegations -- signed, unsigned,
    emtpy or otherwise -- from the root zone, and if we are going to
    seek any kind of entry in the actual DNS root zone then we are
    talking about that in entirely the wrong forum.  We maybe should
    complete the alt draft saying what we want from it, and then
    insert that into the correctly-shaped receptical at ICANN. 

    2.  Unfortunately for us, right now, there _is_ no such receptical
    at ICANN.  For there does not appear to be an ICANN policy for
    delegations from the root for special uses.  There is a policy for
    ccTLD additions, but we are not a country.  There is no current
    policy for new gTLDs -- the previous round closed, and there has
    been no determination of whether a new round will happen nor what
    that round might entail if it happens.  If you want to shape those
    rules, I believe there are some discussions going on within some
    constituencies at ICANN.

> arguments.  Technically they don't have a leg to stand on.
 
I'm sorry, but it's not religious.  Other communities have rules for
establishing their IANA functions.  If we want them to respect our
rules for the IANA registries for which we set the policy, then we
need to respect theirs for the registries for which they set the
policy.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
> Mark, I don't think you've actually given an answer to my question.
> I understood that .ALT was for alternative naming systems, not for
> DNS locally-served zones.   We simply need to decide whether or not
> that's true.   I think either answer is fine; we just need to pick
> one.

I agree with this.  I will say that, when I first started working on
this with Warren, it was really for the use-case where people would
tread on the namespace as a protocol switch -- we wanted a sandbox in
which things like onion could live.  My memory is that only after that
did we start thinking of a sort of 1918-style part of the DNS as
well.  That may have been a mistake, since as this discussion is
showing the properties of an in-protocol, in-DNS namespace without
delegations are somewhat different to alternative-protocol uses that
do not rely on the DNS at all.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Feb 2017 21:40:32 -0500

On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <[email-masked]> wrote:
> My memory is that only after that

I think that we've seen a number of questions go by that lead to the conclusion that it makes sense to have two hierarchies: one for experimental non-DNS queries, and one for locally served zones.   I don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a special-use top-level domain name that has an un-signed delegation, it probably ought to be different than the SUTLDN that is used for non-DNS stuff, so that both names can have the appropriate configuration in the root zone.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Feb 2017 09:05:00 +0100

> of names that can be in the root zone.

This would be my suggestion.

What worries me is not names in 6761 special-use names registry but other names ICANN "should not" add to the root zone.

   paf

---

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

> need to respect theirs for the registries for which they set the

Given there are no rules for this type of namespace we need to
respect the reasons for the other rules which I did but you choose
to completely cut out of the reply.  This isn't a registry.  It's
a non-registry.  It is different.

Mark

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 4 Feb 2017 08:45:23 -0500

> On Feb 3, 2017, at 9:40 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <[email-masked] <mailto:[email-masked]>> wrote:

We may be making this harder than it has to be.

It’s worth noting at this point that the "1918-style part of the DNS” (DNSSEC compatibility for names intended to be locally resolved with the DNS protocol) is a solved problem, if you mean it literally: they’re under .arpa.

This was an obvious solution for address blocks, since in-addr.arpa was already established by the protocol for PTR records and .arpa was already administered under IETF rules.

However, in terms of the desired behavior all the parts are there: .arpa is a signed zone, can have signed or unsigned delegations for names intended to be resolvable in the DNS (locally or globally), and is administered under IETF rules that include *not* delegating special use names under it that shouldn’t be in the DNS (I don’t see the IAB having a problem with making a commitment that a specific string won’t be delegated).

The objections to .home.arpa were to the specific string “.arpa” and that it wasn’t a single-label name, which seemed to be strong preferences but I’m not sure were ever documented as hard (“it won’t work otherwise”) requirements. For other special use names, they might very well not be constraints.

Having already decided that “single label” is a tough constraint to maintain if you want an unsigned delegation from a signed zone (i.e. an unsigned TLD in the root), I’m not sure I see a major difference between mystring.alt and mystring.arpa.

Suzanne

---

From: william manning <[email-masked]>
Date: Sun, 05 Feb 2017 13:22:04 +0000

DNAME was considered early in the IDN evaluations, so it's not exactly
unknown in the Icann community

On Fri, Feb 3, 2017 at 15:33 Steve Crocker <[email-masked]> wrote:

> We (ICANN) have no mechanism or process for inserting a DNAME record into
> the root.  We do have a process for considering the general issue, but, so
> far as I know, no one has yet brought that idea into the ICANN/PTI arena.
>
>
>
> Steve Crocker

---

From: Warren Kumari <[email-masked]>
Date: Sun, 5 Feb 2017 10:16:20 -0500

On Fri, Feb 3, 2017 at 9:40 PM, Ted Lemon <[email-masked]> wrote:
> I think that we've seen a number of questions go by that lead to the
> conclusion that it makes sense to have two hierarchies: one for experimental
> non-DNS queries, and one for locally served zones.

Yes.

>  I don't know if we
> _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a
> special-use top-level domain name that has an un-signed delegation, it
> probably ought to be different than the SUTLDN that is used for non-DNS
> stuff, so that both names can have the appropriate configuration in the root
> zone.

.alt was intended only for names *outside* the DNS - an alternate name
resolution system (like .onion). It was never intended for use in an
alternate/internal DNS namespace. If needed, we can clarify this in
the draft.

I fully understand the desire for names which are resolved using the
DNS, but are not rooted in / connected to the DNS root -- I think that
something like this would be really useful (I've got a bunch of
use-cases), but it seems like a completely different kettle of fish.

I'd encourage someone to write a document like this -- I started
writing a such document[0] in July 2015 to reserve a name (.internal)
specifically for this, but only got as far as the title and abstract
before getting sidetracked. :-P

So, in my opinion there should not be any sort of delegation for .alt.
A new (short) draft reserving .internal (or whatever) specifically for
DNS names not rooted in / connected to the IANA tree could be written,
and that can ask for a delegation.

W

[0]
    <title abbrev="template">Reservation of .internal as a Special Use
    Name.</title
...
<abstract>
      <t>This document reserves the string "internal" for use as an internal
      DNS </t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to freqently asked questions, general musings, etc.
      They will be removed before publication.]</t>

      <t>[ This document is being collaborated on in Github at:
      https://github.com/__URL__. The most recent version of the document,
      open issues, etc should all be available here. The authors (gratefully)
      acept pull requests ]</t>
    </abstract>
  </front>

-- 
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: Mukund Sivaraman <[email-masked]>
Date: Sun, 5 Feb 2017 22:00:20 +0530

>       acept pull requests ]</t>

If you'd uploaded this, it could've been the shortest first draft!

		Mukund

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 5 Feb 2017 11:31:33 -0500

On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote:
> 
> Given there are no rules for this type of namespace

Which "type of namespace" do you mean?

I think there are three possible namespaces you're talking about:

    1.  Domain names.  There are rules for these, though they're
    possibly underspecified.  The IETF now has change control over the
    namespace definition documents (though the creation of said
    namespace predates the IETF).  For this reason, the IETF was in a
    position to create the 6761 registry and thereby establish that
    there are some domain names that are treated specially.

    2.  Domain names that are candidates for some DNS
    zone.  There is a policy authority for these, and it's the
    operator of the zone in question.  Its rules for that zone apply.
    In the case of the DNS root zone, the policy authority for that
    zone is the names community as expressed through ICANN.
    (Similarly, I am the policy authority for the crankycanuck.ca
    zone, and if you want a delegation in there you can talk to me.)

    3.  Domain names that are _not_ for use in the DNS.  This is one
    of the purposes of 6761, though perhaps not the only one.  So far,
    the rules for these have been mostly underspecified, though I
    think 6761 gives pretty compelling reasons why it's a good idea at
    least to register the use there.

The trouble we seem to be having is that we want something that is in
(2) but with no single policy authority for the zone.  It is not clear
that we have a way to do that if we start from the root.  We _might_
have a way to do it if we start from arpa, since the IAB is in charge
of arpa and doesn't have the policy problems that ICANN does.

The alt draft that Warren and I worked on was really intended to carve
out a place for (3).

> to completely cut out of the reply.

I cut them out because I don't believe the IETF is the unambiguous
source of those reasons.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

> do not rely on the DNS at all.

Andrew - I have come around to agree that the properties and requirements of non-DNS resolution mechanisms are different from those of DNS resolution that does not use the root zone as a resolution context.  I believe that these properties and requirements cannot be served by the single .alt delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt for use of non-DNS resolution mechanisms.

How to proceed with DNS resolution that does not use the root zone as a resolution context is open for discussion.

- Ralph

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Feb 2017 09:24:29 +1100

In message <[email-masked]>, Ralph Droms writes:
> Andrew - I have come around to agree that the properties and requirements
> of non-DNS resolution mechanisms are different from those of DNS re
> solution that does not use the root zone as a resolution context.  I believe
> that these properties and requirements cannot be served by the single .alt
> delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt
> for use of non-DNS resolution mechanisms.
> 
> How to proceed with DNS resolution that does not use the root zone as a
> resolution context is open for discussion.
> 
> - Ralph

Whether a DNS transport is use or not for the names.  Any scheme
where names in use needs to have a insecure delegation if we expect
recursive server to answer for that namespace even if it is just
to stop query / name leaks.  That is basic DNSSEC.

.ONION needs this treatment.  If the ISP's recursive server is
answering for leaked .ONION names and the ISP's clients validating
recursive server is forwarding to the ISP's server (this is a common
configuration for some Linux distributions) then there will be
reties to all the ISP's servers.

No set of systems, when configured as specified by RFC, should ever
result in SERVFAIL being returned.  That is just poor engineering.
That will have the punters chasing configuration bugs that don't
exist.

Mark

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Feb 2017 19:37:24 -0800

TL;DR: it is possible to have a signed DNAME in the root for alt (to
empty.as112.arpa), AND have a local signed alt. Things under this local alt
can be signed or unsigned.

> to perform a lookup on foo.alt.

I spent some time mocking up a variety of configurations.

My original assertion stands; the particulars on making it work are perhaps
not interesting to everyone.
However, it falls in the "pics or it didn't happen" category, so here's
what I did to make it work.

1 - set up a general resolver with the standard ICANN root trust anchor.
Call it "X".
2 - set up a local "fake root server" which delegates to a "local alt
server". Call this fake root server "F"
3 - set up a local "alt server" which serves the local "alt" domain
(including any delegations, etc). Cal this "A".
3 - set up a second resolver, with appropriate trust anchor(s), that uses a
"fake root server" instead of the real root. Call this "Y".
4 - set up a forwarder, which is configured to always forward to "X",
except for the zone "alt", where it forwards to "Y". Make sure the
necessary trust anchors are configured. Call this "Z".

Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
anchors)
Z->X otherwise (and validates using the ICANN root trust anchor).

When I do this, I get real answers for everything but "alt". For anything
at or under "alt", I get my own local copy.

Everything validates (or is from below an insecure delegation point).

> including negative, configured.

In the above scenario, you CAN have an unsigned foo.alt, and it will not
get BOGUS.

If you want me to send you configs, just drop me a line.

> * A DNAME for ALT in the root zone.

The problem is with your set-up, not the ability to have a working
local-alt set-up.

You need to put "foo.alt" somewhere OTHER than on the validating recursive
server (which knows how to find the local "alt" stuff.)

TIL you can't mix authority and recursive on the same server, when you are
the target of a forwarder.

If the two are separated, it works correctly, including using an alternate
trust anchor for "alt".

Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Feb 2017 15:05:52 +1100

> can be signed or unsigned.

So now there is the problem of distributing trust anchors for the
locally signed .alt zone just to be able to generate a NXDOMAIN
response locally so that you don't leak names to the root servers.

Note: we have no automatic solution to this problem and there is
no possible solution.

A DNAME at the root is not the right solution to this.

Mark

> --001a113fece272cf3b0547e877d3
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">TL;DR: it is possible to have a signed DNAME in the root f=
> or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi=
> s local alt can be signed or unsigned.<br><div class=3D"gmail_extra"><br><d=
> iv class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <span=
>  dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">marka@i=
> sc.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
> margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
> t:1ex"><br>
> In message &lt;<a href=3D"mailto:CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebht=
> [email-masked]">CAH1iCiqXohb_7LsQ2EMo8ZB-<wbr>t20mKq_nUDS8vebhtSX=
> oM13DTg@<wbr>mail.gmail.com</a>&gt;<br>
> <span class=3D"gmail-">, Brian Dickson writes:<br>
> &gt;<br>
> </span>&gt;=C2=A0 =C2=A0 - I am in favor of AS112 for ALT<br>
> &gt;=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)<br>
> &gt;=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s=
> igned<br>
> &gt;=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u=
> sing an<br>
> &gt;=C2=A0 =C2=A0 alternative trust anchor<span class=3D"gmail-"><br>
> <br>
> </span>You need a insecure delegation for ALT for the purposes we want to<b=
> r>
> use ALT for.<br>
> <br>
> Go setup a test rig where you have a signed root with ALT as you<br>
> described.=C2=A0 A validiting recursive server which also serves foo.alt.<b=
> r>
> A second validating recursive server which forwards all queries to<br>
> the first recursive server.=C2=A0 All servers are configured with a trust<b=
> r>
> anchor for the test root zone and are validating responses.=C2=A0 Try<br>
> to perform a lookup on foo.alt.<br></blockquote><div><br></div><div>I spent=
>  some time mocking up a variety of configurations.</div><div><br></div><div=
> >My original assertion stands; the particulars on making it work are perhap=
> s not interesting to everyone.</div><div>However, it falls in the &quot;pic=
> s or it didn&#39;t happen&quot; category, so here&#39;s what I did to make =
> it work.</div><div><br></div><div>1 - set up a general resolver with the st=
> andard ICANN root trust anchor. Call it &quot;X&quot;.</div><div>2 - set up=
>  a local &quot;fake root server&quot; which delegates to a &quot;local alt =
> server&quot;. Call this fake root server &quot;F&quot;<br></div><div>3 - se=
> t up a local &quot;alt server&quot; which serves the local &quot;alt&quot; =
> domain (including any delegations, etc). Cal this &quot;A&quot;.</div><div>=
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a=
>  &quot;fake root server&quot; instead of the real root. Call this &quot;Y&q=
> uot;.</div><div>4 - set up a forwarder, which is configured to always forwa=
> rd to &quot;X&quot;, except for the zone &quot;alt&quot;, where it forwards=
>  to &quot;Y&quot;. Make sure the necessary trust anchors are configured. Ca=
> ll this &quot;Z&quot;.</div><div><br></div><div>Z-&gt;Y if QNAME matches &q=
> uot;alt&quot; or &quot;*.alt&quot; (and validates with local trust anchors)=
> </div><div>Z-&gt;X otherwise (and validates using the ICANN root trust anch=
> or).</div><div><br></div><div>When I do this, I get real answers for everyt=
> hing but &quot;alt&quot;. For anything at or under &quot;alt&quot;, I get m=
> y own local copy.</div><div><br></div><div>Everything validates (or is from=
>  below an insecure delegation point).</div><div>=C2=A0</div><blockquote cla=
> ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
> rgb(204,204,204);padding-left:1ex">
> <br>
> The second recursive server is the validating client that needs to<br>
> be able to get a answer other than BOGUS.=C2=A0 As we want to allow<br>
> foo.alt to be unsigned there can&#39;t be any other trust anchors,<br>
> including negative, configured.<br></blockquote><div><br></div><div>In the =
> above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS=
> .</div><div><br></div><div>If you want me to send you configs, just drop me=
>  a line.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
> px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Only solutions which allow content from the foo.alt zone to be<br>
> successfully resolved are acceptable.<br>
> <br>
> The following will not work with the above rig:<br>
> * No delegation for ALT.<br>
> * A secure delegation for ALT.<br>
> * A DNAME for ALT in the root zone.<br>
> <span class=3D"gmail-HOEnZb"><font color=3D"#888888"><br>
> Mark</font></span></blockquote><div><br></div><div>The problem is with your=
>  set-up, not the ability to have a working local-alt set-up.</div><div><br>=
> </div><div>You need to put &quot;foo.alt&quot; somewhere OTHER than on the =
> validating recursive server (which knows how to find the local &quot;alt&qu=
> ot; stuff.)=C2=A0</div><div><br></div><div>TIL you can&#39;t mix authority =
> and recursive on the same server, when you are the target of a forwarder.</=
> div><div><br></div><div>If the two are separated, it works correctly, inclu=
> ding using an alternate trust anchor for &quot;alt&quot;.</div><div><br></d=
> iv><div>Brian</div></div></div></div>
> 
> --001a113fece272cf3b0547e877d3--

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Feb 2017 21:50:24 -0800

Mark,

I don't think the use cases for most of the sandbox involving alt, and/or the homenet use case, requires support for validating stubs. If stubs aren't already validating, the incremental addition of a local alt, only requires distribution of the trust anchor to the resolvers. That is a solvable problem for most values of "local".

If use cases for non-local or validating stubs exits, IMHO that rises to the level of requiring something real, not an alt name.

If you think that is something that there is a demand for, I don't know if it might belong in a separate domain.

An insecure delegation from the root may be seen as an invitation for exploitation by squatters.

Sent from my iPhone

> On Feb 6, 2017, at 8:05 PM, Mark Andrews <[email-masked]> wrote:
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Feb 2017 17:31:46 +1100

In message <[email-masked]>, Brian Dickson writes:
> Mark,
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs. If stubs
> aren't already validating, the incremental addition of a local alt, only
> requires distribution of the trust anchor to the resolvers. That is a
> solvable problem for most values of "local".

It's not just stubs.

> If use cases for non-local or validating stubs exits, IMHO that rises to
> the level of requiring something real, not an alt name.
>

And if they could find a way to squat here (which requires intercepting
queries) what would be the problem?  We are expecting the namespace
to be squatted.  Thats the whole point of the namespace.  In fact
we are going to tell nameserver vendors to squat on .alt by default*
to generate the NXDOMAIN responses.

There is absolutely no need for a secure NXDOMAIN here.  Just as
there is zero need for secure NXDOMAINs in COM, ORG, NET or any
other gTLD.  The gTLDs prevent secure delegations being spoofed
away.  The don't prevent names being spoofed into existence between
the secure delegations.

There is absolutely no need for a secure delegation here.

I have not seen anyone demonstrate a technical need for a secure
delegation for alt.  There are no formal delegation in alt so there
can be no secure delegations from alt.

Mark

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Feb 2017 23:08:21 -0800

The suggestion of DNAME to empty.as112.arpa involves some subtle details, which IMHO may in combination be the right mix here.

The DNAME target is an insecure empty zone.

This avoids the validation issue, and facilitates use of local "alt" namespaces.

The default response to queries under alt would be unsigned NXDOMAINs.

I am not seeing a problem with this.

Am I missing anything?

Brian

Sent from my iPhone

> On Feb 6, 2017, at 10:31 PM, Mark Andrews <[email-masked]> wrote:
> 
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Feb 2017 18:27:50 +1100

In message <[email-masked]>, Brian Dickson writes:
> The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> which IMHO may in combination be the right mix here.
>

No it doesn't. 

> The default response to queries under alt would be unsigned NXDOMAINs.

No, it would be a secure response saying that foo.alt is covered
by a DNAME.  The names under empty.as112.arpa are unsigned NXDOMAINs.

The difference between the two descriptions is critical to why a
DNAME in the root zone will not work.  You *have* to leak names to
the root to get a DNAME returned by ordinary processing because the
DNAME is signed.

> I am not seeing a problem with this.

Yes.  A solution that *works*.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Feb 2017 23:55:58 -0800

> Yes.  A solution that *works*.
What are the specific requirements for the solution?

I am inferring that the following are needed:

The ability to have a local authority server for *.alt, where responses to
queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses.

The ability to have validating forwarders configured to point to one or
more resolvers, where the resolvers are configured to use these alt
server(s) (directly or indirectly)

The ability of validating stub resolvers to accept the answers received
(not BOGUS).

Does the existence of query rewriting matter, as long as the end result
RDATA is the expected value?
I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME
empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa <RRTYPE> <RRDATA>",
is that acceptable, as long as there is no validation failure?

Whatever initiated the DNS call, via the stub, would get back <RRDATA>, and
presumably be unaware of the presence of the DNAME.

I just want to be sure what is or is not acceptable, and what is explicitly
within the requirements for a working solution.

Brian

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Feb 2017 12:11:11 +0000

> is that acceptable, as long as there is no validation failure?

If there is a local namespace squatting on .alt (directly, not on the
rewritten alt.empty.as112.arpa) then this will conflict with the DNAME in
the root, which will cause resolution failures.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: West or northwest 4 or 5, increasing 6 at times, becoming variable
then southeast later, 3 or 4. Slight or moderate, occasionally rough in south.
Rain or squally showers. Moderate or good.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 08:06:59 -0500

On Feb 7, 2017, at 12:50 AM, Brian Dickson <[email-masked]> wrote:
> I don't think the use cases for most of the sandbox involving alt, and/or the homenet use case, requires support for validating stubs.

If .alt is being used for non-DNS names, you are correct, because non-DNS names cannot be validated, and should never enter the validation process.   However, if it is being used for DNS names, then you have to assume that the stub is validating.   Even though that is not the status quo at present, that's the direction things are likely to go in the future, and this document needs to continue to be correct in the future.

---

From: Bob Harold <[email-masked]>
Date: Tue, 7 Feb 2017 10:01:23 -0500

On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson <
[email-masked]> wrote:

> My original assertion stands; the particulars on making it work are
> perhaps not interesting to everyone.
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses
> a "fake root server" instead of the real root. Call this "Y".
> That's a lot of overhead just to get a local .alt domain.

What I envision for the future is an insecure delegation of .alt, and an
option in future cable modems to enable a local "homenet.alt" domain, which
would just work, even if some stub resolvers in the house are validating.
The cable modem is already a recursive resolver or forwarder, and dhcp
server, so it seems a logical place for the local domain.

-- 
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Feb 2017 11:45:23 -0500

Yay! Centithread!

On Tue, Feb 7, 2017 at 8:06 AM, Ted Lemon <[email-masked]> wrote:
> the homenet use case, requires support for validating stubs.
>
>
> If .alt is being used for non-DNS names, you are correct, because non-DNS
> names cannot be validated, and should never enter the validation process.
> However, if it is being used for DNS names, then you have to assume that the
> stub is validating.   Even though that is not the status quo at present,
> that's the direction things are likely to go in the future, and this
> document needs to continue to be correct in the future.

I still believe that .alt should be for non-DNS names only -- if they
happen to leak into the DNS, this is an error / failure -- the purpose
of having .alt as a locally served zone is to preserve the privacy of
the queries, not to over-ride them to some other local DNS name.

For DNS names, I think that there should be a *different* string (and
a different document) -- they have different meanings / behaviors.

I don't think I've seen a good argument for NOT doing the above -- why
(other thabn the sunk time / effort) don't we do two?

W

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 12:18:23 -0500

> (other thabn the sunk time / effort) don't we do two?

Right, this just seems obvious to me.   If we do two, we can tailor each solution to the need it is intended to fill, rather than trying to come up with some compromise that isn't ideal for either case.

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2017 18:49:45 -0000

>(other thabn the sunk time / effort) don't we do two?

I checked with the protocol police who told me that even with their
tasers set to maximum, they can't force people to use the right one.
I really doubt that if we bless both .alt and .lcl (or whatever) that
the people building stuff will use the one we want them to use.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 13:57:13 -0500

> the people building stuff will use the one we want them to use.

Then it won't work for them.   But fashionable though this sort of cynicism is, clear specifications do get read, and not everybody is a blithering idiot.   We can't protect people from shooting themselves in the foot, but we can make it possible for them not to shoot themselves in the foot.   That's what Warren is proposing.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 07:55:54 +1100

In message <[email-masked]>, Ted Lemon writes:
> Right, this just seems obvious to me.   If we do two, we can tailor each
> solution to the need it is intended to fill, rather than trying to come
> up with some compromise that isn't ideal for either case.

Because we want to prevent the names leaking any further than we
have to and to not have the leaked names get SERVFAIL the solution
to both is the same.  The delegation properties are driven by privacy
and the DNS protocol which includes DNSSEC because that is where
the leaked names are being looked up.

If you really do want to spend the time and effort to create two
delegations when only one is needed the only difference is does the
recursive server always instantiate the local empty zone or not.
i.e. is it recursing rather than iterating to get answers for *.alt.
The delegation in the root zone needs the same properties in both
cases.

For RFC 1918 zones named only instantiates the empty zone when the
recursive server will iterate for answers.  If it always forwards
to another recursive server then the instantiation is blocked.

You will note that 10.in-addr.arpa has a insecure delegation in the
global dns namespace like every other locally served zone.  They
have such a delegations so that recursive server can give answers
which can be validated regardless of whether the RFC 1918 address
space is in use or not.

We did good engineering for locally served zones (RFC 6303).  Lets
follow the good engineering there rather that religiously demand
that the delegation be signed because the later does not work.

The E in IETF is for ENGINEERING.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 16:34:25 -0500

Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.   When I validate, I get a secure denial of existence.   This is the correct behavior.   Why do you think we would get a SERVFAIL?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 08:48:46 +1100

In message <[email-masked]>, Ted Lemon writes:
> Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> When I validate, I get a secure denial of existence.   This is the
> correct behavior.   Why do you think we would get a SERVFAIL?

Because your testing is incomplete.

Go add a empty zone (SOA and NS records only) for alt to your
recursive server.  This is what needs to be done to prevent
privacy leaks.

Configure another recursive server to forward its queries to this
server and enable validation.

Now ask for foo.alt from this second server.

Mark

---

From: Brian Dickson <[email-masked]>
Date: Tue, 7 Feb 2017 13:53:39 -0800

> server and enable validation.
I believe this is an erroneous configuration.

You need to have the recursive server (the first one) forward to another
server for the empty zone, otherwise that zone's contents do not end up in
the recursive server's cache.

Once you have that, the other recursive server (added and forwarding to the
first recursive) only gets back the non-leak results.

Since the first server is always forwarding to the empty zone, it never
queries the root, and never gets the authenticated denial of existence.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 7 Feb 2017 14:18:41 -0800

> recursive server.  This is what needs to be done to prevent
Here are some possible alternatives (to having the empty zone be named
"alt.").

First: make the locally served empty zone be "empty.as112.arpa".

Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and the
locally served zone be the same name.

Or, third, have some other name for the zone (anything other than alt, or
really anything that doesn't collide with a global name), and then use a
local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that
zone's name (e.g. "homenet" or "homenet.local" or whatever  you wish).

Since all of the above occur at or below the transition to unsigned, they
should validate. (I need to test these, but I don't see why they wouldn't
work, and all of the above avoid leaking queries to the root or to AS112
servers.)

Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 10:21:04 +1100

In message <[email-masked]>
> the recursive server's cache.

No you don't.  The DS query for ALT needs to be answered from the
root zone.  This can still be done with default empty zones in play.
The below is for 10.in-addr.arpa as I can't be bothered with
configuring a ALT zone but it shows that it works with shipping
code.  I run lots of experimental code but not in this area.

% dig ds 10.in-addr.arpa +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2471
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: ba4fd3e10ed3b4972daf8a53589a50ba29889ab19d1a982d (good)
;; QUESTION SECTION:
;10.in-addr.arpa.		IN	DS

;; AUTHORITY SECTION:
10.in-addr.arpa.	3594	IN	RRSIG	NSEC 8 3 3600 20170226113733 20170205111120 4341 in-addr.arpa. im4xV0dDtx/ccyflDHOwta5h5hLslomiR4JRHynxSE0Tlm4DenVQ2t7B hwWVGE1eoNuVsagkDiYnRykkQX4bQCChsqKKWTVL57f3onXBmiTWXgWI Ruqzo3Oxa3jlbQ2dgO9bF/xpFrJ3/F7BTyoifA7h33dH1Ef1u2OW3p5p kfvR90s=
10.in-addr.arpa.	3594	IN	NSEC	100.in-addr.arpa. NS RRSIG NSEC
in-addr.arpa.		3594	IN	SOA	b.in-addr-servers.arpa. nstld.iana.org. 2016110943 1800 900 604800 3600
in-addr.arpa.		3594	IN	RRSIG	SOA 8 2 3600 20170301070658 20170207211120 4341 in-addr.arpa. JPiSzCVosbzqFnGmIY+WpANm7Si3cTrSFnTfl5ODB7YfyyzRb0TYsA1o nqpmUw5fQyWHY0nClNfqMEW2V529wT+FoG38SlQBNePtuZSjl3k3WIps snl/3HCY6ZFEaMvq+VmLm/9JQP9Nl2+o3n3qKUErZMxHjeJOmBq4O7E9 j0RUGAE=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 08 09:56:58 EST 2017
;; MSG SIZE  rcvd: 528

[rock:~/git/bind9] marka% dig soa 10.in-addr.arpa +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> soa 10.in-addr.arpa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7409
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: ef3c1c716b970b68d635c9d6589a50cceaa7428cb432d7df (good)
;; QUESTION SECTION:
;10.in-addr.arpa.		IN	SOA

;; ANSWER SECTION:
10.in-addr.arpa.	86400	IN	SOA	10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 08 09:57:16 EST 2017
;; MSG SIZE  rcvd: 122

[rock:~/git/bind9] marka% 

Now if I ask with a non recursive query for DS I get the answer
from the empty zone.

[rock:~/git/bind9] marka% dig ds 10.in-addr.arpa +dnssec +norec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32952
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 330bcb4d5f583a7463a60035589a52444193e9f918ef9905 (good)
;; QUESTION SECTION:
;10.in-addr.arpa.		IN	DS

;; AUTHORITY SECTION:
10.IN-ADDR.ARPA.	86400	IN	SOA	10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 08 10:03:32 EST 2017
;; MSG SIZE  rcvd: 122

[rock:~/git/bind9] marka% 

Now if I add a second validating server forwarding to this server
I will only see the first two responses.  There are lots of corner
cases with DNSSEC which this demonstrates but any server that
supports DNSSEC will do.

This difference in answers is similar to asking with recursive and
non recursive queries for the NS records at a delegation point
towards a parent server which supports recursion for the client.
You get answers from the child (answer) or parent zone (referral)
depending on the state of the RD bit.

Mark

> queries the root, and never gets the authenticated denial of existence.

Brian.  Go do the experiment with VALIDATION ON.

You can have heaps of different configurations if you are not
validating.

Once you have validation being performed then there is only one way
to do this that doesn't leak names beyond ALT itself.  You can't
prevent ALT being leaked if there is a validating client.

Mark

> --001a113fece2e8a7ce0547f7c7b3
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
> te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <span dir=3D"ltr">&lt;<a h=
> ref=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span>=
>  wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
> der-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=
> =3D"h5"><br>
> In message &lt;<a href=3D"mailto:18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue=
> .com">18F2EB0D-5BD0-4CC5-B02C-<wbr>[email-masked]</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt; Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, not S=
> ERVFAIL.<br>
> &gt; When I validate, I get a secure denial of existence.=C2=A0 =C2=A0This =
> is the<br>
> &gt; correct behavior.=C2=A0 =C2=A0Why do you think we would get a SERVFAIL=
> ?<br>
> <br>
> </div></div>Because your testing is incomplete.<br>
> <br>
> Go add a empty zone (SOA and NS records only) for alt to your<br>
> recursive server.=C2=A0 This is what needs to be done to prevent<br>
> privacy leaks.<br>
> <br>
> Configure another recursive server to forward its queries to this<br>
> server and enable validation.<br>
> <br></blockquote><div><br></div><div>I believe this is an erroneous configu=
> ration.</div><div><br></div><div>You need to have the recursive server (the=
>  first one) forward to another server for the empty zone, otherwise that zo=
> ne&#39;s contents do not end up in the recursive server&#39;s cache.</div><=
> div><br></div><div>Once you have that, the other recursive server (added an=
> d forwarding to the first recursive) only gets back the non-leak results.</=
> div><div><br></div><div>Since the first server is always forwarding to the =
> empty zone, it never queries the root, and never gets the authenticated den=
> ial of existence.</div><div><br></div><div>Brian</div><div>=C2=A0</div><blo=
> ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
> cc solid;padding-left:1ex">
> Now ask for foo.alt from this second server.<br>
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> Mark<br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </div></div></blockquote></div><br></div></div>
> 
> --001a113fece2e8a7ce0547f7c7b3--

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 10:44:05 +1100

In message <CAH1iCip=[email-masked]>
, Brian Dickson writes:
> --f403045fbba86cf7240547f82103
> Content-Type: text/plain; charset=UTF-8
> 

Which does not work.  If you are serving up a local

	ALT. SOA ...
	ALT. NS	...
	ALT. DNAME alt.empty.as112.arpa.

then it will not have RRSIG records so it will not validate unless there
is a INSECURE delegation for .ALT.

I really don't see the point in having the DNAME there other than you
seem to want a DNAME there.

The public version of the insecure .ALT zone could have a DNAME but
we are not talking about those contents at the moment.  We are
talking about what goes into the root zone to make this work.

> really anything that doesn't collide with a global name),

Nothing doesn't collide with a global name.  This is all about carving
a namespace out of the global namespace.

> and then use a

Homenet is still part of the global namespace.  Once there is a delegation
and a RFC which states that it is not part of the global namespace then
you have other issues or should we start squatting on the homenet space?
 
> --f403045fbba86cf7240547f82103
> <br></blockquote><div><br></div><div>Here are some possible alternatives (t=
> o having the empty zone be named &quot;alt.&quot;).</div><div><br></div><di=
> v>First: make the locally served empty zone be &quot;empty.as112.arpa&quot;=
> .</div><div><br></div><div>Or, second method: have the DNAME RDATA be &quot=
> ;alt.empty.as112.arpa&quot;, and the locally served zone be the same name.<=
> /div><div><br></div><div>Or, third, have some other name for the zone (anyt=
> hing other than alt, or really anything that doesn&#39;t collide with a glo=
> bal name), and then use a local DNAME from &quot;empty.as112.arpa&quot; (or=
>  &quot;alt.empty,as112.arpa&quot;) to that zone&#39;s name (e.g. &quot;home=
> net&quot; or &quot;homenet.local&quot; or whatever =C2=A0you wish).</div><d=
> iv><br></div><div>Since all of the above occur at or below the transition t=
> o unsigned, they should validate. (I need to test these, but I don&#39;t se=
> e why they wouldn&#39;t work, and all of the above avoid leaking queries to=
>  the root or to AS112 servers.)</div><div><br></div><div>Brian</div><div><b=
> r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
> 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> --f403045fbba86cf7240547f82103--

---

From: Brian Dickson <[email-masked]>
Date: Tue, 7 Feb 2017 16:00:09 -0800

>         ALT. DNAME alt.empty.as112.arpa.

No, I am saying the following:
In the root, assume the existence of "ALT. DNAME alt.empty.as112.arpa."

Locally, serve your desired content (for what would be reachable below
"alt") at:

ALT.EMPTY.AS112.ARPA SOA ...
ALT.EMPTY.AS112.ARPA NS ...
FOO.ALT.EMPTY.AS112.ARPA <RRTYPE> <RDATA>
etc

The second DNAME would be for convenience only, so your local zone name
isn't causing too much confusion.

It does not matter one whit what that zone name (as the DNAME RDATA) would
be, so long as it is not at or beneath a real global name.

Suppose you want to use "foo.x" instead of "foo.alt.empty.as112.arpa":
$ORIGIN alt.empty.as112.arpa.
foo DNAME foo.x.

foo.x. SOA ...
foo.x NS ...
$ORIGIN foo.x
bar TXT "I am bar.foo.x, reachable via bar.foo.alt.empty.as112.arpa or via
bar.foo.alt."

The first DNAME gets you default protection via the AS112 empty zone,
assuming (the generalized you) are not doing local "alt" things.

The local service of "alt.empty" over-rides the insecure empty zone, but
does not block the validation path down to it.

The second DNAME is for convenience only, or potentially for welding some
locally served "homenet" onto "homenet.alt".
(The latter I am pointing out the feasibility of, not advocating for.)

Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 11:56:46 +1100

In message <CAH1iCiq0bAiyZU0SqxWn7vH=[email-masked]>
, Brian Dickson writes:
> --001a1140fee44d9e500547f98cf1

So how do you get the DNAME returned without leaking a qname?
Answer:  You don't with current nameservers.

To prevent leaking you need to have something that regularly asks
for ALT/DNAME so that the answer is in the cache before the first
*.alt name comes along or you special case *.alt, make a DNAME query
for ALT instead of *.alt then resume the original query processing.

That is new code just to avoid a insecure delegation in the root
zone when we know we need a insecure delegation in the root zone
for .homenet.

You also generate bigger answers, run the risk of returning YXDOMAIN
and increase the validation cost.

There is a place for that DNAME in a insecurely delegated ALT zone.
That sinks all the traffic that is not caught by the other mechanism.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 23:51:03 -0500

> recursive server.  This is what needs to be done to prevent

No, the recursive server can just cache the proof of nonexistence.   I didn't query the root when I did my test—I ran the query through comcast's servers.   Worked just fine.   Yes, if you configure your local server to lie, that won't work.   That's by design.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 16:25:44 +1100

In message <[email-masked]>, Ted Lemon writes:
> No, the recursive server can just cache the proof of nonexistence.   I
> didn't query the root when I did my test—I ran the query through
> comcast's servers.   Worked just fine.   Yes, if you configure your local
> server to lie, that won't work.   That's by design.

And how does the server get the proof of non-existence?  It needs
to leak a query.  You server asked comcasts servers.  They in turn
asked the root servers.  By doing so you leaked the query to both
comcast and the root.

Unless you have aggressive negative caching or qname minimisation
you will leak all the leaked *.alt names.  Are you requiring that
every recursive nameserver on the planet older than a couple of
months be upgraded rather than reconfigured to get privacy?

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 00:44:16 -0500

On Feb 8, 2017, at 12:25 AM, Mark Andrews <[email-masked]> wrote:
> to leak a query.

If it has proof of non-existence for .alt cached, it doesn't need to ask any further questions to deny the existence of any subdomain of .alt.   Leaking a query to .alt is harmless.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2017 17:02:08 +1100

In message <[email-masked]>, Ted Lemon writes:
> If it has proof of non-existence for .alt cached, it doesn't need to ask
> any further questions to deny the existence of any subdomain of .alt.

Which assumes agggressive negative caching.   I'm going to make a
realistic assumption that it will take 10+ years for there to be
meaningful (>50%) deployment of aggressive negative caching.

> Leaking a query to .alt is harmless.

Is it?  What reports are we going to see over the next 20 year of
DITL data on *.alt.

Mark

---

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

On Wed, Feb 08, 2017 at 05:02:08PM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 30 lines which said:

> > If it has proof of non-existence for .alt cached, it doesn't need
> > to ask any further questions to deny the existence of any
> > subdomain of .alt.
> 
> Which assumes agggressive negative caching.

If by "aggressive negative caching", you mean
draft-ietf-dnsop-nsec-aggressiveuse, then I disagree with you: it is
*not* necessary (since the name is the same), you just need RFC 8020
support.

> I'm going to make a realistic assumption that it will take 10+ years
> for there to be meaningful (>50%) deployment of aggressive negative
> caching.

I would be quite happy to have RFC 8020 in BIND, if you don't mind :-)

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Feb 2017 11:26:28 +0000

Stephane Bortzmeyer <[email-masked]> wrote:
> Mark Andrews <[email-masked]> wrote:
> > Ted Lemon <[email-masked]> wrote:
> > >

For RFC 8020 to suppress these .alt leaked queries properly, you also need
qname minimization.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher: East 5 to 7, occasionally gale 8 at first. Moderate or rough. Snow
showers. Moderate or good, occasionally very poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 12:34:08 +0100

On Wed, Feb 08, 2017 at 11:26:28AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 23 lines which said:

> For RFC 8020 to suppress these .alt leaked queries properly, you
> also need qname minimization.

Yes, but anyone uses RFC 7816, anyway :-)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 10:05:42 -0500

> meaningful (>50%) deployment of aggressive negative caching.

First of all, this probably isn't true, since most of the caches we care about are run by network operators, who tend to update more frequently for obvious reasons.   But the solution you propose, which causes a SERVFAIL, involves a specially-prepared resolver.   So if you get to _create_ the problem with a specially-prepared resolver, I get to solve it with a differently specially-prepared resolver.   If you want queries to .alt not to leak, you have to preload your cache with a proof of nonexistence for .alt, and you have to keep it up to date.   This is not terribly difficult to arrange.

> Is it?  What reports are we going to see over the next 20 year of

How is that relevant?   Suppose we don't create .alt, and instead people just pick random top-level domains for their experiments, as they do now.   Will the number of bogus queries to the root be greater, or fewer?   Furthermore, queries for .alt are legitimate, in just the same way that queries for .com are.   They just have a different answer.

---

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

In message <[email-masked]>, Ted Lemon writes:
> First of all, this probably isn't true, since most of the caches we care
> about are run by network operators, who tend to update more frequently
> for obvious reasons.   But the solution you propose, which causes a
> SERVFAIL, involves a specially-prepared resolver.   So if you get to
> _create_ the problem with a specially-prepared resolver, I get to solve
> it with a differently specially-prepared resolver.   If you want queries
> to .alt not to leak, you have to preload your cache with a proof of
> nonexistence for .alt, and you have to keep it up to date.   This is not
> terribly difficult to arrange.
>
> How is that relevant?   Suppose we don't create .alt, and instead people
> just pick random top-level domains for their experiments, as they do now.
>   Will the number of bogus queries to the root be greater, or fewer?
> Furthermore, queries for .alt are legitimate, in just the same way that
> queries for .com are.   They just have a different answer.

Me, I'm trying to prevent the SERVFAIL issues the IETF has created for
.onion.  In particular this from RFC7686

   4.  Caching DNS Servers: Caching servers, where not explicitly
       adapted to interoperate with Tor, SHOULD NOT attempt to look up
       records for .onion names.  They MUST generate NXDOMAIN for all
       such queries.

Without .onion being a insecurely delegation this results in SERVFAIL
or BOGUS being returned for .onion named when validation is performed
by any validating software that is not RFC7686 aware.

Nameserver vendors have a choice.  Follow RFC7686 and have their
clients get a answer that they know cannot be validated or ignore
this clause and pretend that RFC7686 has never been written so that
their client get a validatable answer.  Should the IETF have put
Nameserver vendors in this position?

At this stage we have not yet implemented this clause in BIND.  We
are aware of RFC7686 and at some point someone will complain that
we don't implement this.  At that point we will point out to them
that this results in SERVFAIL or bogus being returned.

Note all through the debate about .onion I raise this issue.  Go
look at the archives.

Now draft-ietf-dnsop-alt-tld-07 has almost identical wording

   4.  Caching DNS servers SHOULD recognize these names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve these names.  Instead, caching DNS servers SHOULD
       generate immediate negative responses for all such queries.

This clause results in BOGUS or SERVFAIL being returned to the DNS
application if there is a validator in the return DNS path between
the caching DNS server and the application.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 14:49:34 -0500

> the caching DNS server and the application.

So, that is the thing to fix.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Feb 2017 07:30:18 +1100

In message <[email-masked]>, Ted Lemon writes:
> 	charset=us-ascii

And if the service has the same privacy issues as .onion has?

So we leak names until every recursive server in the world is
validating (what % is that today?) and supports agressive negative
caching (still a I-D).

Mark

---

From: Brian Dickson <[email-masked]>
Date: Wed, 8 Feb 2017 12:36:23 -0800

> by any validating software that is not RFC7686 aware.
So, while technically the instruction (SHOULD NOT) applies to full .onion
names,
it is a SHOULD NOT, not a MUST NOT.

Again, technically, the bit of code to do the following, IMHO, nears the
level of "trivial":
- upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
- cache the response, and as appropriate, re-query periodically.
- If a query for <anything>.onion is received, reply with the authenticated
denial of existence from the root (cached in step 2)

I believe this should prevent any SERVFAIL or BOGUS.

(I think this turns on the pedantic reading of "generate".)

> the caching DNS server and the application.

See above; maybe the text of alt-tld should be less prescriptive, and
instead use aggressive-negative compatible language (including use of
legitimate, signed denial of existence RRsets).

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 16:12:57 -0500

> validating (what % is that today?) and supports agressive negative

I feel like I am arguing with a wall, so if this doesn't work I will just give up.   But if it's okay for us to ask resolvers to make a chance, it is okay for us to ask resolvers to make the right change.   And if they don't, yes, it's possible that some queries will leak.   There is nothing we can do to prevent that other than harden caching servers and stub resolvers; if we are going to do that, we might as well do it right, by caching the full proof of nonexistence, rather lying about what's in the root zone.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Feb 2017 09:41:31 +1100

In message <[email-masked]>, Ted Lemon writes:
> I feel like I am arguing with a wall, so if this doesn't work I will just
> give up.   But if it's okay for us to ask resolvers to make a chance, it
> is okay for us to ask resolvers to make the right change.   And if they
> don't, yes, it's possible that some queries will leak.   There is nothing
> we can do to prevent that other than harden caching servers and stub
> resolvers; if we are going to do that, we might as well do it right, by
> caching the full proof of nonexistence, rather lying about what's in the
> root zone.

Actually we can do something that doesn't require that validation
be enabled.  We don't have to create that linkage.  It's not like
the names are not supposed to exist.  They do/will exist and not
as in they are/will be squatted upon.

Oh sorry, you can't have privacy unless you validate.  And only
because people are too scared to ask for changes to the root
zone to add a delegation.

Mark

---

From: Brian Dickson <[email-masked]>
Date: Wed, 8 Feb 2017 15:05:49 -0800

> as in they are/will be squatted upon.

I'm confused here.

The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is that
they exist ONLY within their own (local) scope, if they exist at all.

>From the viewpoint of the global DNS, they do not exist, and the point of
those I-Ds/RFCs is to enforce that non-existence, in the global scope.

My problem with what you are proposes, is that it removes the mechanism for
that enforcement.

Here's a thought - for any/all validating stubs, use CD=1 for names in the
set of "things that are meant to be local", and turn off validation of
those.
That *should*, if I understand 4035's directives for CD=1, prevent
validation by the recursive resolver in use by the client, and will return
whatever answers are present, with or without DNSSEC records.

Or, perhaps the organizations that represent the requestor of the 6761
names, could establish something like a "distrust anchor" - a trust anchor
which is only to be used for signing negative assertions about the TLD
name, or assertions about its insecure status to enable local service of
the TLD name, and which can be published to the community, along with a
static DNS zone file to be served by the <name>-aware resolvers?

Again, just to reiterate, in the global root zone, and for any resolvers
which are not yet onion-aware, onion does not exist and must not exist.

For onion-aware resolvers, everything related to onion is just an
optimization; avoiding leakage for privacy reasons might be an issue for
some folks, but IMHO must not tread on the previous requirement - that
onion must not exist in the root, and must not appear to exist to any
onion-unaware resolvers.

If you want to find a way to fix that, without resulting in BOGUS or
SERVFAIL, there may be ways that aren't easy, but the one way not permitted
by the published RFCs is, an unsigned delegation in the root.

I'm not sure why you disagree with this, it is clear as day in the relevant
RFCs.

Brian

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 8 Feb 2017 23:56:30 +0000

> The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is
> that they exist ONLY within their own (local) scope, if they exist at all.
>
> From the viewpoint of the global DNS, they do not exist, and the point
> of those I-Ds/RFCs is to enforce that non-existence, in the global scope.
>
> My problem with what you are proposes, is that it removes the mechanism
> for that enforcement.
>
> those.  That *should*, if I understand 4035's directives for CD=1, prevent
> names, could establish something like a "distrust anchor" - a trust
> anchor which is only to be used for signing negative assertions
> about the TLD name, or assertions about its insecure status to enable
> local service of the TLD name, and which can be published to the
> community, along with a static DNS zone file to be served by the
> <name>-aware resolvers?
>
> optimization; avoiding leakage for privacy reasons might be an issue
> for some folks, but IMHO must not tread on the previous requirement
> - that onion must not exist in the root, and must not appear to exist
> to any onion-unaware resolvers.
>
> SERVFAIL, there may be ways that aren't easy, but the one way not
> permitted by the published RFCs is, an unsigned delegation in the root.
>

I would like to just throw this out there again.. what about a new
RR type to actively flag the owner as officially not-existing?
I could even volunteer to write this if it seems reasonable.

It seems to me this issue has come up a number of times (.onion, etc.)
and it keeps needing to be solved each time.  The 6761, etc. and related
special-use registry contains a number of 'SHOULD' and 'SHOULD NOT'
requirements that need to be compiled into software, why not generalize
this a bit more just in case it happens again.

There is also the small matter of money vs. free.  If a zone is "simply"
delegated in the root zone, at some future point this delegation "could"
become a free service.  Without definitive "technical" rational for name
use, this is a difficult sell.  By defining an RR type purposefully
preventing this condition, it might be an easier pitch. Just a thought.

Thanks,
John

> I'm not sure why you disagree with this, it is clear as day in the
> relevant RFCs.
>
> Brian
>
>
>
>
-- 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: Thu, 9 Feb 2017 17:26:55 +0100

On Thu, Feb 09, 2017 at 09:41:31AM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 38 lines which said:

> And only because people are too scared to ask for changes to the
> root zone to add a delegation.

Being afraid to ask ICANN to do something is not cowardice, it is
common sense :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Feb 2017 17:31:23 +0100

On Wed, Feb 08, 2017 at 12:36:23PM -0800,
 Brian Dickson <[email-masked]> wrote 

> denial of existence from the root (cached in step 2)

Note that, if you implement RFC 7816 and RFC 8020, you already have
this behavior. No work for us :-)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 06:57:22 +1100

In message <[email-masked]>, Stephane Bortzmeyer writes
> this behavior. No work for us :-)

Only if you are willing to break lookups for names where there are
missing delegations in parent zone and the parent and child zones
share the same nameservers or the nameserver just misimplements ENT
or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist
with RFC 2535).  All of these result in NXDOMAIN for ENT.

RFC7816

   A problem can also appear when a name server does not react properly
   to ENTs (Empty Non-Terminals).  If ent.example.com has no resource
   records but foobar.ent.example.com does, then ent.example.com is an
   ENT.  Whatever the QTYPE, a query for ent.example.com must return
   NODATA (NOERROR / ANSWER: 0).  However, some name servers incorrectly
   return NXDOMAIN for ENTs.  If a resolver queries only
   foobar.ent.example.com, everything will be OK, but if it implements
   QNAME minimisation, it may query ent.example.com and get an NXDOMAIN.
   See also Section 3 of [DNS-Res-Improve] for the other bad
   consequences of this bad behaviour.

Mark

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Feb 2017 12:14:30 -0800

Maybe DNS authority server software could auto-generate TXT records for what would otherwise be ENTs, or zone administrators could add them manually,

E.g. ent.example.com TXT "This object intentionally left blank."

This avoids the ENT issue.

I can't think of any way that would break anything. The issue with ENTs is that they have children, which are not changed or harmed. Preventing the erroneous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be returned.

Brian

Sent from my iPhone

> On Feb 9, 2017, at 11:57 AM, Mark Andrews <[email-masked]> wrote:
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 07:45:06 +1100

In message <[email-masked]>, Brian Dickson writ
es:
> Maybe DNS authority server software could auto-generate TXT records for what=
>  would otherwise be ENTs, or zone administrators could add them manually,
> 
> I can't think of any way that would break anything. The issue with ENTs is t=
> hat they have children, which are not changed or harmed. Preventing the erro=
> neous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be=
>  returned.
> 
> Brian

Brian.
	There is only one time you can trust a NXDOMAIN to mean
there is no data under it.  That is when it validates as secure.

At the moment we have Ted saying that if you want privacy you MUST
also turn on DNSSEC validation and implement QNAME minimisation and
implement agressive negative caching (still a I-D).  This is all
because of ungrounded fears of people using DNS as a way to do a
opt-in experimental naming in .alt where we intend to have experimental
opt-in naming services.  Add to that it is suggested that we create
yet another TLD (.lcl) where such services would be allowed.

Mind boggling inconsistancy.

Mark

> >=20
> >=20
> > In message <[email-masked]>, Stephane Bortzmeyer w=
> rites
> > :
> >> Brian Dickson <[email-masked]> wrote=20
> >>=20
> >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=3D
> =
> 1.
> >>> - If a query for <anything>.onion is received, reply with the authentica=
> ted
> >>=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > --=20

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 16:01:12 -0500

On Feb 9, 2017, at 3:45 PM, Mark Andrews <[email-masked]> wrote:
> implement agressive negative caching (still a I-D).

No, I am _not_ saying that.   I am saying that an unsigned delegation doesn't help with privacy unless you also specially configure your local resolver, and if you are going to specially configure your local resolver, then there are several options for how to do that.   The only reason you need DNSSEC is that if you specially configure your local resolver to lie, then DNSSEC validation will break that.   If you aren't doing DNSSEC validation, you can say any old thing in your local resolver and the stub will believe it.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 09:48:51 +1100

In message <[email-masked]>, Ted Lemon writes:
> No, I am _not_ saying that.   I am saying that an unsigned delegation
> doesn't help with privacy unless you also specially configure your local
> resolver, and if you are going to specially configure your local
> resolver, then there are several options for how to do that.   The only
> reason you need DNSSEC is that if you specially configure your local
> resolver to lie, then DNSSEC validation will break that.   If you aren't
> doing DNSSEC validation, you can say any old thing in your local resolver
> and the stub will believe it.

And a signed answer doesn't help unless the recursive server is
validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
(to prevent *.alt leaking in the first place) and has agressive
negative caching (so the answer from the minimised QNAME query get
turned into a answer for *.alt).

Now we can put QNAME minimisation into a server.
Now we can put the code to support agressive negative caching into a server.
We can't force validation to be enabled.

We need all three things for the privacy leakage to stop.  Any two
alone doesn't stop it.

The alternative is to do a insecure delegation and build in a default
empty zone for alt.  You then have to take steps to break the privacy
leak by disabling the empty zone.  Additionally it works with all
existing servers if they just add a empty .alt zone.  It doesn't
require validation to be enabled.

It's the difference between defaulting private or not.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 18:07:08 -0500

How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver
is doing qname minimization?

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Feb 2017 15:09:46 -0800

> > and the stub will believe it.
Suppose a signed delegation for alt, to some widely operated, centrally
managed servers (say, the arpa servers).
Now suppose an unsigned delegation for some other name under alt, such as
"foo.alt", to an empty zone on the same set of servers.

The only difference here is where the unsigned delegation is, and what the
scope of that delegation is.

In this scenario, any local "foo.alt" can lie about the contents of
"foo.alt", because it is outside of the secure delegation chain from the
root.

The only difference is that the delegation is not directly from the root.

Any other name under "alt" would have its existence securely denied, unless
and until a request for an insecure delegation was made and approved.

Is there a problem with this scenario?

> We need all three things for the privacy leakage to stop.  Any two

There's something I don't understand.

In the case where the local namespace (in your email, that would be "alt",
in my example above, that would be "foo.alt") is not configured, why does
leaking matter? Obviously the real local use case is "won't work - broken
config", and leaking is mostly moot.

In the case where the local namespace is instantiated, the queries won't
leak to the root, so privacy is assured.

Are you saying that leakage when the local namespace is non-existent, is
a/the issue?

I don't agree, if that is what you are asserting.
Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are
using a resolver specifically configured for "foo.alt".
Note that defaulting to providing "empty.as112.arpa", and having the DNAME
to "alt.empty.as112.arpa", would further actually accomplish privacy,
without affecting the local instantiation of "foo.alt" via
"foo.alt.empty.as112.arpa".

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 10:28:30 +1100

> is doing qname minimization?

Because QNAME minimization does not stop on NXDOMAIN.  Too much
broken stuff out there to stop on NXDOMAIN.  The purpose of QNAME
minimization is prevent leaking too much information about the qname
to the parent zone.  It does nothing to prevent leakage of the QNAME
to the containing zone.

For that to happen you need the other two conditions to be met.
 
> --94eb2c0c8e5cca568e0548210c07
> <div dir=3D"ltr">How does a query for, e.g., super-s3kr1t.alt leak if your =
> caching resolver is doing qname minimization?</div><div class=3D"gmail_extr=
> a"><br><div class=3D"gmail_quote">On Thu, Feb 9, 2017 at 5:48 PM, Mark Andr=
> ews <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=
> ">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
> style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
> v class=3D"HOEnZb"><div class=3D"h5"><br>
> In message &lt;<a href=3D"mailto:12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue=
> .com">12D7473B-3A22-4A8D-9C13-<wbr>[email-masked]</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt;<br>
> &gt; On Feb 9, 2017, at 3:45 PM, Mark Andrews &lt;<a href=3D"mailto:marka@i=
> sc.org">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt; At the moment we have Ted saying that if you want privacy you MUS=
> T<br>
> &gt; &gt; also turn on DNSSEC validation and implement QNAME minimisation a=
> nd<br>
> &gt; &gt; implement agressive negative caching (still a I-D).<br>
> &gt;<br>
> &gt; No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d=
> elegation<br>
> &gt; doesn&#39;t help with privacy unless you also specially configure your=
>  local<br>
> &gt; resolver, and if you are going to specially configure your local<br>
> &gt; resolver, then there are several options for how to do that.=C2=A0 =C2=
> =A0The only<br>
> &gt; reason you need DNSSEC is that if you specially configure your local<b=
> r>
> &gt; resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I=
> f you aren&#39;t<br>
> &gt; doing DNSSEC validation, you can say any old thing in your local resol=
> ver<br>
> &gt; and the stub will believe it.<br>
> <br>
> </div></div>And a signed answer doesn&#39;t help unless the recursive serve=
> r is<br>
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion<br>
> (to prevent *.alt leaking in the first place) and has agressive<br>
> negative caching (so the answer from the minimised QNAME query get<br>
> turned into a answer for *.alt).<br>
> <br>
> Now we can put QNAME minimisation into a server.<br>
> Now we can put the code to support agressive negative caching into a server=
> .<br>
> We can&#39;t force validation to be enabled.<br>
> <br>
> We need all three things for the privacy leakage to stop.=C2=A0 Any two<br>
> alone doesn&#39;t stop it.<br>
> <br>
> The alternative is to do a insecure delegation and build in a default<br>
> empty zone for alt.=C2=A0 You then have to take steps to break the privacy<=
> br>
> leak by disabling the empty zone.=C2=A0 Additionally it works with all<br>
> existing servers if they just add a empty .alt zone.=C2=A0 It doesn&#39;t<b=
> r>
> require validation to be enabled.<br>
> <br>
> It&#39;s the difference between defaulting private or not.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
> Mark Andrews, ISC<br>
> </div></div></blockquote></div><br></div>
> 
> --94eb2c0c8e5cca568e0548210c07--

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 10:47:26 +1100

In message <[email-masked]>
> managed servers (say, the arpa servers).

All delegations from the root are signed as the root zone is signed.
The difference is it a secure delegation (with DS record) or a
insecure delegation (proof of non existance of the DS).

I'd insecurely delegate alt to the root servers themselves.  There
is no point in spreading the leakage.

> Is there a problem with this scenario?

It requires alt to be a registry.  One of the point of this I-D is
to get a namespace that doesn't have a registry.

> Are you saying that leakage when the local namespace is non-existent, is

Because when TPB go on a witch hunt for all users of xxxx.alt we
don't want the root servers operators to be able to return the
addresses.  It's not a matter of if, just when.  We have seen that
happen too many times.

> "foo.alt.empty.as112.arpa".

A DNAME doesn't give privacy.  You need QNAME minimisation with a
qtype of DNAME instead of NS.

> --001a113fece2d952b805482113d7
> te">On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <span dir=3D"ltr">&lt;<a h=
> <br></div></div></blockquote><div><br></div><div>Suppose a signed delegatio=
> n for alt, to some widely operated, centrally managed servers (say, the arp=
> a servers).</div><div>Now suppose an unsigned delegation for some other nam=
> e under alt, such as &quot;foo.alt&quot;, to an empty zone on the same set =
> of servers.</div><div><br></div><div>The only difference here is where the =
> unsigned delegation is, and what the scope of that delegation is.</div><div=
> ><br></div><div>In this scenario, any local &quot;foo.alt&quot; can lie abo=
> ut the contents of &quot;foo.alt&quot;, because it is outside of the secure=
>  delegation chain from the root.</div><div><br></div><div>The only differen=
> ce is that the delegation is not directly from the root.</div><div><br></di=
> v><div>Any other name under &quot;alt&quot; would have its existence secure=
> ly denied, unless and until a request for an insecure delegation was made a=
> nd approved.</div><div><br></div><div>Is there a problem with this scenario=
> ?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
>  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb=
> "><div class=3D"h5">
> alone doesn&#39;t stop it.<br></blockquote><div><br></div><div><br></div><d=
> iv>There&#39;s something I don&#39;t understand.=C2=A0</div><div><br></div>=
> <div>In the case where the local namespace (in your email, that would be &q=
> uot;alt&quot;, in my example above, that would be &quot;foo.alt&quot;) is n=
> ot configured, why does leaking matter? Obviously the real local use case i=
> s &quot;won&#39;t work - broken config&quot;, and leaking is mostly moot.</=
> div><div><br></div><div>In the case where the local namespace is instantiat=
> ed, the queries won&#39;t leak to the root, so privacy is assured.</div><di=
> v><br></div><div>Are you saying that leakage when the local namespace is no=
> n-existent, is a/the issue?</div><div><br></div><div>I don&#39;t agree, if =
> that is what you are asserting.</div><div>Queries for &quot;rumplestiltskin=
> .foo.alt&quot; can&#39;t expect privacy, unless they are using a resolver s=
> pecifically configured for &quot;foo.alt&quot;.</div><div>Note that default=
> ing to providing &quot;empty.as112.arpa&quot;, and having the DNAME to &quo=
> t;alt.empty.as112.arpa&quot;, would further actually accomplish privacy, wi=
> thout affecting the local instantiation of &quot;foo.alt&quot; via &quot;fo=
> o.alt.empty.as112.arpa&quot;.</div><div><br></div><div>Brian</div><div>=C2=
> =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
> r-left:1px #ccc solid;padding-left:1ex">
> <br>
> --001a113fece2d952b805482113d7--

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 19:28:05 -0500

> to the parent zone.  It does nothing to prevent leakage of the QNAME

Er, maybe I don't understand qname minimization correctly.   My understanding is that the way it works is that the recursive resolver does not forward the entire query up the chain: it just forwards the bit it needs resolved to answer the next question.   So, if you ask for foo.alt, the resolver should first ask for "." (except it probably already has it), and then "alt.", which will return an NXDOMAIN.   So it will never ask anybody for foo.alt, because it has no-one to ask.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Feb 2017 16:40:23 -0800

> addresses.  It's not a matter of if, just when.  We have seen that

I'm not sure who "TPB" is, but...

If you really care about privacy, IMHO, the place to instantiate the
private namespace, is under one of the heavily used AS112 zones.

E.g. 10.in-addr.arpa, or 168.192.in-addr.arpa.

It's unsigned, by default (for BIND) local already, and even if a leak
occurs, it will be hiding among the sheer volume of crap.
Plus, having the AS112 decentralization applied, means any incidental
leakage is going to be nearly impossible to find.

Using a new TLD for local use-cases that do want to be in a privately
forked piece or the global namespace, is perhaps unwise.

One thing to consider: the client will not know whether the resolver has
leaked or not.

Maybe this should be a DPRIVE topic, rather than general dnsop?

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 11:48:01 +1100

In message <[email-masked]>, Ted Lemon writes:
> Er, maybe I don't understand qname minimization correctly.   My
> understanding is that the way it works is that the recursive resolver
> does not forward the entire query up the chain: it just forwards the bit
> it needs resolved to answer the next question.   So, if you ask for
> foo.alt, the resolver should first ask for "." (except it probably
> already has it), and then "alt.", which will return an NXDOMAIN.   So it
> will never ask anybody for foo.alt, because it has no-one to ask.

No, it will ask for foo.alt because:
1) there is too much brokeness out there that returns NXDOMAIN instead of
   a NODATA for a ENT.
2) the cache don't have a DNSSEC proof of non existence for foo.alt
   without also having agressive negative caching (code and
   configuration) and the answer for alt having validated as a
   secure NXDOMAIN.

QNAME minimisation prevents the root learning about foo.com because
there is a delegation for com in the root zone.  This does not apply
for foo.alt.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 20:15:32 -0500

> 1) there is too much brokeness out there that returns NXDOMAIN instead of

So you're saying that a root nameserver is going to return an incorrect result?   And what does this have to do with intelligent trees?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 12:57:25 +1100

In message <[email-masked]>, Ted Lemon writes:
> > 1) there is too much brokeness out there that returns NXDOMAIN instead
> > of  a NODATA for a ENT.
>
> So you're saying that a root nameserver is going to return an incorrect
> result?  And what does this have to do with intelligent trees?

I'm developing software that will be run on private internets with
various degrees of compentence from the adminitrators as well as
the public Internet.  That private internet may have a ENT for ALT
that returns NXDOMAIN.  The server has to work in that environment.

So NXDOMAIN doesn't stop the query.

Even with everything working properly QNAME minimisation DOES NOT
STOP THE QUERIES.

RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 4035)
RFC 4035 + RFC 7816 + ANC supported by the code w/o validation -> leaks
RFC 4035 + RFC 7816 + ANC supported by the code + validation -> no leaks

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 13:04:25 +1100

> RFC 4035 + RFC 7816 + ANC supported by the code + validation -> no leaks

And to complete the table
RFC 4035 + ANC supported by the code + validation -> leaks (no queries for alt)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 21:44:53 -0500

> that returns NXDOMAIN.  The server has to work in that environment.

I don't know what an ENT is.   In any case, I don't see what this has to do with what we are talking about.   It is an absolute fact that if you want ALT queries not to leak you need to have a specially-configured recursive resolver, or else one that is really quite up to date.   If you have one that is really quite up to date, a secure denial of existence will do the right thing.

So we are really just arguing about how to specially configure out-of-date resolvers.   This is really out of scope.   There is nothing dnsop can do to make sure that these queries do not leak, so we should just decide what the right design is assuming that all the moving parts are working correctly, and leave it at that.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Feb 2017 16:07:01 +1100

In message <[email-masked]>, Ted Lemon writes
:
> I don't know what an ENT is.

Empty Non Terminal which is a quite common acronym in this group.

>   In any case, I don't see what this has to do with what we are talking
> about.   It is an absolute fact that if you want ALT queries not to leak
> you need to have a specially-configured recursive resolver,

Pray tell what specially-configured recursive resolver works?

> or else one that is really quite up to date.

Actually one from the future.  We don't have a RFC that say to perform
agressive negative caching.

> If you have one that is really quite
> up to date, a secure denial of existence will do the right thing.

Only if you also validate.

You are putting the "you can play bar" for privacy at the ceiling.

> So we are really just arguing about how to specially configure
> out-of-date resolvers.   This is really out of scope.   There is nothing
> dnsop can do to make sure that these queries do not leak, so we should
> just decide what the right design is assuming that all the moving parts
> are working correctly, and leave it at that.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Feb 2017 01:23:23 -0500

Could your concern be addressed with secure denial of existence plus the
right text about how to configure recursive resolvers?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2017 09:55:44 +0100

On Fri, Feb 10, 2017 at 06:57:22AM +1100,
 Mark Andrews <[email-masked]> wrote 

> with RFC 2535).  All of these result in NXDOMAIN for ENT.

Funny, I did not expect *you* to claim we have to accomodate broken
name servers :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2017 09:58:45 +0100

On Fri, Feb 10, 2017 at 09:48:51AM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 43 lines which said:

> and has agressive negative caching (so the answer from the minimised
> QNAME query get turned into a answer for *.alt).

As I already said here, if by "agressive negative caching", you mean
draft-ietf-dnsop-nsec-aggressiveuse, then the above sentence is
*false*. RFC 8020 is enough to "turn the answer from the minimised
QNAME query to a answer for *.alt".

[And I would really like to see BIND implement it.]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2017 10:10:54 +0100

On Fri, Feb 10, 2017 at 11:48:01AM +1100,
 Mark Andrews <[email-masked]> wrote 

> No, it will ask for foo.alt because:

This is false (and Ted Lemon was correct in describing QNAME
minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only:

09:05:55.233366 IP6 2001:4b98:dc2:43:216:3eff:fea9:41a.64146 > 2a01:4f8:161:6106:1::10.53: 36407% [1au] A? alt. (32)

If, afterwards, I ping bar.alt, there is no outgoing DNS request (this
is because of "NXDOMAIN cut").

> there is a delegation for com in the root zone.  This does not apply

This does not seem true.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2017 10:14:39 +0100

On Thu, Feb 09, 2017 at 04:40:23PM -0800,
 Brian Dickson <[email-masked]> wrote 

> private namespace, is under one of the heavily used AS112 zones.
[...]
> even if a leak

This was proposed in draft-bortzmeyer-dname-root. But read its
Security considerations section: not everyone agrees that leaking to
AS112 is harmless.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Feb 2017 10:26:42 +0100

On Fri, Feb 10, 2017 at 12:57:25PM +1100,
 Mark Andrews <[email-masked]> wrote 

> RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 4035)

RFC 4035 (if more security needed, but it is not *necessary*) + RFC
7816 + RFC 8020 -> no leaks

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Feb 2017 12:07:58 -0500

> it is a SHOULD NOT, not a MUST NOT.

Note also that the original request was that it be a MUST NOT, and
some of us tried to explain that RFCs do not actually determine what
people may do and it's the Internet, and so you couldn't make a
requirement in one RFC that would be guaranteed to be implemented by
those who don't implement that RFC.  Which means that the restricton
is a stupid one.  The result was a compromise in which it says "SHOULD
NOT".  In this case, the pretty good reason not to implement the
restriction is that the Internet doesn't work the way the people who
wanted onion to work thought it did.

Any name under alt -- which is, rememeber, _supposed_ to be the
protocol switch in the way Warren and I originally were thinking --
should never get looked up in the global DNS.  If it does, that's
because someone is trying to use a name that contains right in itself
an indication that it needs an alternative resolution context, and not
having that resolution context available.  It might be that such a
computer will erroneously fall back on the global DNS.  That's not a
reason for us to do contortions in the specification.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Feb 2017 12:31:24 -0500

> server, so it seems a logical place for the local domain.

No, it won't just work if a stub is validating, because the validating
stub will want to validate the delegation from the parent, and that
will be a proof of non-existence.  Provable non-existence prevents you
from being poisoned through typosquatting, but it means you can't
inject things in the tree without co-operation from the parent.

This is part of why I don't want to extend alt this way, and the more
I think about it the less desirable it seems to me.  We have a
particular problem: non-DNS-protocol switching for applications that
want to use a DNS-compatible domain name slot (see RFC 5890).  This is
problems like onion, local, and so on.  We propose a solution in which
we steal four of the available 255 octets to create a "safe" space
from DNS delegation.  Now anyone can use that space for their non-DNS
protocol, and every resolver library in the world knows that if it
runs into a name in the alt tree it shouldn't need to look it up in
DNS.  If the query leaks to the root and gets a proof of
non-existence, it doesn't matter because it was supposed to be a
different protocol.  Non-existence in the DNS is analytically true.
If a validating resolver gets an answer back from another resolver
that provides NXDOMAIN without the proof of non-existence and treats
the result as bogus instead, who cares?  It was never supposed to
resolve in the DNS anyway.

The homenet case is different, because it _is_ supposed to work with
DNS.  In that case, the missing proofs are a problem for validating
end points.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2017 18:25:28 -0000

>will be a proof of non-existence. ...

Yeah.  It seems to me that if we want DNSSEC to work for locally
served DNS subtrees, we need some way to distribute trust anchors for
the subtrees to those cable modems.  While that is probably not an
insoluble problem, it is not one that I would plan to solve any time
soon, so it's one I would prefer to address separately.

>want to use a DNS-compatible domain name slot (see RFC 5890).

Agreed.  Say that you can do anything you want with .ALT (duh) but you
SHOULD NOT resolve .ALT names via the DNS protocol because of the
DNSSEC problems.  To minimize leakage, we can use the tools we already
have: qname minimization, local mirrors of the root, and special
casing in DNS caches as many now do for .onion.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 10 Feb 2017 13:41:05 -0500

Hi,

The editors hold the token on text for this, but it seems to me that the discussion has started going in circles.

A number of arguments have been made, and in some cases repeated. Let’s assume the editors have heard them and try to restrict followups to new observations, questions, or arguments.

> On Feb 10, 2017, at 1:25 PM, John Levine <[email-masked]> wrote:
> 

This sounds reasonable to me.

Suzanne