Subject: Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

From: "John Levine" <[email-masked]>
Date: 14 Dec 2016 22:04:28 -0000

>Here's the reasoning:   Either your home router understands .homenet or 
>it doesn't.  If it doesn't, then your homenet shouldn't be using 
>.homenet and any .homenet lookups to the real world should fail.  If it 
>does, then it should trap .homenet queries and do with it what it will.

But it's worse than that -- if your client software does DNSSEC
validation it needs to understand that homenet is a special case and
it's OK not to validate.  This brings us to one of the knottiest parts
of special use names, which is that they're all handled differently.
For .onion, it's generally handled in a SOCKS proxy in the
application, for .local it's handled by mDNS, and for .localhost it's
special cased in the stub client library.  (There are of course other
ways one could do it, e.g., a .onion proxy on a LAN could intercept
AAAA lookups, and return link-local addresses it serves.)

One model is that DNSSEC is so complex that applications depend on the
cache and if it sets the AD bit, you trust the result.  Another is
that memory is cheap and you put a complete DNSSEC verifier in the
application libraries, so they need to get all of the DNSSEC goop and
decide for themselves whether they believe it.

In the former model, you're right, the cache can tell virtuous lies
about .homenet addresses and there's no need to put anything in the
root.  In the latter case, you're pretty much schrod.  Since there's
no way to do a DNSSEC chain from the root to a zillion random homenet
setups, an unsigned root delegation says that an unsigned result isn't
necessarily wrong, but of course it doesn't say that it's right,
either.

This is a situation that DNSSEC wasn't set up to solve, unless you're
going to wave your hands and invent some sort of DHCP extension where
the router can hand out local trust anchors.  I realize we have RFC
3318, but I don't get the impression that this is a scenario it can
handle without implausible amounts of manual preconfiguration just
to get your mobile phone on your home wifi.

So having said all this, I agree with Steve that an unsigned delegation
is a bad idea, not because all unsigned delegations are necessarily
bad, but because this one wouldn't solve enough problems to be worth
the ugly and ambiguous precedent it'd set.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2016 22:13:25 -0000

>AAAA lookups, and return link-local addresses it serves.)

Forgot to mention: homenet is a fourth model, special cased in the
cache, which is an occasional but I think infrequent alternate
implementation for .localhost.  There's implicitly a fifth for
.example, .test, and .invalid which are expected to get a normal
NXDOMAIN.  

I expect when the next 6761 candidate comes along, it'll be handled in
yet another grotty way.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 11:02:56 +1100

In message <[email-masked]>, "John Levine" writes:
> special cased in the stub client library.

But it isn't.  Go read the library code.  There isn't magic for
localhost in there. The code looks in /etc/hosts before looking in
the DNS (normally) if there is a gethostbyname/getaddrinfo etc.
call.  This allows the administrator to override the DNS for specific
names on this machine for those calls.  This makes "telnet localhost"
work.  It doesn't make lots of other stuff that should work succeed.

.localhost needs the same treatment as .homenet.  It doesn't get
it today but it should for the same reason .homenet needs a insecure
delegation.

