Subject: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 13:47:28 -0500

Here are my notes from updating the above two drafts.

Ralph Droms writes regarding draft-ietf-homenet-dothome:

> I suggest that the paragraph in the Introduction that motivates the change
> from .home to .homenet be augmented or replaced with the reasons Ray listed
> in earlier e-mail:
>
>
> 1.  we cannot be sure that using .home is consistent with the existing
> (ab)use
>
> 2.  ICANN is in receipt of about a dozen applications for ".home", and
> some of those applicants no doubt have deeper pockets than the IETF does
> should they decide to litigate
>
I updated the text as follows:

The '.homenet' top-level domain replaces '.home' which was specified in
[RFC7788] as the default domain-name for home networks. '.home' had been
selected as the most user-friendly option.  However, there are existing
uses of '.home' that may be in conflict with this use: evidence indicates
that '.home' queries frequently leak out and reach the root name servers
[ICANN1] [ICANN2].  Also, ICANN has about a dozen applicants for the
'.home' top-level domain name, which creates a significant risk of
litigation if it were claimed by the IETF outside of that process.  As a
result, the use of '.home' has been deprecated; this document updates
[RFC7788] to replace '.home' with '.homenet', while another document,
[I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD.

This sentence appears in section 2:
>
>>  Names ending with '.homenet.'  MUST refer to services that are located
>> within a home network (e.g., a printer, or a toaster).
>
> I think "services" is too restrictive; in fact, the examples are really
> devices or hosts, not services provided by those devices.  What is the
> restriction "located within a home network", and what, exactly, does it
> mean?  In my opinion, this document should focus on name evaluation within
> the .homenet locally served zone.

I updated the text as follows:

The top-level domain name '.homenet.' is to be used for naming within a
home network. Names ending with '.homenet.' reference a locally-served
zone, the contents of which are unique only to a particular home network,
and are not globally unique.  Such names refer to nodes and/or services
that are located within a home network (e.g., a printer, or a toaster).

 Also in section 2, the phrase "Although home networks most often provide
> one or more service discovery mechanisms," assumes the reader knows that
> many service discovery mechanisms hide the domain name of the service or
> host and, hence, .homenet.

I updated the text as follows:

Some service discovery user interfaces that are expected to be used on
homenets conceal information such as domain names from end users.  However,
it is still expected that in some cases, users will need to see, remember,
and even type, names ending with '.homenet'. It is therefore desirable that
users identify the top-level domain and understand that using it expresses
the intention to connect to a service that is specific to the home network
to which they are connected.  Enforcing the fulfillment of this intention
is out of scope for this document.

In section 3, the response to item 3 in the SUDN reservation considerations
> could be clarified by specifying that any queries in the .homenet zone must
> be forwarded to a DNS service as configured by explicitly by HNCP or other
> appropriate local configuration mechanism coordinated with .homenet
> resolution, as opposed to just “configured”.  A manually configured entry
> for some external server is “configured”, but not configured in a helpful
> way.

Also in item 3, s/for '.homenet'./for domain names ending in '.homenet'/

I updated the text as follows:

Name resolution APIs and libraries MUST NOT recognize names that end in
'.homenet.' as special an MUST NOT treat them differently. Name resolution
APIs MUST send queries for such names to their configured caching DNS
server(s). Using a caching server other than the server or servers offered
by the home network will result in failure to correctly resolve queries for
subdomains of '.homenet'.   If a host is configured to always use a
resolver other than the one offered by the local network, it will be unable
to resolve queries that are subdomains of '.homenet'.

> In item 4, s/part of the domain/part or all of the '.homenet' domain/

updated

Given the existence of draft-ietf-dnsop-terminology-bis, it would be
> helpful (at least, I would find it helpful) to use the agreed common
> terminology; for example “recursive resolver” instead of “Caching DNS
> servers”.

I updated the draft to use "recursive resolver" instead of "caching name
server" and sent a note to Paul asking him why there is no definition for
that term in the document.   :)

In the answer for question 5, it might help the reader to specify which
> zones the “authoritative servers” are authoritative for.

