Subject: Re: [homenet] Reverse DNS

From: Wouter Cloetens <[email-masked]>
Date: Wed, 01 Aug 2012 09:42:02 +0200

On 01/08/12 03:26, Curtis Villamizar wrote:
> Anything DNS related should be reliable.  Therefore a secondary would
> be preferable to not having one.

OTOH, the use case of a DNS lookup for a hostname or IP address for 
which the last-hop router is offline (at the time of the lookup) is limited.
It is there; e.g. batch log processing on web servers, but that is for 
informative purposes only, and doesn't cause connection failures.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Aug 2012 00:13:22 +1000

> informative purposes only, and doesn't cause connection failures.

This is crazy talk.  We have absolutely no idea what will or will
not end up being run from the home.  Whether people will need to
lookup information about the home when it is unreachable or not.
How do you debug if you can reach home or not if you can't get the
addresses of the machines at home?

The DNS was designed with the idea that there would be redundent
servers.  It is not designed to deal with not being able to connect
to any servers for a zone and it really does not work well when
this is the case.

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

---

From: Wouter Cloetens <[email-masked]>
Date: Wed, 01 Aug 2012 16:58:42 +0200

On 01/08/12 16:13, Mark Andrews wrote:
> In message<[email-masked]>, Wouter Cloetens writes:

If you need to run a reliable service, you shouldn't be running it from 
your home. The use case of homenet is restricted to that.

What you understand as "crazy talk," I see as; trying to get something 
working, in best-effort mode, taking into account the limitations of a 
home network with a CE router in front of it.
We assume that a DynDNS-style approach simply will never scale for every 
IPv6 address in the home, and therefore the home router has to be 
authoritative, handling the requests.

> to any servers for a zone and it really does not work well when

If you *are* running a service from home, there is always the option of 
setting up DynDNS specifically for those hosts that need to be accessible.

-- 
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/
http://www.linkedin.com/in/wcloetens  Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010      Mobile: +32-492-277790       Fax: +32-16-852099

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Aug 2012 11:40:45 -0400

On Wed, Aug 01, 2012 at 04:58:42PM +0200, Wouter Cloetens wrote:
> We assume that a DynDNS-style approach simply will never scale for
> every IPv6 address in the home, and therefore the home router has to
> be authoritative, handling the requests.

If I may ask, why do you make that assumption?  I assure you that Dyn
is running some very large zones with high change rates.  Now, it
might be that nobody would be willing to pay for such a service at the
rate Dyn would charge to make this profitable, assuming large numbers
of records and a high rate of change.  If that's your argument,
however, I'd like to know understand how this is going to be worth
doing for someone else when Dyn already has the sunk investment in
infrastructure.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Aug 2012 03:54:53 +1000

> your home. The use case of homenet is restricted to that.

The only real difference between home and commercial is SLA agreements
and MTR.  Home is a perfectly fine place to run some services.  Some
services can only be run from the home.  Additionally PTR records
are not the only think that gets stored in the reverse DNS.

> authoritative, handling the requests.

Actually dynamic DNS is extremely cheap and can scale to every
device.  Costs to host zones in volume are in single dollar digits
/ zone / year.  Automation reduces these costs towards the pure
hardware and comm costs which continue to drop.

---

From: Evan Hunt <[email-masked]>
Date: Wed, 1 Aug 2012 18:48:55 +0000

> home network with a CE router in front of it.

Then again, the point of this WG as I understand it is to get rid of some
of those limitations, not to accomodate or perpetuate them. :)

> authoritative, handling the requests.

You can have a router be authoritative for its own zones and also have
a reliable secondary name service elsewhere.

I run BIND 9 on my home router (netgear wndr3700 running customized 
openwrt/cerowrt, thank you Dave Taht); it's authoritative for several
zones, both forward and reverse, some of which are split into internal
and external views, and all of which are DNSSEC signed.  When any of
the zones is updated due to the addition or removal of a device, a
NOTIFY is sent to the secondary name service, which IXFRs up the
changes.  (I use ISC's SNS for this because I'm an employee and
get it for free, but there are similar inexpensive services out
there including, IIRC, a recent offering from Amazon -- and it
wouldn't be a difficult service for an ISP to offer.)

For queries originating inside my network, the router handles recursion
and will answer authoritatively when asked for a name in the site-local
namespace or in the internal view of the public namespaces.

Queries originating outside the network generally go to the secondary
servers.  If I'd wanted to, I could have configured my router to be a
hidden master, and then *all* the queries would go to the secondaries
(except for *XFR requests coming from the secondaries).

So in this model both the router and the secondary servers are
authoritative for the externally visible view of the network; the router
is solely authoritative for the internally visible view.  I don't know of
any reason this approach couldn't scale.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Aug 2012 12:36:58 -0700

> of those limitations, not to accomodate or perpetuate them. :)

Exactly.   I think that the wish for an expedient solution often ignores the fact that a step-by-step implementation of the real solution isn't as hard as the proponents of expedient solutions often fear.

Regarding the question of whether to update the primary on the CPE device or update the primary on the ISP, the main motivation in my mind for doing it on the CPE device is that it avoids a massive key management problem.   If the CPE device is primary and the ISP device is secondary, the ISP can publish a SIG(0) key in a well-known zone and use that to authenticate zone transfers.   Going the other direction requires the ISP to have a public key somewhere for every single customer.   There's nothing fundamentally hard about this, but I think the other way is easier.

Having said that, of course we should describe how to do it both ways.   I just think the CPE being primary is going to be more popular, assuming both solutions are equally well-supported.

---

From: Wouter Cloetens <[email-masked]>
Date: Wed, 01 Aug 2012 22:07:49 +0200

> doing for someone else when Dyn already has the sunk investment in

Internet of Things. Home automation. 5, 10 years from now. 10k nodes 
low-power nodes for a site. (Not unrealistic for an office building, 
I've been told).
It is sensible to have those nodes visible in the DNS, forward and 
reverse, for remote management and other reasons. You basically never, 
ever want to type in an IPv6 address.
It is not sensible to have them register themselves to DynDNS, or have 
the router register to Dyn for them.

draft-mglt-homenet-naming-delegation and 
mglt-homenet-front-end-naming-delegation provide a solution that will 
work securely, out of the box, without any end user configuration at 
all, and consuming no bandwidth if the home DNS feature is not used. The 
end user doesn't even have to register for a DynDNS account.

*That* is what this WG should be about IMO; making things scale to 
unimaginable proportions (we are designing for the next 100 years), 
simple, without any need for configuration, and without cost.

bfn, Wouter