Subject: [homenet] My assessment of .homenet as described during the WG session yesterday.

From: Terry Manderson <[email-masked]>
Date: Tue, 28 Mar 2017 17:32:31 +0000

Dear HOMENET and DNSOP WG(s),

Wearing the INT AD hat.

Firstly, thank you to the DNSOP WG for the deep review, thoughts, and considered responses to my request for review.

Secondly, my apologies for not sharing my throughs before the HOMENET session. It would have been impractical to do so as this is a very (VERY) fluid situation with IETF leadership also engaged in discussions.

This is simply an iteration of my description of the current situation as delivered yesterday. Do be aware that conversations are continuing and you should NOT take this as a declarative statement. During the HOMENET WG session I specified that for this topic I am comfortable answering _ clarifying _ questions. The same applies here. My answers may or may not change due to the fluid nature of the concern and I hope you appreciate that.

My summary of the situation is this.

1) .homenet _COULD_ be added to the special use domain registry based on RFC6761 

2) The expected future operation of HOMENET resolution for DNSSEC validating stub resolvers requires a break in the DNSSEC chain of trust.

3) To achieve "2", the document _additionally_ asks IANA to insert an insecure delegation into the root zone

4) The ask for "3" is not covered in IETF policy terms, in fact it tries to put an entry into someone else's registry (the root zone), and will require a set of collaborative discussions with the ICANN community and a new process that handles this situation. There are no expectations that this process will be defined in a reasonable time for the uses of HOMENET.

Options, possibly not an exhaustive list

A) seek a .homenet special use domain with the request for an insecure delegation in the root zone. (This is what the document asks for NOW, and here we are)

B) seek a .homenet special use domain WITHOUT the delegation request AND ask the IETF/IESG/IAB to commence the discussion with the ICANN community to achieve an insecure delegation

c) seek a <SOMETHING>.arpa insecure special use delegation

d) go for "B" and if that doesn't work shift to "C"

Each of these have different positive and negatives in a raw technical sense, UI design desires, and policy and political frames.

Again, this situation is fluid and as discussions evolve I will provide more information when it is appropriate. In the mean-time I would very much like everyone to take a calming breath and understand that I am taking a very pragmatic view of this concern.

Cheers,
Terry
INT AD

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Mar 2017 09:48:43 -0500

Hi Terry,

Clarifying questions here...

> 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to put an entry into someone else's registry (the root zone), and will require a set of collaborative discussions with the I…

q1. What precisely about “3” is not covered in IETF policy terms? That the document directs IANA to request a delegation in the root zone? Or that the document directs IANA to request an *insecure* delegation in the root zone, whereas a secure delegation *would* be adequately covered? Or both of these?

q2. If the answer to q1 is that both aspects of “3” are not covered in IETF policy terms, and that each one will require a set of collaborative discussions with the ICANN community and new processes that handle each of these situations, are there any expectations about which of the two processes, if there are two and not just one, can be defined in a workable period of time for HOMENET?

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: George Michaelson <[email-masked]>
Date: Wed, 29 Mar 2017 09:51:32 -0500

sign it with a bad key or bad DS. this goes to SERVFAIL and its NXDOMAIN.

-G

On Wed, Mar 29, 2017 at 9:48 AM, james woodyatt <[email-masked]> wrote:
> 2) The expected future operation of HOMENET resolution for DNSSEC validating
> stub resolvers requires a break in the DNSSEC chain of trust.
>
> 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to
> put an entry into someone else's registry (the root zone), and will require
> a set of collaborative discussions with the ICANN community and a new
> process that handles this situation. There are no expectations that this
> process will be defined in a reasonable time for the uses of HOMENET.
>
>
> q1. What precisely about “3” is not covered in IETF policy terms? That the
> document directs IANA to request a delegation in the root zone? Or that the
> document directs IANA to request an *insecure* delegation in the root zone,
> whereas a secure delegation *would* be adequately covered? Or both of these?
>
> q2. If the answer to q1 is that both aspects of “3” are not covered in IETF
> policy terms, and that each one will require a set of collaborative
> discussions with the ICANN community and new processes that handle each of
> these situations, are there any expectations about which of the two
> processes, if there are two and not just one, can be defined in a workable
> period of time for HOMENET?
>
> --james woodyatt <[email-masked]>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 11:07:55 -0400