Well, now, when I looked at the answer to question five, I realized that
the text is wrong.   There is no need to specify anything here.   If an
authoritative server is configured to be authoritative for .homenet or any
subdomain(s) of .homenet, it will do the right thing.   If it is not, it
will do the right thing.   The text here requiring an auth server not to
return an NS record for .homenet would only apply to the root operator, and
we are addressing that in a different way.   I think requiring special
treatment for this name in an authoritative server would be a mistake.   I
have updated the text as follows:

Only a DNS server that is authoritative for the root ('.') or is configured
to be authoritative for '.homenet' or a subdomain of '.homenet' will ever
answer a query about '.homenet.'  In both of these cases, the server should
simply answer as configured: no special handling is required.

“DNS server operator” is likely a term of art in the answer for question,
> but it’s not clear to me which operators and servers are referred to,
> here.  Although passive voice should be avoided, it might be appropriate to
> simply write “DNS servers outside a home network should not be configured
> to be authoritative for .homenet.

I like your proposed text, and updated the document to use it.

Jacques Latour and Bob Harold got into a conversation where Jacque said:

Where do you delegate homenet to? Advanced DNSSEC validation may check for
> proper delegation?

This is actually addressed in the IANA considerations: the proposal is to
do an unsigned delegation to the AS112 servers.   However, the document
doesn't actually do anything to make sure that that delegation will produce
the right result.  I do not know how to address this.

Bob then asked:

If an insecure delegation can be made in the root, then could a local trust
> anchor be used by those who want their .homenet domain DNSSEC validated?

I added the following text to the security considerations to address this:

In order to enable DNSSEC validation of a particular '.homenet', it might
make sense to configure a trust anchor for that homenet.   How this might
be done is out of scope for this document.

Andrew Sullivan wrote, regarding draft-ietf-homenet-redact:

in ¶1 of §1, "This document recommends the use of the '.home'…." reads as
> though the present document (i.e. the I-D itself) is making the
> recommendation.  Perhaps "That document" instead would work, or "Said
> RFC", or something.

 I think "that document" does the job—thanks for catching this.

Andrew also raised the point about the unsigned root zone delegation and
the process woes that might follow such a request.   The working group
appears to have decided to try going down that path despite the potential
problems it presents, so I will say no more about that here.

He also wrote:

> In §1, "evidence indicates that '.home' queries frequently leak out and
> reach the root name servers [ICANN1] [ICANN2]", I don't think that's the
> issue.  The issue is that home is a well-known, in use TLD (we know
> because of those queries), and the consequences of reusing it are
> therefore completely unknown.

I updated this according to Ralph's suggestion, which I believe hit on the
same point.   Please let me know if you think further clarification or
deincorrectification is required.

New versions of these documents will be hitting the datatracker shortly.
If you feel that you had some comment that was not addressed, please let me
know: I did my best not to ignore what anybody said, but there was a long
thread, so I may have done so anyway.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Jan 2017 12:44:02 -0500

> On Jan 19, 2017, at 1:47 PM, Ted Lemon <[email-masked]> wrote:
> 

Ted - thanks for the notes.  In general, I think you've addressed my comments and the document is ready to be forwarded to the IESG.  I do have one remaining small issue (see inline).