> (There are of course other
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 19:09:09 -0500

On Dec 14, 2016, at 5:04 PM, John Levine <[email-masked]> wrote:
> it's OK not to validate.
> [etc]

That is precisely why we need an unsecured delegation.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 16:43:52 -0800

> That is precisely why we need an unsecured delegation.

I agree that in the current world, an unsigned delegation is required.

I would humbly suggest that use of an AS112-like set of well-known names
and IP addresses, would be the preferred way of DOING that delegation.

A well-known address set would allow homenet-aware devices to be pre-loaded
with the address of the NS, while non-aware would learn it through the
delegation.

If it were possible to have the names be served by root servers (as a
consequence of being in the set of domains served by the root servers),
then the glue data would be signed and validate-able, which is about as
good as you can get (security-wise), while making homenet strictly local.

(Within a given homenet, the well known IP(s) could be handled via anycast
or similar mechanisms, presuming the homenet mechanisms support things like
that.)

My personal recommendation would be non-RFC-1918 well known addresses.

This ensures that for queries that leak from non-1918 space sourced
queries, that the delegation is to an address that is guaranteed to be
reachable, even if the local set-up is badly broken.

That IP would be configured to give itself as the answer to any query, and
be configured to provide (rate-limed) HTTP (wild-card) responses,
that serve up the RFC for how to set up homenet. (If that RFC doesn't
exist, that really should be next on the WG milestones.)

All roads would then lead to the answer to the question, which is, "How do
I get this stuff to work?".

Brian

PS For the DNSSEC-aware humans:

I think this exposes an unforeseen edge case, not covered in the design of
DNSSEC.

I think what would have been ideal, would have been the ability to securely
delegate to a well-known name/address, but without a secure entry point.
I.e. where parent/child NS use different RRTYPEs, and the parent NS is
signed (along with glue), and there is no DS.

The child could exist as an island of security, and have a self-signed
DNSKEY (or KSK/ZSK pair).

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 19:48:08 -0500

> work.  It doesn't make lots of other stuff that should work succeed.

I'd say that's special case, since nearly every /etc/hosts I've looked at 
only conains an entry for localhost, and perhaps a useless 255.255.255.255 
for broadcasthost.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 12:18:03 +1100

In message <CAH1iCioPZiO78j478BV7t=[email-masked]>
> I get this stuff to work?".

Why is this any better than a referral to the existing root servers
and a empty locally served .homenet zone with the previously mentioned
constraint of only enabling it when the namespace is not being
forwarded.  We do this for all the default local zones so this will
just be a extra name in the list of empty local zones that are
automatically configured.  A 5 minute job to commit to all the
branches once the name is approved.  Other vendors do similar.  The
root servers will always need to be answering for homenet/DS.  The
locally served .homenet zone will stop most of the leaks for *.homenet
at the ISP level.

If there are too many leaks after 5 years (give ISPs time to deploy
the new servers) then consider a AS112 like solution but I don't
think it will be needed.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 20:24:40 -0500

On Wed, 14 Dec 2016, Ted Lemon wrote:
>> Except that as the [etc] said, it doesn't really solve the problem.

> It solves the problem of not repudiating names in the homenet.   You have
> to have a special resolver to be able to validate them.

I'm confused -- if you need a special resolver to handle .homenet anyway, 
why does it matter what's in the root?

R's,
John

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 02:52:36 +0100

> This brings us to one of the knottiest parts of special use names, which
> is that they're all handled differently.  For .onion, it's generally
> handled in a SOCKS proxy in the application, for .local it's handled by
> mDNS, and for .localhost it's special cased in the stub client library.

Let's please not bring .onion into this discussion.  .onion is a hack with
far-reaching consequences, and one that the IETF should never have
standardised.  The less we mention .onion, the better.

.onion encodes the protocol into the hostname.  Instead of .onion, tor
should have used http+tor:// and https+tor://, which would have required
no special-casing, since an application that doesn't understand the new
scheme will return an error straight away rather than leaking .onion names
into the DNS.  (I understand why .onion was used -- it was an expedient
way to avoid the need for special-case code in the browser --, but the
tradeoff that was chosen requires special-case code in every single
freaking DNS-speaking application.  Yeah, I'm still pissed off.)

Not so with .local and .homenet.  Neither of these requires any special
code in the application.  From the point of view of the application,
.local and .homenet are just ordinary domain names that are passed to the
stub resolver, which yields a perfectly normal IP(v6) address that is then
used with ICMP, TCP, UDP, DCCP (remember that?) or whatever your favourite
transport-layer protocol happens to be.  Completely unlike .onion.

Now, granted, .local and .homenet require special casing in shared parts
of the protocol stack (.local in the stub resolver, .homenet in the
Homenet router's resolver), but this needs to be done just once in the
protocol stack, not in every single application.  Completely unlike .onion.

Sorry for the rant.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 03:06:04 +0100

> requires special-case code in every single freaking DNS-speaking
> application.  Yeah, I'm still pissed off.)

Since people seem puzzled about my rant, here's the relevant quotation
from RFC 7686:

    Applications that do not implement the Tor protocol SHOULD generate an
    error upon the use of .onion and SHOULD NOT perform a DNS lookup.

RFC 7686 updates every single DNS-using application protocol, even if it
has nothing to do with tor.  Now go and fix the FTP client you wrote in
1984, it violates RFC 7686.

-- Juliusz

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2016 02:18:31 -0000

>protocol stack, not in every single application.  Completely unlike .onion.

I think you're making unwarranted assumptions about software design
here.  On the computers I know, the stub resolver is in one shared
library and the SOCKS proxy is in another.  What's the difference?

I agree that ToR users typically use specially configured browsers
to minimize side channel leakage, but that's unrelated to the way
the the sockets work.  You can run POP3 over ToR if you want to.

The somewhat relevance to the topic at hand is that we seem to have
different mental models of the way the clients work.  If we expect the
client libraries to know that .homenet is special, it doesn't matter
what's in the root.  If we expect they don't, and all the magic is in
the router, I still don't see any solutions that aren't really ugly.
If we do the unsigned delegation that Mark wants, the validating client
can tell that the .homenet answers it's getting aren't necessarily
bogus, but it can't tell that they're authentic either.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 18:22:42 -0800

> locally served .homenet zone will stop most of the leaks for *.homenet

It depends on perspective, and your definition of "better".

The homenet folks want zero configuration, want it to work, and don't want
to wait.

The difference between the scenarios are:
- How a non-aware resolver within a homenet (which has a correctly deployed
aware resolver) behaves
- How much infrastructure requires changes before the first improperly
deployed homenet gets any help
  - In your scenario, it never gets help, and leaks to the root until ISPs
and/or resolvers get changes deployed
  - In my scenario, the first instance of an upgraded AS112 node (with new
address being anycast) results in universal support, modulo available
capacity

If you only care about leaking, you are missing the point.

If you care about both leaking, *and* getting mixed environments to work,
*and* minimizing deployment support costs, you should be able to see why
this is better.

> the new servers) then consider a AS112 like solution but I don't

IMHO, this is mostly backwards. In this case, I think the AS112 would
probably need to be permanent.

But, in general, the fastest way of fixing the leaks is, deploy the leak
shield (AS112), then fix the leaks, then remove the leak shield when it is
no longer needed.

Waiting until the deluge has become a dribble, seems backwards.
(Plus, look how well that worked for spam.)

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 21:35:41 -0500

You would need a special resolver to _validate_ .homenet automatically
using a trust anchor published by the home network.   You do not need a
special resolver to look up names in the homenet without validation, if
there is an unsecured delegation at the root.   If there is a secure denial
of existence or a secure delegation at the root, then no validating
resolver can look up names in the homenet domain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 21:37:38 -0500

Brian, there's no need for the complexity you are describing.   The
unsecured delegation of .homenet would just point to AS112.   Any trust
anchor bootstrapping would not involve the root at all.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 14:20:15 +1100

In message <CAH1iCir6R=[email-masked]>
> address being anycast) results in universal support, modulo available

Add this or the equivalent to each root server.

zone homenet {
	file "homenet.db";
	masters { icann's servers; };
	type slave;
};

homenet.db:
HOMENET. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016121401 1800 900 604800 86400
HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

and add the following to the root zone

HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

verses

* getting new IPv4 and IPv6 address blocks for the new anycast servers.
* configuring them to serve the zone.
* getting the prefixes for these servers announced world wide.
* getting the insecure delegation into the root zone as it is still needed.

	HOMENET. 86400 IN NS SOME.NEW.SERVER.
	HOMENET. 86400 IN NS ANOTHER.NEW.SERVER.

* adding the new addresses to the every homenet router since you don't
  want to follow the delegation from the root servers.

In what world is the second senario faster or less work than the first?

Just bringing up undelegated servers for HOMENET does not help is
any way what so ever.  A homenet aware router will not talk to them
ever as it is authoritative for HOMENET or knows the servers that
are authoritative via HNCP and will direct HOMENET queries there
other than for HOMENET/DS which will be directed to the rootserver
(directly or indirectly).  If the domain advertised in via HNCP is
not HOMENET it still configures itself as authoritative for HOMENET
with a empty zone to catch leaks from roaming devices.  A non homenet
aware router will not talk to them ever as they are not delegated
too.

> *and* minimizing deployment support costs, you should be able to see why

No.  You have not shown this.

> (Plus, look how well that worked for spam.)

There is no deluge at the moment.  There should not be a deluge in
the future as HOMENET routers don't leak HOMENET lookups and HOMENET
aware name servers don't leak HOMENET queries as they self configure
to serve HOMENET.  The delay is to give time to allow ISPs to deploy
HOMENET aware servers.

This is not RFC 1918 where there were just instructions to "don't
leak".  In this case we are deploying software that actively stops
leaks by default.

Mark

> --001a11467d66e3e63d0543a920b7
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
> te">On Wed, Dec 14, 2016 at 5:18 PM, Mark 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_quote" style=3D"margin:0 0 0 .8ex;bo=
> rder-left:1px #ccc solid;padding-left:1ex"><br>
> In message &lt;CAH1iCioPZiO78j478BV7t=3D<a href=3D"mailto:pTN9LZXQbweeBZQF2=
> [email-masked]">pTN9LZ<wbr>XQbweeBZQF2w3O1gKwx3XA@mail.<wbr>gma=
> il.com</a>&gt;<br>
> <div><div class=3D"h5">, Brian Dickson writes:<br>
> &gt;<br>
> &gt; On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon &lt;<a href=3D"mailto:mello=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt; On Dec 14, 2016, at 5:04 PM, John Levine &lt;<a href=3D"mailto:jo=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; But it&#39;s worse than that -- if your client software does DNSS=
> EC<br>
> &gt; &gt; validation it needs to understand that homenet is a special case =
> and<br>
> &gt; &gt; it&#39;s OK not to validate.<br>
> &gt; &gt;<br>
> &gt; &gt; [etc]<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; That is precisely why we need an unsecured delegation.<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; I agree that in the current world, an unsigned delegation is required.=
> <br>
> &gt;<br>
> &gt; I would humbly suggest that use of an AS112-like set of well-known nam=
> es<br>
> &gt; and IP addresses, would be the preferred way of DOING that delegation.=
> <br>
> &gt;<br>
> &gt; A well-known address set would allow homenet-aware devices to be pre-l=
> oaded<br>
> &gt; with the address of the NS, while non-aware would learn it through the=
> <br>
> &gt; delegation.<br>
> &gt;<br>
> &gt; If it were possible to have the names be served by root servers (as a<=
> br>
> &gt; consequence of being in the set of domains served by the root servers)=
> ,<br>
> &gt; then the glue data would be signed and validate-able, which is about a=
> s<br>
> &gt; good as you can get (security-wise), while making homenet strictly loc=
> al.<br>
> &gt;<br>
> &gt; (Within a given homenet, the well known IP(s) could be handled via any=
> cast<br>
> &gt; or similar mechanisms, presuming the homenet mechanisms support things=
>  like<br>
> &gt; that.)<br>
> &gt;<br>
> &gt; My personal recommendation would be non-RFC-1918 well known addresses.=
> <br>
> &gt;<br>
> &gt; This ensures that for queries that leak from non-1918 space sourced<br=
> >
> &gt; queries, that the delegation is to an address that is guaranteed to be=
> <br>
> &gt; reachable, even if the local set-up is badly broken.<br>
> &gt;<br>
> &gt; That IP would be configured to give itself as the answer to any query,=
>  and<br>
> &gt; be configured to provide (rate-limed) HTTP (wild-card) responses,<br>
> &gt; that serve up the RFC for how to set up homenet. (If that RFC doesn&#3=
> 9;t<br>
> &gt; exist, that really should be next on the WG milestones.)<br>
> &gt;<br>
> &gt; All roads would then lead to the answer to the question, which is, &qu=
> ot;How do<br>
> &gt; I get this stuff to work?&quot;.<br>
> &gt;<br>
> &gt; Brian<br>
> <br>
> </div></div>Why is this any better than a referral to the existing root ser=
> vers<br>
> and a empty locally served .homenet zone with the previously mentioned<br>
> constraint of only enabling it when the namespace is not being<br>
> forwarded.=C2=A0 We do this for all the default local zones so this will<br=
> >
> just be a extra name in the list of empty local zones that are<br>
> automatically configured.=C2=A0 A 5 minute job to commit to all the<br>
> branches once the name is approved.=C2=A0 Other vendors do similar.=C2=A0 T=
> he<br>
> root servers will always need to be answering for homenet/DS.=C2=A0 The<br>
> locally served .homenet zone will stop most of the leaks for *.homenet<br>
> at the ISP level.<br></blockquote><div><br></div><div>It depends on perspec=
> tive, and your definition of &quot;better&quot;.</div><div><br></div><div>T=
> he homenet folks want zero configuration, want it to work, and don&#39;t wa=
> nt to wait.</div><div><br></div><div>The difference between the scenarios a=
> re:</div><div>- How a non-aware resolver within a homenet (which has a corr=
> ectly deployed aware resolver) behaves</div><div>- How much infrastructure =
> requires changes before the first improperly deployed homenet gets any help=
> </div><div>=C2=A0 - In your scenario, it never gets help, and leaks to the =
> root until ISPs and/or resolvers get changes deployed</div><div>=C2=A0 - In=
>  my scenario, the first instance of an upgraded AS112 node (with new addres=
> s being anycast) results in universal support, modulo available capacity</d=
> iv><div><br></div><div>If you only care about leaking, you are missing the =
> point.</div><div><br></div><div>If you care about both leaking, *and* getti=
> ng mixed environments to work, *and* minimizing deployment support costs, y=
> ou should be able to see why this is better.</div><div>=C2=A0</div><blockqu=
> ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
> olid;padding-left:1ex">
> <br>
> If there are too many leaks after 5 years (give ISPs time to deploy<br>
> the new servers) then consider a AS112 like solution but I don&#39;t<br>
> think it will be needed.<br></blockquote><div><br></div><div>IMHO, this is =
> mostly backwards. In this case, I think the AS112 would probably need to be=
>  permanent.</div><div><br></div><div>But, in general, the fastest way of fi=
> xing the leaks is, deploy the leak shield (AS112), then fix the leaks, then=
>  remove the leak shield when it is no longer needed.</div><div><br></div><d=
> iv>Waiting until the deluge has become a dribble, seems backwards.</div><di=
> v>(Plus, look how well that worked for spam.)</div><div><br></div><div>Bria=
> n</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">
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><span class=3D"im HOEnZb"><br>
> &gt; PS For the DNSSEC-aware humans:<br>
> &gt;<br>
> &gt; I think this exposes an unforeseen edge case, not covered in the desig=
> n of<br>
> &gt; DNSSEC.<br>
> &gt;<br>
> &gt; I think what would have been ideal, would have been the ability to sec=
> urely<br>
> &gt; delegate to a well-known name/address, but without a secure entry poin=
> t.<br>
> &gt; I.e. where parent/child NS use different RRTYPEs, and the parent NS is=
> <br>
> &gt; signed (along with glue), and there is no DS.<br>
> &gt;<br>
> &gt; The child could exist as an island of security, and have a self-signed=
> <br>
> &gt; DNSKEY (or KSK/ZSK pair).<br>
> </span><div class=3D"HOEnZb"><div class=3D"h5">--<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>
> 
> --001a11467d66e3e63d0543a920b7--

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 19:30:20 -0800

> anchor bootstrapping would not involve the root at all.

Is the intent just to have a global NXDOMAIN, provided with no DNSSEC?

That works at preventing homenet from working unless every resolver inside
the home network is homenet-aware.
(And yes, I realize as currently specified in RFC 7778, that is a
requirement.)

However, I don't believe that is only (or optimal) path for the homenet.

Their stated goal is that they want everything to work, plug-and-play.

What I'm proposing will (I believe) actually produce a working network as
long as a single resolver is homenet-aware.
It automatically gets non-homenet-aware resolvers to point at homenet-aware
resolvers (ie homenet routers), as long as the default address for homenet
routers' DNS service, is the same as the value assigned in the AS112-like
delegation.

I.e. it turns a broken hybrid of "today" networks plus a "homenet", into a
fully functional homenet with a minimum of
deployments/upgrades/replacements. It also minimizes the "broken Christmas
light" aka "missing terminator" class of problem, if any host is running
its own recursive resolver (which would then fail to properly integrate
into the homenet.)

(Also, I think having things with built-in firmware-based crappy resolvers
actually work without any patching, would be nice.)

I agree that an unsigned delegation is sufficient for non-hybrid
homenet-aware gear to provide hosts a correct homenet experience.

Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 04:49:55 +0100

> On the computers I know, the stub resolver is in one shared library and
> the SOCKS proxy is in another.  What's the difference?

The SOCKS library uses a completely different data transport (one that is
circuit-switched and layered over TCP), with very different capabilities
from the usual packet-switched transport.  Adding support for mDNS to the
stub resolver makes no change to the way the actual data is pushed around.

> You can run POP3 over ToR if you want to.

You can also run POP3 over X.25.  Shall we special-case .x25, and require
all applications to use PF_X25 instead of PF_INET6 whenever they see
a name ending in .x25?  This essentially what RFC 7686 requires for .onion.

> If we expect the client libraries to know that .homenet is special, it
> doesn't matter what's in the root.

I was under the impression that .homenet is handled entirely within the
DNS resolver of the Homenet router, which combines:

  - an authoritative DNS server for .homenet;
  - a hybrid mDNS proxy;
  - a recursive DNS resolver for the rest of the namespace.

In other words, I was assuming that we put enough Stenberg-Cheshire magic
in the Homenet router's resolver to ensure that no host changes are
necessary.  If that is not the plan, then I'd appreciate a clarification.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 23:01:26 -0500

A stub resolver is expected to query a caching resolver, not the root.   So
all that is required for this to work is that the resolver advertised on
the homenet claim authority for the zone, and that there be an unsecured
delegation that validates that the homenet resolver can give to the stub
resolver.   Stub resolvers that query the root themselves will fail.   This
is a feature--that behavior is broken.

On Wed, Dec 14, 2016 at 10:30 PM, Brian Dickson <
[email-masked]> wrote:

> It automatically gets non-homenet-aware resolvers to point at
> homenet-aware resolvers (ie homenet routers), as long as the default
> address for homenet routers' DNS service, is the same as the value assigned
> in the AS112-like delegation.
>
> fully functional homenet with a minimum of deployments/upgrades/replacements.
> It also minimizes the "broken Christmas light" aka "missing terminator"
> class of problem, if any host is running its own recursive resolver (which
> would then fail to properly integrate into the homenet.)
>

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 23:02:32 -0500

>  - a recursive DNS resolver for the rest of the namespace.

So far so good.  The problem is a (largely hypothetical at this point) 
stub resolver that wants to do DNSSEC verification of the results the 
router gives it.

R's,
John

> from the usual packet-switched transport.

Of course, but from the point of view of a SOCKS client, either way it 
gives it a name and a port, and it gets back a two-way data stream.  If 
you don't happen to be using a web proxy or ToR, the SOCKS library does 
essentially nothing.

> Adding support for mDNS to the stub resolver makes no change to the way 
> the actual data is pushed around.

Sure it does -- the .local queries do one thing and the others do another.
Not unlike with SOCKS the .onion opens do one thing and the others do 
another.  But this is utterly tangential to the argument about resolvers 
that might want to do DNSSEC validation of .homenet results.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:15:38 +1100

In message <CAH1iCirFZtCWVkMqFp8Fb=[email-masked]>
> homenet-aware gear to provide hosts a correct homenet experience.

So you want the nameservers configured to serve HOMENET to advertise
a well known prefixes (IPv4 and IPv6) into the IGP and as a result
packet routing will direct HOMENET queries to those servers.

That the publically delegated to servers also use those addresses.

I suppose this helps the case of a host using interative resolution
to find the on net homenet servers.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:19:12 +1100

> is a feature--that behavior is broken.

Why shouldn't a iterative resolver work if we can make it work?

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:35:50 +1100

> stub resolver that wants to do DNSSEC verification of the results the 

Lots of machines already do

	forwarder { list of servers from DHCP; };
	forward only;

automatically and those servers have a DNSSEC validation enabled.
This isn't a hypothetical problem.

Mark

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 14:34:17 +0100

> stub resolver that wants to do DNSSEC verification of the results the

Yes, I'm following this discussion with interest.  The only bit I object
to is bringing .onion into the discussion -- .homenet is nothing like that
particular piece of bad humour.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 09:35:57 -0500

> Why shouldn't a iterative resolver work if we can make it work?

Putting an iterative resolver in a stub resolver is an attack on the DNS
infrastructure.   If you are doing it because you are testing some theory
in an experimental jig, that's perfectly fine; in that case, you are a
consenting adult, and can configure it with a special delegation for
.homenet if you need that to work.   If you are adding it to production
code that will be installed in a billion devices, you are a vandal.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 06:54:04 +1100

In message <CAPt1N1mwoGDuc8fn7mFd0R3cx_xQLBM3H=[email-masked]>
, Ted Lemon writes:
> --001a11411ef6886b910543b361bc
> Content-Type: text/plain; charset=UTF-8
> 
> >

Please go read STD 13 and tell me where using a iterative resolver
in a application is BANNED because it is NOT there.  Iterative
resolvers in applications are part to the data flow model for DNS.
Just because MOST application will use a stub resolver doesn't make
it REQUIRED.

There is no attack of the DNS by wanting interative resolvers to
work by default.

Mark

---

From: james woodyatt <[email-masked]>
Date: Thu, 15 Dec 2016 12:10:09 -0800

On Dec 15, 2016, at 06:35, Ted Lemon <[email-masked]> wrote:
> [Mark Andrews <[email-masked]> wrote:]
> Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure.   If you are doing it because you are testing some theory in an experimental jig, that's perfectly fine; in that case, you are a consenting adult, and can configure it with a special delegation for .homenet if you need that to work.   If you are adding it to production code that will be installed in a billion devices, you are a vandal. 

I doubt any sane home gateway vendor would do this even if the DNS infrastructure were robust enough to handle it (which, hey— I thought it was supposed to be, why isn’t it?). The reason is that too many ISPs insist on enhancing the content of the public DNS with their own private horizon stuff, so that additional services they bundle to their customers will work only on their own networks. Competition! Oh and that’s before I mention the extra featurefulness that many content delivery networks are still using for selecting servers based on the source address of the iterative DNS query instead of something more meaningful.

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 07:21:11 +1100

In message <[email-masked]>, james woodyatt wr
ites:
> > Putting an iterative resolver in a stub resolver is an attack on the
> > DNS infrastructure.   If you are doing it because you are testing some
> > theory in an experimental jig, that's perfectly fine; in that case, you
> > are a consenting adult, and can configure it with a special delegation
> > for .homenet if you need that to work.   If you are adding it to
> > production code that will be installed in a billion devices, you are a
> > vandal.
>
> I doubt any sane home gateway vendor would do this even if the DNS
> infrastructure were robust enough to handle it (which, hey— I thought it
> was supposed to be, why isn’t it?). The reason is that too many ISPs
> insist on enhancing the content of the public DNS with their own private
> horizon stuff, so that additional services they bundle to their customers
> will work only on their own networks. Competition! Oh and that’s before I
> mention the extra featurefulness that many content delivery networks are
> still using for selecting servers based on the source address of the
> iterative DNS query instead of something more meaningful.

Too many people are already use third party DNS servers (Google
etc.) for ISPs to get away with this garbage anymore.  Iterative
resolvers in the CPE router just work.

The issue is more about iterative resolvers not in the CPE router.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 15 Dec 2016 15:57:18 -0500

>> Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure.

Ted might want to alert all of the BSD and linux distros that default to 
running a copy of bind or unbound answering queries on 127.0.0.1.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 16:00:20 -0500

Billions and billions of them?   How often do they query the root, do you
think, compared to a stub resolver that did recursion itself?

On Thu, Dec 15, 2016 at 3:57 PM, John R Levine <[email-masked]> wrote:

>>> infrastructure.

---

From: "John R Levine" <[email-masked]>
Date: 15 Dec 2016 16:11:37 -0500

> think, compared to a stub resolver that did recursion itself?

I have no idea, although I do know that IoT devices tend to use stripped 
down linux distros.

In any event, given that most of the root traffic is junk, I wouldn't 
think that any plausible increase in non-junk traffic would be noticable. 
Queries for TLDs cache really well.  You might want to talk to the RSSAC.

R's,
John

Regards,

---

From: william manning <[email-masked]>
Date: Fri, 16 Dec 2016 01:46:50 -0800

actually, IoT OS platforms are mostly not stripped versions of linux, most
are purpose-built, real time OS's.  One of the more popular is RIOT.   If
you look at the attacks on these OS's, you can look at Miri, the BOT which
shows lots of packet love.
Concur that you should touch base with RSSAC before deciding to punt
traffic to the root servers to reject.  The RFC 1918 leaks were bad enough
to force the development of the AS112 infrastructure to absorb that traffic
so the roots could survive.

So we can make the delegation NOW and declare it unsigned, or we can punt
(more) traffic to the roots.
Trying to get DNSSEC validation into IoT devices requires code in the end
systems...  and

Elsewhere, Mr. O'Dell said:
"Seriously, the crapware contingent squeezes every byte out of the software
in those devices, and if somebody cannot show the incremental revenue is a
lot bigger than forcing the customer to buy a new one at some point,
there's no [dnssec] in them. Remember there is a huge difference between
inexpensive and cheap, and when consumer crapware is involved, bet on cheap
every time."

Now if we want to force the functional equivalent of renal failure on the
root servers, then by all means, don't make the delegation and hope nothing
leaks out to the public Internet.

/Wm

On Thu, Dec 15, 2016 at 1:11 PM, John R Levine <[email-masked]> wrote:

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