Terry Manderson <[email-masked]> wrote:
    > B) seek a .homenet special use domain WITHOUT the delegation request
    > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
    > community to achieve an insecure delegation

    > d) go for "B" and if that doesn't work shift to "C"

Is there some reason we can not proceed with "C", concurrently with (B).
This might cause stub resolvers to have to have two cases
(SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
and attempt interop with SOMETHING.arpa NOW, and it would more clearly
permit "home." to be removed from code.

    > Again, this situation is fluid and as discussions evolve I will provide
    > more information when it is appropriate. In the mean-time I would very
    > much like everyone to take a calming breath and understand that I am
    > taking a very pragmatic view of this concern.

Thank you!

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Terry Manderson <[email-masked]>
Date: Wed, 29 Mar 2017 15:37:09 +0000

Hi James,

Q1. Both. The root zone, as a registry, is not an IETF registry.

Q2. My guess, and I am really guessing here, that if a process were to be created by the ICANN community to accept such requests from the IETF, it would be encompassing of both.

Cheers
Terry 

On 30/03/2017, 12:48 AM, "homenet on behalf of james woodyatt" <[email-masked] on behalf of [email-masked]> wrote:

    q1. What precisely about “3” is not covered in IETF policy terms? That the document directs IANA to request a delegation in the root zone? Or that the document directs IANA to request an *insecure* delegation in the root zone, whereas a secure delegation
     *would* be adequately covered? Or both of these?

    q2. If the answer to q1 is that both aspects of “3” are not covered in IETF policy terms, and that each one will require a set of collaborative discussions with the ICANN community and new processes that handle each of these situations, are there any expectations
     about which of the two processes, if there are two and not just one, can be defined in a workable period of time for HOMENET?

---

From: Terry Manderson <[email-masked]>
Date: Wed, 29 Mar 2017 15:41:36 +0000

Hi Michael,

There is no policy or technical barrier to proceeding with SOMETHING.arpa. Procedurally that, of course, would necessitate some WG discussion and consensus.

Cheers
Terry

On 30/03/2017, 1:07 AM, "DNSOP on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    Thank you!

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Mar 2017 16:10:57 -0400

Terry Manderson <[email-masked]> wrote:
    Terry> There is no policy or technical barrier to proceeding with
    Terry> SOMETHING.arpa. Procedurally that, of course, would necessitate some WG
    terry> discussion and consensus.

...
    Terry> c) seek a <SOMETHING>.arpa insecure special use delegation

    mcr> This might cause stub resolvers to have to have two cases
    mcr> (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
    mcr> and attempt interop with SOMETHING.arpa NOW, and it would more clearly
    mcr> permit "home." to be removed from code.

I believe that HOMENET should proceed immediately with asking the IAB for
<SOMETHING>.arpa.

I think that getting "home." removed from implementation is pretty important.

let's do this ask concurrently with deciding what <SOMETHING> is.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Mar 2017 16:59:27 -0500

Many Thanks for posting this, Terry.

Homenet,

As Terry said, these options are still very fluid and may come or go. That said, Ray and I talked this over and believe Option B fits well within the spirit of the consensus call made at IETF 97 to redact and replace .home with .homenet (understanding at the time that it could be more difficult process-wise than if we requested .homenet.arpa). 

- Mark

> On Mar 28, 2017, at 12:32 PM, Terry Manderson <[email-masked]> wrote:
> 
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Mar 2017 17:07:15 -0500

> On Mar 29, 2017, at 10:07 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

I think that would require a new consensus call. There was a lot of work done to get to the point of agreeing on a path forward at the last IETF, and this path would be rather different than that.

> permit "home." to be removed from code.

/chair-hat-off

I don’t think we want to have two defaults in our specs. It’s bad enough that we are already going to end up with .home and .homenet depending on the version of code used or forked from, I really don’t want to do anything that could lead to a third if we can avoid it.

- Mark

---

From: Brian Dickson <[email-masked]>
Date: Wed, 29 Mar 2017 23:41:00 -0500

On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <[email-masked]> wrote:

> I think that would require a new consensus call. There was a lot of work
> done to get to the point of agreeing on a path forward at the last IETF,
> and this path would be rather different than that.
>
> I don’t think we want to have two defaults in our specs. It’s bad enough
> that we are already going to end up with .home and .homenet depending on
> the version of code used or forked from, I really don’t want to do anything
> that could lead to a third if we can avoid it.
>
> - Mark
>

Taking a STRICTLY devil's advocate position here:

Isn't it the case that the thing that knows what the <homenet> label is,
should be able to masquerade on behalf of anything that isn't aware of the
divergence of the three possible values for <homenet>? If you end up with
some boxes thinking it is ".home", some ".homenet", and some
".homenet.arpa", as long as one of them knows about all three, it should be
possible to resolve the differences.

The scope of the namespace is "the home network", and never reaches the
real DNS (roots), so at worst it would be folding the three fake namespaces
into a unified (three-headed) fake namespace.

I.e. avoid it if you can, but if you can't, I think the issues are
solvable, even if they get a little funky/ugly under the hood.

None of that should be visible to users, I don't think.

Brian

P.S. Guide to implementers - never expose multiple handles for the same
object; over-exuberant users may be tempted to try to "clean up" the
duplicates.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Mar 2017 16:20:05 +1100

In message <[email-masked]>, Brian Dickson writes:
> > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> <[email-masked]>
> > wrote:
> > >
> > >
> ".homenet.arpa", as long as one of them knows about all three, it should
> be possible to resolve the differences.
>
> real DNS (roots), so at worst it would be folding the three fake
> namespaces into a unified (three-headed) fake namespace.

Can we please stop with this "and never reaches the real DNS (roots)"
garbage.  Queries for homenet/DS *will* reach the roots.  That is
how DNSSEC validation is designed to work.  They *need* to be
answered with a signed NOERROR NODATA response.  Lots of Linux
distributions ship with DNSSEC validation enabled for on machine
clients and they are also configured to forward to the nameservers
that are returned by DHCP.

These machines behave *exactly* like a validating stub resolver from
the DNSSEC perspective.  This isn't something that will be in the
future.  It is the PRESENT.

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Mar 2017 12:54:50 -0500

Mark,

When I say, "never reaches the roots", this is what I mean:
Resolution of "example.<homenet-label>" is, by design, intercepted by
homenet resolvers, and never reaches the outside world.
Do you concur with this statement?

Please stop conflating the issue of "the homenet namespace is local" (and
thus not resolvable from outside starting at the DNS root) from the issue
of the need for an insecure delegation IF homenet end systems do their own
DNSSEC validation AND those same end systems don't special-case homenet
from validation AND IF homenet is not signed with a separate trust anchor.

Yes, IF validating stubs need to confirm the unsigned nature of homenet,
THEN there is a need for retrieving the appropriate DNSSEC proof showing
that there is a delegation out of the chain of trust anchored at the DNS
root.

What that proof looks like is dependent on the issue under discussion,
which is what the domain name for homenet should be, and why.

If the domain for homenet is "homenet." anchored in the root zone, then
yes, "homenet/DS" will need to be obtained (or more correctly,
"homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along
with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN
root trust anchor).

If the domain for homenet is something else, such as "homenet.arpa.", then
the proof contains more elements, such as the DS for arpa, and the NSEC for
homenet.arpa (proving no homenet.arpa/DS exists).

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Mar 2017 18:05:14 +0000

> Do you concur with this statement?

i'm not mark, but i'd like to speak on a related topic.

by design, queries that result in RFC 1918 addresses, and queries for RFC 1918 
PTR names, were to be intercepted by local resolvers.

let me know if you can't access DNS-OARC's DITL archives, which will show you 
how prominent both kinds those queries loom in actual root name service load.

i predict that foo.bar.<homenetlabel> will do likewise, whatever its design. 
this is the one saving grace in asking for a real root zone delegation: we can 
add an NS pointing to localhost, and try to get subsequent queries to go to 
heck rather than to the root servers.

vixie

---

From: Steve Crocker <[email-masked]>
Date: Thu, 30 Mar 2017 14:11:00 -0400

On the other hand, might there be value in seeing how much errant traffic goes to the root so it can be reported and used to inform vendors, network architects, network administrators, et al?

Given the amount of bogus traffic already goes to the root, I’m not immediately worried this will increase the traffic level to a point of concern.

And I remain puzzled as to why a simple NXDOMAIN response from the root isn’t exactly the right thing and why it matters whether it’s signed or not.

Steve

> On Mar 30, 2017, at 2:05 PM, Paul Vixie <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Mar 2017 18:21:34 +0000

On Thursday, March 30, 2017 6:11:00 PM GMT Steve Crocker wrote:
> On the other hand, might there be value in seeing how much errant traffic
> goes to the root so it can be reported and used to inform vendors, network
> architects, network administrators, et al?

it seems unlikely to me that any of them would care. they didn't for RFC 1918, 
and i did try, for years, before DNS-OARC existed, using f-root trace data.

> Given the amount of bogus traffic already goes to the root, I’m not
> immediately worried this will increase the traffic level to a point of
> concern.

that's what we've said about every other incremental increase. some day we 
will reach a tipping point and be wrong. i think if we know that dreck is 
coming, we should prepare for it, perhaps with an NS RR pointing to the AS112 
project, whose operators are ready to share data with researchers on request.

perversely, the ~90+% garbage we receive helps motivate overprovisioning, and 
helps ensure that when some server is down, its impact (less than 10% of load 
that should be answered) is statistically spread out across a large amount of 
dreck. if only good queries made it to the roots, then the statisticaly 
likelihood of not being able to answer one that mattered, would be higher. 
it's a congestion-based form of forward error correction, i suppose.

> And I remain puzzled as to why a simple NXDOMAIN response from the root
> isn’t exactly the right thing and why it matters whether it’s signed or
> not.

nxdomain isn't cached by everyone who should, and of those who cache it, 
nxdomain doesn't stop downward cache traversal everywhere (which it should), 
and in any case nxdomain covers the full qname and so would only stop 
traversals through a full (foo.bar.<homenetlabel>) qname, which is why we need 
query-minimization (which would permit queries for just <homenetlabel> or 
perhaps <onelabel>.<homenetlabel>) whose cached nxdomains would have a broader 
impact (if they stopped traversal and if they are cached at all.)

executive summary: the dns works at all, and we love that, but it's not happy 
and it's not healthy and it's never going to be.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Mar 2017 05:21:19 +1100

In message <[email-masked]>, Brian Di
> Do you concur with this statement?

Yes, but that isn't the complete picture.  "never" doesn't mean "most of the
time".  "never" means "never".
 
> from validation AND IF homenet is not signed with a separate trust anchor.

I want RFC 4035 compliant validating systems to be able to resolve
local names with the default homenet domain name when they are
connected to a homenet. That cannot happen without there being a
insecure delegation in the global namespace that breaks the DNSSEC
chain of trust.  Additionally the chosen name MUST exist in the
global namespace to avoid QNAME minimisation issues.

> which is what the domain name for homenet should be, and why.

RFC 4035 states what that proof needs to look like.  That proof needs to
exist at whatever name is chosen.

> > > > >> B) seek a .homenet special use domain WITHOUT the delegation reque=
> st
> > > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN=
> N
> > > > I don=E2=80=99t think we want to have two defaults in our specs. It=
> =E2=80=99s bad
> > enough
> > > > the version of code used or forked from, I really don=E2=80=99t want =
> to do
> > anything
> > > Isn't it the case that the thing that knows what the <homenet> label is=
> ,
> > > divergence of the three possible values for <homenet>? If you end up wi=
> th
> > > ".homenet.arpa", as long as one of them knows about all three, it shoul=
> d
> --001a113ec618c0ed6c054bf663af
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Mark,<div><br><div><div>When I say, &quot;never reaches th=
> e roots&quot;, this is what I mean:</div><div>Resolution of &quot;example.&=
> lt;homenet-label&gt;&quot; is, by design, intercepted by homenet resolvers,=
>  and never reaches the outside world.=C2=A0</div><div>Do you concur with th=
> is statement?</div></div><div><br></div><div>Please stop conflating the iss=
> ue of &quot;the homenet namespace is local&quot; (and thus not resolvable f=
> rom outside starting at the DNS root) from the issue of the need for an ins=
> ecure delegation IF homenet end systems do their own DNSSEC validation AND =
> those same end systems don&#39;t special-case homenet from validation AND I=
> F homenet is not signed with a separate trust anchor.</div><div><br></div><=
> div>Yes, IF validating stubs need to confirm the unsigned nature of homenet=
> , THEN there is a need for retrieving the appropriate DNSSEC proof showing =
> that there is a delegation out of the chain of trust anchored at the DNS ro=
> ot.</div><div><br></div><div>What that proof looks like is dependent on the=
>  issue under discussion, which is what the domain name for homenet should b=
> e, and why.</div><div><br></div><div>If the domain for homenet is &quot;hom=
> enet.&quot; anchored in the root zone, then yes, &quot;homenet/DS&quot; wil=
> l need to be obtained (or more correctly, &quot;homenet/NSEC&quot; proving =
> no DS exists), signed by the ZSK of the root, along with the signed DNSKEY =
> set (signed by the KSK of the root, i.e. the ICANN root trust anchor).</div=
> ><div><br></div><div>If the domain for homenet is something else, such as &=
> quot;homenet.arpa.&quot;, then the proof contains more elements, such as th=
> e DS for arpa, and the NSEC for homenet.arpa (proving no homenet.arpa/DS ex=
> ists).</div><div><br></div><div>Brian</div></div></div><div class=3D"gmail_=
> extra"><br><div class=3D"gmail_quote">On Thu, Mar 30, 2017 at 12:20 AM, Mar=
> k Andrews <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_q=
> uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
> x"><div class=3D"HOEnZb"><div class=3D"h5"><br>
> In message &lt;<a href=3D"mailto:CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__%=
> [email-masked]">CAH1iCiozhJ3CxRDXh8R1kfv40SZv<wbr>A2MqPmsstx__+=
> 34BRowwUw@mail.<wbr>gmail.com</a>&gt;, Brian Dickson writes:<br>
> &gt; On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley &lt;<a href=3D"mailto:m=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; On Mar 29, 2017, at 10:07 AM, Michael Richardson<br>
> &gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</=
> a>&gt;<br>
> &gt; &gt; wrote:<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Terry Manderson &lt;<a href=3D"mailto:terry.manderson@icann.=
> org">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt; &gt;&gt; B) seek a .homenet special use domain WITHOUT the delega=
> tion request<br>
> &gt; &gt; &gt;&gt; AND ask the IETF/IESG/IAB to commence the discussion wit=
> h the ICANN<br>
> &gt; &gt; &gt;&gt; community to achieve an insecure delegation<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;&gt; c) seek a &lt;SOMETHING&gt;.arpa insecure special use de=
> legation<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;&gt; d) go for &quot;B&quot; and if that doesn&#39;t work shi=
> ft to &quot;C&quot;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Is there some reason we can not proceed with &quot;C&quot;, =
> concurrently with (B).<br>
> &gt; &gt;<br>
> &gt; &gt; I think that would require a new consensus call. There was a lot =
> of work<br>
> &gt; &gt; done to get to the point of agreeing on a path forward at the las=
> t IETF,<br>
> &gt; &gt; and this path would be rather different than that.<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; This might cause stub resolvers to have to have two cases<br=
> >
> &gt; &gt; &gt; (SOMETHING.arpa, and .homenet) eventually, but at least we c=
> ould deploy<br>
> &gt; &gt; &gt; and attempt interop with SOMETHING.arpa NOW, and it would mo=
> re clearly<br>
> &gt; &gt; &gt; permit &quot;home.&quot; to be removed from code.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; /chair-hat-off<br>
> &gt; &gt;<br>
> &gt; &gt; I don=E2=80=99t think we want to have two defaults in our specs. =
> It=E2=80=99s bad enough<br>
> &gt; &gt; that we are already going to end up with .home and .homenet depen=
> ding on<br>
> &gt; &gt; the version of code used or forked from, I really don=E2=80=99t w=
> ant to do anything<br>
> &gt; &gt; that could lead to a third if we can avoid it.<br>
> &gt; &gt;<br>
> &gt; &gt; - Mark<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; Taking a STRICTLY devil&#39;s advocate position here:<br>
> &gt;<br>
> &gt; Isn&#39;t it the case that the thing that knows what the &lt;homenet&g=
> t; label is,<br>
> &gt; should be able to masquerade on behalf of anything that isn&#39;t awar=
> e of the<br>
> &gt; divergence of the three possible values for &lt;homenet&gt;? If you en=
> d up with<br>
> &gt; some boxes thinking it is &quot;.home&quot;, some &quot;.homenet&quot;=
> , and some<br>
> &gt; &quot;.homenet.arpa&quot;, as long as one of them knows about all thre=
> e, it should<br>
> &gt; be possible to resolve the differences.<br>
> &gt;<br>
> &gt; The scope of the namespace is &quot;the home network&quot;, and never =
> reaches the<br>
> &gt; real DNS (roots), so at worst it would be folding the three fake<br>
> &gt; namespaces into a unified (three-headed) fake namespace.<br>
> <br>
> </div></div>Can we please stop with this &quot;and never reaches the real D=
> NS (roots)&quot;<br>
> garbage.=C2=A0 Queries for homenet/DS *will* reach the roots.=C2=A0 That is=
> <br>
> how DNSSEC validation is designed to work.=C2=A0 They *need* to be<br>
> answered with a signed NOERROR NODATA response.=C2=A0 Lots of Linux<br>
> distributions ship with DNSSEC validation enabled for on machine<br>
> clients and they are also configured to forward to the nameservers<br>
> that are returned by DHCP.<br>
> <br>
> These machines behave *exactly* like a validating stub resolver from<br>
> the DNSSEC perspective.=C2=A0 This isn&#39;t something that will be in the<=
> br>
> future.=C2=A0 It is the PRESENT.<br>
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> &gt; I.e. avoid it if you can, but if you can&#39;t, I think the issues are=
> <br>
> &gt; solvable, even if they get a little funky/ugly under the hood.<br>
> &gt;<br>
> &gt; None of that should be visible to users, I don&#39;t think.<br>
> &gt;<br>
> &gt; Brian<br>
> &gt;<br>
> &gt; P.S. Guide to implementers - never expose multiple handles for the sam=
> e<br>
> &gt; object; over-exuberant users may be tempted to try to &quot;clean up&q=
> uot; the<br>
> &gt; duplicates.<br>
> <br>
> </div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<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>
> </font></span></blockquote></div><br></div>
> 
> --001a113ec618c0ed6c054bf663af--

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 14:52:22 -0500

> And I remain puzzled as to why a simple NXDOMAIN response from the root isn’t exactly the right thing and why it matters whether it’s signed or not.

Because DNSSEC.   A validating stub will see a proof of nonexistence and ignore anything the local recursive resolver offers.