>> I suggest that the paragraph in the Introduction that motivates the change from .home to .homenet be augmented or replaced with the reasons Ray listed in earlier e-mail:
>> 
>> 
>> 
>> 1.  we cannot be sure that using .home is consistent with the existing (ab)use
>> 
>> 2.  ICANN is in receipt of about a dozen applications for ".home", and some of those applicants no doubt have deeper pockets than the IETF does should they decide to litigate
>> 
> The '.homenet' top-level domain replaces '.home' which was specified in [RFC7788] as the default domain-name for home networks. '.home' had been selected as the most user-friendly option.  However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2].  Also, ICANN has about a dozen applicants for the '.home' top-level domain name, which creates a significant risk of litigation if it were claimed by the IETF outside of that process.  As a result, the use of '.home' has been deprecated; this document updates [RFC7788] to replace '.home' with '.homenet', while another document, [I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD. 

Ok.

>>>  Names ending with '.homenet.'  MUST refer to services that are located within a home network (e.g., a printer, or a toaster).
>> I think "services" is too restrictive; in fact, the examples are really devices or hosts, not services provided by those devices.  What is the restriction "located within a home network", and what, exactly, does it mean?  In my opinion, this document should focus on name evaluation within the .homenet locally served zone. 
> 
> The top-level domain name '.homenet.' is to be used for naming within a home network. Names ending with '.homenet.' reference a locally-served zone, the contents of which are unique only to a particular home network, and are not globally unique.  Such names refer to nodes and/or services that are located within a home network (e.g., a printer, or a toaster).

Ok.

> 
>>  Also in section 2, the phrase "Although home networks most often provide one or more service discovery mechanisms," assumes the reader knows that many service discovery mechanisms hide the domain name of the service or host and, hence, .homenet.
> 
> Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users.  However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with '.homenet'. It is therefore desirable that users identify the top-level domain and understand that using it expresses the intention to connect to a service that is specific to the home network to which they are connected.  Enforcing the fulfillment of this intention is out of scope for this document.

Ok.

> 
>> In section 3, the response to item 3 in the SUDN reservation considerations could be clarified by specifying that any queries in the .homenet zone must be forwarded to a DNS service as configured by explicitly by HNCP or other appropriate local configuration mechanism coordinated with .homenet resolution, as opposed to just “configured”.  A manually configured entry for some external server is “configured”, but not configured in a helpful way.
> Name resolution APIs and libraries MUST NOT recognize names that end in '.homenet.' as special an MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to their configured caching DNS server(s). Using a caching server other than the server or servers offered by the home network will result in failure to correctly resolve queries for subdomains of '.homenet'.   If a host is configured to always use a resolver other than the one offered by the local network, it will be unable to resolve queries that are subdomains of '.homenet'.

I think this is almost right, but still misses the explicit requirement the "configured ... servers" be the servers in the home network.

Perhaps:

Name resolution APIs MUST send queries for such name to a recursive DNS server configured to be authoritative for the .homenet zone appropriate to the home network.  This RDNSS or list of RDNSSes will usually be supplied to the client through a local configuration mechanism like HNCP or DHCP.  If a host is configured to use a resolver other than one that is authoritative for the appropriate .homenet zone, the client may be unable to resolve or receive incorrect results for names in sub domains of ".homenet".

>> In item 4, s/part of the domain/part or all of the '.homenet' domain/

Ok.
>> Given the existence of draft-ietf-dnsop-terminology-bis, it would be helpful (at least, I would find it helpful) to use the agreed common terminology; for example “recursive resolver” instead of “Caching DNS servers”.
> 
> I updated the draft to use "recursive resolver" instead of "caching name server" and sent a note to Paul asking him why there is no definition for that term in the document.   :)

Ok.  I threw "RDNSS" in the text above, dunno which term is best.
> 
>> In the answer for question 5, it might help the reader to specify which zones the “authoritative servers” are authoritative for.
> 
> 
> Well, now, when I looked at the answer to question five, I realized that the text is wrong.   There is no need to specify anything here.   If an authoritative server is configured to be authoritative for .homenet or any subdomain(s) of .homenet, it will do the right thing.   If it is not, it will do the right thing.   The text here requiring an auth server not to return an NS record for .homenet would only apply to the root operator, and we are addressing that in a different way.   I think requiring special treatment for this name in an authoritative server would be a mistake.   I have updated the text as follows:
> 
> Only a DNS server that is authoritative for the root ('.') or is configured to be authoritative for '.homenet' or a subdomain of '.homenet' will ever answer a query about '.homenet.'  In both of these cases, the server should simply answer as configured: no special handling is required. 

Good catch and I agree with your new text.

> 
>> “DNS server operator” is likely a term of art in the answer for question, but it’s not clear to me which operators and servers are referred to, here.  Although passive voice should be avoided, it might be appropriate to simply write “DNS servers outside a home network should not be configured to be authoritative for .homenet.
> 

Ok.

- Ralph

