Subject: [homenet] WGLC on draft-ietf-homenet-dot-09

From: Ray Bellis <[email-masked]>
Date: Tue, 4 Jul 2017 10:32:43 +0100

Given the relatively large number of changes in this document based on
Suzanne's review and my own, I'm starting a *one week* WGLC on this
document before it gets pushed back out to our AD again.

There was very little response to the last WGLC so there are concerns
over whether it has WG consensus.

*Please* read this version, and comment, even if it's to say "I have no
comments, please go ahead and publish".

NB: the particular string applied for (".home.arpa") is not up for
discussion again.  We've been there, done that.

thanks,

Ray

--8<--8<--

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

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

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/

--8<--8<--

---

From: <[email-masked]>
Date: Wed, 5 Jul 2017 15:46:52 +0000

Hey,

Looking for some thought from you guys. As an operator with millions of devices using .home in their Residential Gateway CPE, Im interested, does/should/could this draft provide some recommendations about how to migrate its CPE from ".home" to ".home.arpa" ?

Mal

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Ray Bellis
Sent: 04 July 2017 10:33
To: HOMENET
Subject: [homenet] WGLC on draft-ietf-homenet-dot-09

Given the relatively large number of changes in this document based on Suzanne's review and my own, I'm starting a *one week* WGLC on this document before it gets pushed back out to our AD again.

There was very little response to the last WGLC so there are concerns over whether it has WG consensus.

*Please* read this version, and comment, even if it's to say "I have no comments, please go ahead and publish".

NB: the particular string applied for (".home.arpa") is not up for discussion again.  We've been there, done that.

thanks,

Ray

--8<--8<--

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

Abstract:

--8<--8<--

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: "Walter H." <[email-masked]>
Date: Wed, 05 Jul 2017 18:20:57 +0200

