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

[Mark Andrews <[e-mail]>]

In message <CAH1iCioPZiO78j478BV7t=[e-mail]>
, Brian Dickson writes:
> 
> On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon <[e-mail]> wrote:
> 
> > On Dec 14, 2016, at 5:04 PM, John Levine <[e-mail]> 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: [phone]                 INTERNET: [e-mail]