>> Where do you delegate homenet to? Advanced DNSSEC validation may check for proper delegation?  
> 
> This is actually addressed in the IANA considerations: the proposal is to do an unsigned delegation to the AS112 servers.   However, the document doesn't actually do anything to make sure that that delegation will produce the right result.  I do not know how to address this.
>  
> Bob then asked:
> 
>> If an insecure delegation can be made in the root, then could a local trust anchor be used by those who want their .homenet domain DNSSEC validated? 
> 
> In order to enable DNSSEC validation of a particular '.homenet', it might make sense to configure a trust anchor for that homenet.   How this might be done is out of scope for this document.
>  
>> in ¶1 of §1, "This document recommends the use of the '.home'…." reads as though the present document (i.e. the I-D itself) is making the recommendation.  Perhaps "That document" instead would work, or "Said RFC", or something.
> 
> Andrew also raised the point about the unsigned root zone delegation and the process woes that might follow such a request.   The working group appears to have decided to try going down that path despite the potential problems it presents, so I will say no more about that here.
> 
> He also wrote:
>> In §1, "evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]", I don't think that's the issue.  The issue is that home is a well-known, in use TLD (we know because of those queries), and the consequences of reusing it are therefore completely unknown.
> 
> I updated this according to Ralph's suggestion, which I believe hit on the same point.   Please let me know if you think further clarification or deincorrectification is required.
> 
> New versions of these documents will be hitting the datatracker shortly.   If you feel that you had some comment that was not addressed, please let me know: I did my best not to ignore what anybody said, but there was a long thread, so I may have done so anyway. 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jan 2017 13:09:51 -0500

On Jan 30, 2017 12:44 PM, "Ralph Droms" <[email-masked]> wrote:

Name resolution APIs MUST send queries for such name to a recursive DNS
server configured to be authoritative for the .homenet zone appropriate to
the home network.  This RDNSS or list of RDNSSes will usually be supplied
to the client through a local configuration mechanism like HNCP or DHCP.
If a host is configured to use a resolver other than one that is
authoritative for the appropriate .homenet zone, the client may be unable
to resolve or receive incorrect results for names in sub domains of
".homenet".

The problem with this is that you're asking the resolver to know that it is
talking to a homenet.   I would rather describe the problem than write
normative text that fixes it.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Jan 2017 13:26:34 -0500

> On Jan 30, 2017, at 1:09 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Jan 30, 2017 12:44 PM, "Ralph Droms" <[email-masked] <mailto:[email-masked]>> wrote:
> The problem with this is that you're asking the resolver to know that it is talking to a homenet.   I would rather describe the problem than write normative text that fixes it.

Ah, of course, I see your point.  On the other hand "MUST send queries for such names to their configured caching DNS server(s)" seems to me to have no content - what else would the client API do but send queries to the configured servers?

2nd try:

Name resolution APIs and libraries MUST NOT recognize names that end in '.homenet.' as special and MUST NOT treat them differently.  Name resolution APIs will only resolve such a name correctly if the query is sent to a recursive DNS server configured to be authoritative for the .homenet zone appropriate to the home network.  This RDNSS or list of RDNSSes will usually be supplied to the client through a local configuration mechanism like HNCP or DHCP.  If a host is configured to use a resolver other than one that is authoritative for the appropriate .homenet zone, the client may be unable to resolve or receive incorrect results for names in sub domains of ".homenet".

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jan 2017 15:04:46 -0500

How about this:

> Name resolution APIs and libraries MUST NOT recognize names that end in '.homenet.' as special and MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the .homenet zone appropriate to the home network.  One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP.  If a host is configured to use a resolver other than one that is authoritative for the appropriate .homenet zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of ".homenet". 

I don't like RDNSS, so I expanded the acronym; I don't think that we should mention HNCP here as a host configuration protocol.   I also cleaned up the last sentence a bit.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Jan 2017 15:11:06 -0500

> On Jan 30, 2017, at 3:04 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Jan 30, 2017, at 1:26 PM, Ralph Droms <[email-masked] <mailto:[email-masked]>> wrote:

Fine with me... 

- Ralph

---

From: Ray Bellis <[email-masked]>
Date: Mon, 30 Jan 2017 20:13:09 +0000

> Fine with me... 

Ralph - thanks for checking through Ted's edits.

Mark and I shall be going through the documents ourselves this week
before we advance them to the IESG.

If any other people that made comments during WGLC would please also
double check that their issues have been addressed that would be much
appreciated.

thanks,

Ray

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jan 2017 15:21:54 -0500

Thanks, Ray!   I've uploaded a new version of the document, so if someone is moved to do another review now, they may want to start from there.