One thing I have to comment to  ".home.arpa", as I have changed any 
device used in my residental home network to
use ".home.arpa" instead of ".local" or ".home", but I noticed one thing 
in connection with BIND
(I'm using just simple DNS with BIND)

I'm using DDNS and my router has there the dynamic master zones:
lets say "ddns.mynet.home.arpa" for forward DNS
and "1.168.192.in-addr.arpa" for reverse DNS;

on the second running DNS (also running BIND) which is just a VM
I could define there just a forward zone like this:

zone "1.168.192.in-addr.arpa" IN {
type forward;
forwarders { 192.168.0.1; };
forward only;
};

but with the forward zone "ddns.mynet.home.arpa" this doen't work, and I 
don't know if there are
any restrictions which shouldn't be in BIND ...

the reason for just defining a forward zone instead of slave zone on the 
second DNS is a timing thing:

at the moment a device gets registrated on the master DNS by DHCP, 
requests to the second DNS
just get forwarded to the master and so get an reply, but with a slave 
zone requests to the second DNS
get resolved a longer time later ...

and this MUST work with  ".home.arpa"  the same way as with 
"168.192.in-addr.arpa" ...

these statements:

disable-empty-zone "HOME.ARPA";
disable-empty-zone "168.192.IN-ADDR.ARPA";

work both; or do I have to give this:

disable-empty-zone "MYNET.HOME.ARPA";

in order to work properly with forward zones?

Thanks,
Walter

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jul 2017 13:14:40 -0400

> Looking for some thought from you guys. As an operator with millions of devices using .home in their Residential Gateway CPE, Im interested, does/should/could this draft provide some recommendation…

I think this is out of scope for this document.   My personal advice, worth what you paid, is that you not change anything until you have a positive reason to do so: don't change it just because this document says to change it.   What would motivate changing it would be if ICANN allocates the name in some future gTLD process.   At present they seem to believe that it would cause too many problems, but that could change: there are definitely organizations that would like to have the name.

Until the delegation is installed by the IAB, I think it's too soon to consider using 'home.arpa.'

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 5 Jul 2017 14:51:16 -0400

> On Jul 5, 2017, at 1:14 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Jul 5, 2017, at 11:46 AM, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:

FWIW, I’m not sure I fully agree with this definition of relevant changes, particularly if you care about DNSSEC.

There is not now, and IMO there is not likely ever to be, an unsigned delegation in the root zone for .home to enable local DNSSEC resolution.

There is not now, but likely soon to be (although Ted’s right the relevant request hasn’t been made yet) an unsigned delegation in the .arpa zone for .home.arpa to enable local DNSSEC resolution.

An interest in DNSSEC would argue for changing such names as soon as the .home.arpa delegation is in place.

Suzanne

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jul 2017 17:18:59 -0400

> An interest in DNSSEC would argue for changing such names as soon as the .home.arpa delegation is in place.

Yes, but BT has a rather large ops issue to contend with, and the DNSSEC issue is (I presume) not causing any difficulty now, nor is it likely to in the short term.   Waiting until the delegation is present seems like a safer bet than just making the switch now.   The DNSSEC issue, which I agree is important in the long run, is not likely to cause any operational problem in the short run.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Jul 2017 14:19:00 +1000

> get resolved a longer time later ...

If you have properly configured the zone / named on the master a
NOTIFY message will be sent to the slave server which will trigger
a zone refresh and subsequent update.  This is actually the fastest
way to get new content to the other servers as you don't have to
wait for old content to expire from the cache.

Named uses the NS RRset for the zone to determine where to send
NOTIFY messages.  It can also be configured to sent NOTIFY messages
to other servers (see also-notify).

Forwarding is only "fast" for records that are not already cached.

> disable-empty-zone "168.192.IN-ADDR.ARPA";

These are not needed if you are using a zone declarations (forward
must be "forward only;") for ddns.mynet.home.arpa and
1.168.192.IN-ADDR.ARPA.  Named will create the empty zones with
dummy delegations for ddns.mynet.home.arpa and 1.168.192.IN-ADDR.ARPA.
("1.168.192.IN-ADDR.ARPA. NS ." and "ddns.mynet.home.arpa. NS .")
This ensures that mynet.home.arpa returns a ENT and that DS lookup
return NOERROR NODATA for ddns.mynet.home.arpa and 1.168.192.IN-ADDR.ARPA
rather than NXDOMAIN.

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Jul 2017 14:23:23 +1000

Note also home.arpa will be problematical until the insecure
delegation for it is made if you are validating.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 7 Jul 2017 10:39:34 +0100

The WGLC on this is due to run out next Tuesday.

We've had a couple of comments, but we still need more people to confirm
that they've read it and are happy for it to leave the WG.

thanks,

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jul 2017 08:34:05 -0400

Hi there,

I have read the -09 draft.  I think I am confused (but maybe I am
confused about that).

It says

   5.  No special processing of '.home.arpa' is required for
       authoritative DNS server implementations.  However, it is
       possible that an authoritative DNS server might attempt to
       validate the delegation for a zone before answering
       authoritatively for that zone.  In this situation, it would find
       an invalid delegation, and would not answer authoritatively.  A
       server that implements this sort of check MUST be configurable so
       that either it does not do this check for the 'home.arpa' domain,
       or it ignores the results of the check.

I think the problem here might be "attempt to validate".  Since the
point of section 7 is precisely to permit DNSSEC validation not to
"fail" (i.e. not to validate "bogus"), this seems to be an
equivocation on "validate".  I think what is probably meant is

    It is possible that an authoritative DNS server might have local
    policy that requires positive DNSSEC validation of a delegation
    for a zone before answering authoritatively for that zone.  In
    that situation, it would not find a signed delegation, and would
    therefore not answer authoritiatively.  A server …

If that's not what's meant, then I don't know what is meant.  The
delegation is certainly not invalid in the DNSSEC sense.  It's not
possible to find it in the global DNS servers authoritative for the
parent name space, however.  If _that's_ the worry, then the term
"valid" is not what is needed here.  In that case, maybe this is
what's wanted:

    It is possible that an authoritative DNS server might attempt to
    check the authoritative servers for home.arpa. for a delegation
    beneath that name before answering authoritatively for such a
    delegated name.  In such a case, because the name always has only
    local significance there will be no such delegation in the
    home.arpa. zone, and so the server would refuse to answer
    authoritatively for such a zone.  A server …

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Jul 2017 09:43:02 -0400

Your second suggestion is what I meant.  Thanks for taking the time to write it—I totally missed the conflicting meaning of "validate". 

> On Jul 7, 2017, at 8:34 AM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi there,
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Jul 2017 12:27:31 +1000

In message <[email-masked]>, Andrew Sullivan w
>        or it ignores the results of the check.

I suspect someone is confusing authoritative (AA=1) with authenticated
data (AD=1).  A authoritative nameserver can set both or just AA=1.
Note you can set AD=1 without checking the DS record in the parent.
All that is required is that *local policy* for setting AD is met.

     5.  No special processing of '.home.arpa' is required for
	 authoritative DNS server implementations.  However, it is
	 possible that an authoritative DNS server might attempt
	 to validate the delegation for a zone before answering
	 authoritatively for that zone.  In this situation, it would
	 find an insecure delegation (no DS record), and would not
	 answer with AD=1.  AA should be set as required by STD13.

Note this is a *insecure* delegation, not a *invalid* delegation.

> equivocation on "validate".  I think what is probably meant is

Section 7 is wrong, re-write below.

7.  Delegation of 'home.arpa'

   In order to be fully functional, there must be a delegation of
   'home.arpa' in the '.arpa' zone [RFC3172].  This delegation MUST
   be signed, MUST NOT include a DS record, and MUST point to one
   or more black hole servers, for example BLACKHOLE-1.IANA.ORG and
   BLACKHOLE-2.IANA.ORG.  The delegation is signed to prove the
   existance of the delegation at 'home.arpa' and the non-existance
   of the DS record at 'home.arpa'.  This breaks the DNSSEC chain
   of trust at 'home.arpa', which prevents a validating stub resolver
   from rejecting names published under 'home.arpa' on a homenet
   name server.

The delegation of home.arpa is signed (NSEC record for home.arpa,
or a covering NSEC3 record.), it just isn't a SECURE delegation (no
DS record present).

>     therefore not answer authoritiatively.  A server
>
>     authoritatively for such a zone.  A server
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Jul 2017 10:48:14 +0100

On 07/07/2017 14:43, Ted Lemon wrote:

> Your second suggestion is what I meant.  Thanks for taking the time
> to write it—I totally missed the conflicting meaning of "validate".

Ted,

Please incorporate Andrew's proposed change, after which I shall
(re-)advance this document to our AD for publication.

thanks,

Ray