Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

[Warren Kumari]

Ok, I'm surprised - I spent much time with this review, and felt bad
submitting a number of DISCUSS points close to the telechat. I thought
that addressing them might end up in this going back to the WG -- but,
your (really quick) responses more than adequately addresses my
DISCUSS (and major concerns).

Thank you, I'm clearing my discuss position -- more inline, but I'm a
happy camper.



On Wed, Aug 30, 2017 at 3:54 PM, Ted Lemon  wrote:
> On Aug 30, 2017, at 3:10 PM, Warren Kumari  wrote:
>> 1: Section 4.  Domain Name Reservation Considerations, Subsection 4
>> If I'm a recursive server and I am configured "with a delegation to an
>> authoritative server for that particular homenet’s instance of the domain
>> ’home.arpa.’." then I have a local zone containing "home.arpa   IN   NS
>> ". Unless I'm really confused, this means
>> that I have to make myself authoritative for .arpa, which will a: break
>> everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to
>> validating stubs. (See also #5). Perhaps you mean that there should be
>> something like (BINDism): zone "home.arpa" {
>>type forward;
>>forwarders { 192.0.2.1; 192.0.2.2; };
>> };
>> This possibility only came to me after much thought, and I do not think that 
>> it
>> could be described as "a delegation". I also do not think that this is a
>> standard / well defined behavior.
>
> Yup, that's bogus.   Is this better?
>
> In addition to the behavior specified above, recursive 
> resolvers that can be used in
> a homenet MUST be configurable to forward queries for 
> 'home.arpa.' and subdomains of
> 'home.arpa.' to an authoritative server for 'home.arpa.'.   
> This server will provide
> authoritative data for 'home.arpa.' within a particular 
> homenet.   The special
> handling for DS records for the 'home.arpa.' delegation is 
> still required.

Much better, thanks.


>
>
>> 2: Section 4.  Domain Name Reservation Considerations, Subsection 4
>> "Caching resolvers conforming to this specification MUST support DNSSEC
>> queries." This is a MUST, so it's important to understand, but I don't
>> understand what it actually means.  What is a "DNSSEC query"? It is just one
>> with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I
>> don't know what this means, so I don't know if it applies to me / what I 
>> should
>> do.
>
> I think this is clarified in the -13 version of the document.   Is this 
> review based on that version, or on -12?   Here is the new text:
>
> Recursive resolvers at sites using 'home.arpa.' MUST 
> transparently support
> DNSSEC queries: queries for DNSSEC records and queries with 
> the DO bit set
> ( section 3.2.1).  While validation 
> is not required, it
> is strongly encouraged: a caching recursive resolver that 
> does not validate
> answers that can be validated may cache invalid data.  This 
> in turn will prevent
> validating stub resolvers from successfully validating 
> answers.

WFM.

>
>> 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST
>> behave as described in Locally Served Zones ([RFC6303] Section 3).  That is,
>> queries for domains that are subdomains of ’home.arpa.’ MUST NOT be 
>> forwarded,
>> with one important exception: ..." This says that I must not forward for
>> *domains* that are *subdomains* of home.arpa. The example shows a lookup for 
>> NS
>> for 'home.arpa', so presumably this is actually talking about subdomains of
>> home.arpa.  So, I have no idea what to do for lookups within home.arpa itself
>> -- what do I do with query for the A record for printer.home.arpa? It is 
>> simply
>> a name within home.arpa; I have no way of knowing if it is a subdomain of
>> home.arpa but it certainly isn't a domain that is a subdomain of home.arpa
>> (because there are only three label, not four).
>
> Yes, the other text had the same problem.   How about "queries for 
> 'home.arpa.' and subdomains of 'home.arpa.'"?

WFM. Thanks.

>
>> --
>> COMMENT:
>> --
>>
>> Major issues:
>>
>> 1: I think that this document could benefit from additional review in the 
>> DNSOP
>> WG - it got some
>> (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that
>> was a: while it was still homenet. b: primarily focused in terms of RFC6761 
>> and
>> not on the whole systems / interaction with existing behaviors, c: largely
>> devolved into "does this do go in the root zone or not"?, d: 9 revisions 
>> back.
>> The document feels vague about much of the details / expected behavior from 
>> all
>> of the different players, and I think more focused review from more DNS 
>> people
>> would help.

Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

[Ted Lemon]

On Aug 30, 2017, at 3:10 PM, Warren Kumari  wrote:
> 1: Section 4.  Domain Name Reservation Considerations, Subsection 4
> If I'm a recursive server and I am configured "with a delegation to an
> authoritative server for that particular homenet’s instance of the domain
> ’home.arpa.’." then I have a local zone containing "home.arpa   IN   NS  
> ". Unless I'm really confused, this means
> that I have to make myself authoritative for .arpa, which will a: break
> everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to
> validating stubs. (See also #5). Perhaps you mean that there should be
> something like (BINDism): zone "home.arpa" {
>type forward;
>forwarders { 192.0.2.1; 192.0.2.2; };
> };
> This possibility only came to me after much thought, and I do not think that 
> it
> could be described as "a delegation". I also do not think that this is a
> standard / well defined behavior.

Yup, that's bogus.   Is this better?

In addition to the behavior specified above, recursive 
resolvers that can be used in
a homenet MUST be configurable to forward queries for 
'home.arpa.' and subdomains of
'home.arpa.' to an authoritative server for 'home.arpa.'.   
This server will provide
authoritative data for 'home.arpa.' within a particular 
homenet.   The special
handling for DS records for the 'home.arpa.' delegation is 
still required.


> 2: Section 4.  Domain Name Reservation Considerations, Subsection 4
> "Caching resolvers conforming to this specification MUST support DNSSEC
> queries." This is a MUST, so it's important to understand, but I don't
> understand what it actually means.  What is a "DNSSEC query"? It is just one
> with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I
> don't know what this means, so I don't know if it applies to me / what I 
> should
> do.

I think this is clarified in the -13 version of the document.   Is this review 
based on that version, or on -12?   Here is the new text:

Recursive resolvers at sites using 'home.arpa.' MUST 
transparently support
DNSSEC queries: queries for DNSSEC records and queries with the 
DO bit set
( section 3.2.1).  While validation is 
not required, it
is strongly encouraged: a caching recursive resolver that does 
not validate
answers that can be validated may cache invalid data.  This in 
turn will prevent
validating stub resolvers from successfully validating answers.

> 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST
> behave as described in Locally Served Zones ([RFC6303] Section 3).  That is,
> queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded,
> with one important exception: ..." This says that I must not forward for
> *domains* that are *subdomains* of home.arpa. The example shows a lookup for 
> NS
> for 'home.arpa', so presumably this is actually talking about subdomains of
> home.arpa.  So, I have no idea what to do for lookups within home.arpa itself
> -- what do I do with query for the A record for printer.home.arpa? It is 
> simply
> a name within home.arpa; I have no way of knowing if it is a subdomain of
> home.arpa but it certainly isn't a domain that is a subdomain of home.arpa
> (because there are only three label, not four).

Yes, the other text had the same problem.   How about "queries for 'home.arpa.' 
and subdomains of 'home.arpa.'"?

> --
> COMMENT:
> --
> 
> Major issues:
> 
> 1: I think that this document could benefit from additional review in the 
> DNSOP
> WG - it got some
> (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that
> was a: while it was still homenet. b: primarily focused in terms of RFC6761 
> and
> not on the whole systems / interaction with existing behaviors, c: largely
> devolved into "does this do go in the root zone or not"?, d: 9 revisions back.
> The document feels vague about much of the details / expected behavior from 
> all
> of the different players, and I think more focused review from more DNS people
> would help.

I disagree.   The document has had substantial review from DNSOP people, 
including recently.   They are mentioned in the acknowledgments.   I think that 
I've fixed a couple of the things in -13 that triggered this reaction.   In 
particular:

> 2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or
> is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses
> both terms makes me think that they are different, but I don't know how.

The term "caching resolver" was carried over from 6761.   What is meant here is 
"recursive resolver" or "full service resolver," which I think are 

[homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
draft-ietf-homenet-dot-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/



--
DISCUSS:
--

1: Section 4.  Domain Name Reservation Considerations, Subsection 4
If I'm a recursive server and I am configured "with a delegation to an
authoritative server for that particular homenet’s instance of the domain
’home.arpa.’." then I have a local zone containing "home.arpa   IN   NS  
". Unless I'm really confused, this means
that I have to make myself authoritative for .arpa, which will a: break
everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to
validating stubs. (See also #5). Perhaps you mean that there should be
something like (BINDism): zone "home.arpa" {
type forward;
forwarders { 192.0.2.1; 192.0.2.2; };
};
This possibility only came to me after much thought, and I do not think that it
could be described as "a delegation". I also do not think that this is a
standard / well defined behavior.

2: Section 4.  Domain Name Reservation Considerations, Subsection 4
"Caching resolvers conforming to this specification MUST support DNSSEC
queries." This is a MUST, so it's important to understand, but I don't
understand what it actually means.  What is a "DNSSEC query"? It is just one
with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I
don't know what this means, so I don't know if it applies to me / what I should
do.

3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST
behave as described in Locally Served Zones ([RFC6303] Section 3).  That is,
queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded,
with one important exception: ..." This says that I must not forward for
*domains* that are *subdomains* of home.arpa. The example shows a lookup for NS
for 'home.arpa', so presumably this is actually talking about subdomains of
home.arpa.  So, I have no idea what to do for lookups within home.arpa itself
-- what do I do with query for the A record for printer.home.arpa? It is simply
a name within home.arpa; I have no way of knowing if it is a subdomain of
home.arpa but it certainly isn't a domain that is a subdomain of home.arpa
(because there are only three label, not four).


--
COMMENT:
--

Major issues:

1: I think that this document could benefit from additional review in the DNSOP
WG - it got some
(https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that
was a: while it was still homenet. b: primarily focused in terms of RFC6761 and
not on the whole systems / interaction with existing behaviors, c: largely
devolved into "does this do go in the root zone or not"?, d: 9 revisions back.
The document feels vague about much of the details / expected behavior from all
of the different players, and I think more focused review from more DNS people
would help.

2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or
is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses
both terms makes me think that they are different, but I don't know how.

3: The document says: "Unless configured otherwise, recursive resolvers and DNS
proxies MUST behave as described in Locally Served Zones ([RFC6303] Section
3).", but I do not see this being added to the locally served zones registry.
This was raised in a previous review (Jon Mitchell, OpsDir (for v03)
https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/
), and not implemented. I'm assuming there is a reason, but I haven't found the
discussion.

4: The document describes what recursive servers should do with queries for
things in home.arpa, but seems to gloss over some detail -- I think that the
document would benefit from an overview showing the stub (and / or validating
stub), an internal recursive / proxy, an external recursive, the local
authoritative for home.arpa, and the .arpa servers, and clearly explain what
the expected behavior / role for each one under various scenarios is.

5: Even with the above answered, I remain confused by the "what does a
recursive resolver do" bit -- this discusses what a recursive server should do
with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC
validating stubs from believing that foo.home.arpa