Subject: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt

From: [email-masked]
Date: Tue, 08 Aug 2017 15:31:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

        Title           : Special Use Domain 'home.arpa.'
        Authors         : Pierre Pfister
                          Ted Lemon
	Filename        : draft-ietf-homenet-dot-11.txt
	Pages           : 9
	Date            : 2017-08-08

Abstract:
   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for names ending with
   '.home.arpa.', and designates this domain as a special-use domain
   name. 'home.arpa.' is designated for non-unique use in residential
   home networks.  Home Networking Control Protocol (HNCP) is updated to
   use the 'home.arpa.' domain instead of '.home'.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-dot-11
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Aug 2017 18:33:33 -0400

I updated homenet-dot with the change that Mark requested regarding signed, unsigned and insecure delegations.   I believe the text is correct now, but would appreciate a sanity check.   Otherwise, I think it's up to the chairs to make the next move.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Aug 2017 13:17:22 +1000

In message <[email-masked]>, Ted Lemon writes:
> I updated homenet-dot with the change that Mark requested regarding
> signed, unsigned and insecure delegations.   I believe the text is
> correct now, but would appreciate a sanity check.   Otherwise, I think
> it's up to the chairs to make the next move.

I would explictly list DS home.arpa as a exception.  (I had to file
a bug report against recursive server that failed to have this
exception this week for AS112 zones.  The bug has been fixed.)  Also
I wouldn't be using '.home.arpa.' as we also want to stop queries
for 'home.arpa' leaving the home.  There are a couple of references
to '.home.arpa'.

e.g.

Old:
   DNS queries for names ending with '.home.arpa.' are resolved using
   local resolvers on the homenet.  Such queries MUST NOT be recursively
   forwarded to servers outside the logical boundaries of the homenet.

New:
   DNS queries for names ending with 'home.arpa.' are resolved using
   local resolvers on the homenet.  Such queries MUST NOT be recursively
   forwarded to servers outside the logical boundaries of the homenet with
   the exception of DS lookups for 'home.arpa.'.

Mark

-- 
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, 9 Aug 2017 11:53:42 -0400

What does forwarding DS lookups for home.arpa out of the homenet do?   That
is, suppose I implement a cache that doesn't do this: what bad thing
happens?   It's going to return NXDOMAIN, right?   Isn't it the NSEC
lookups that have to succeed, and the NS record lookup?   And doesn't the
NS record have to be forged?

I think this actually means that it does have to be an unsigned delegation.
  Argh.

Hm, thinking farther, no, it doesn't, because it's okay to return the right
answer for the delegation as long as the stub resolver is willing to rely
on the cache, which we've already specified it must do.   So what's the
failure mode that this new text prevents?  Oh, you have to look up the DS
record to get the NSEC that validates it?

(I'm leaving in all of the stuff I typed while I was thinking this through
because I'm not sure I got it right, and you can point out what I got
wrong.)

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Aug 2017 09:28:01 +1000

> NS record have to be forged?

It will return a signed NOERROR nodata responses saying that there
isn't a DS record for home.arpa but there is a delegation assuming
DO=1 is set in the query and IANA has competed setting up the
insecure delegation.  If DO=0, or there isn't a OPT record, you
still get a NOERROR nodata response but that isn't useful for
downstream validating clients.

Note for DNSSEC to work reliably all resolvers that are forwarding
queries need to be DNSSEC aware (set DO=1) and validate responses.
If they don't validate responses they will cache bad answers which
will prevent down stream validators getting good answers.  Validating
allow the forwarding resolver to reject bad answers and to try
alternate sources.

It they don't validate DNSSEC will work most of the time because
most answers you get back are actually correct and complete.

Writing a recursive server these days that doesn't support DNSSEC
should be a hanging offence. :-)

> record to get the NSEC that validates it?

Yes (proves its non existence).