Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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 wrote: > 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, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message <4195dba6-6eae-45ce-ad61-9236c6212...@google.com>, james woodyatt wr ites: > > On Dec 15, 2016, at 06:35, Ted Lemon wrote: > > [Mark Andrews wrote:] > > 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. > > 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 > --james woodyatt mailto:j...@google.com>> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message , Ted Lemon writes: > --001a11411ef6886b910543b361bc > Content-Type: text/plain; charset=UTF-8 > > > > > 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. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
> > 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
> 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message , "John R Levine" writes:
> > 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.
>
> 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.
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
> R's,
> John
>
> >> 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.
>
> 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.
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message , Ted Lemon writes: > > 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. Why shouldn't a iterative resolver work if we can make it work? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message , Brian Dickson writes: > > On Wed, Dec 14, 2016 at 6:37 PM, Ted Lemon wrote: > > > 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. > > > > 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 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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 < brian.peter.dick...@gmail.com> wrote: > On Wed, Dec 14, 2016 at 6:37 PM, Ted Lemon wrote: > >> 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. >> > > 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 > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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. 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 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
On Wed, Dec 14, 2016 at 6:37 PM, Ted Lemon wrote: > 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. > 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message
, Brian Dickson writes:
>
> On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote:
>
> >
> > In message > gmail.com>
> > , Brian Dickson writes:
> > >
> > > On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote:
> > >
> > > > On Dec 14, 2016, at 5:04 PM, John Levine wrote:
> > > >
> > > > 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.
> > > >
> > > > [etc]
> > > >
> > > >
> > > > 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
> >
> > 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.
> >
>
> 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
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 I
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
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. On Wed, Dec 14, 2016 at 8:24 PM, John R Levine wrote: > On Wed, 14 Dec 2016, Ted Lemon wrote: > >> That is precisely why we need an unsecured delegation. >>> >>> 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 > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote: > > In message gmail.com> > , Brian Dickson writes: > > > > On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote: > > > > > On Dec 14, 2016, at 5:04 PM, John Levine wrote: > > > > > > 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. > > > > > > [etc] > > > > > > > > > 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 > > 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. > 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. > > 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. > 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 > > Mark > > > 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). > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mai
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
>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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
On Wed, 14 Dec 2016, Ted Lemon wrote: That is precisely why we need an unsecured delegation. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message , Brian Dickson writes: > > On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote: > > > On Dec 14, 2016, at 5:04 PM, John Levine wrote: > > > > 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. > > > > [etc] > > > > > > 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 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 > 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). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
application, for .local it's handled by mDNS, and for .localhost it's 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. 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, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote: > On Dec 14, 2016, at 5:04 PM, John Levine wrote: > > 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. > > [etc] > > > 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). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
On Dec 14, 2016, at 5:04 PM, John Levine wrote: > 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. > [etc] That is precisely why we need an unsecured delegation. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
In message <20161214220428.1688.qm...@ary.lan>, "John Levine" writes: > >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. 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 > ways one could do it, e.g., a .onion proxy on a LAN could intercept > 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 > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
>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 > 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. But still: >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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"
>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 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
