Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

[Adam Roach <[e-mail]>]

On 8/28/17 5:29 PM, Ted Lemon wrote:
> El Aug 28, 2017, a les 6:07 PM, Adam Roach <[e-mail] 
> <mailto:[e-mail]>> va escriure:
>> Section 4 contains a list that it describes as defining "the behavior 
>> of [DNS]
>> systems". Item number 7 seems to be something else: I don't know what 
>> code or
>> configuration would result from this statement. Maybe move this item 
>> to section
>> 3?
>
> This is the format that RFC 6761 requires us to follow, which is why 
> it's being done this way.   I think the text makes sense if you read 
> it with the RFC 6761 list of criteria in section 5 in mind.   So I 
> don't think it makes sense to move it, although I agree it scans a bit 
> strangely. :)

Oh! That makes a lot more sense -- I should have chased down that 
section in 6761. I think what's tripping me up is the introduction in 
the homenet-dot draft: "This section defines the behavior of systems 
involved in domain name resolution when resolving queries for names 
ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if 
it said something more like "This section reserves the '.home.arpa.' 
subdomain according to the procedures outlined in [RFC6761] section 4."

(I'll also note that 6761 appears to require this to be "a subsection of 
the 'IANA Considerations' section", so you might consider moving it 
accordingly -- this would have been somewhat less confusing if it were 
clearer that it's part of the registration process, which putting it in 
the 'IANA Considerations' section would have done.)
>
>> With the explanation in section 6:
>>
>>   it may be useful for the resolver to identify different
>>   homenets on which it has resolved names
>>
>> Doesn't this mitigation in the security section require name resolution
>> libraries to recognize names that end in ".home.arpa." as special so 
>> that it
>> can treat them differently?
>
> Section 6 is talking about future work.   If we come up with a way to 
> do this, then it would update this document, changing the normative 
> requirement.


To me, this reads as something that could be done unilaterally by the 
local resolver according to their own reasonable notion of what the 
proper mitigations might be here. I would suggest rephrasing to make it 
clearer that this suggestion pertains to _future_ work; e.g., "To 
prevent this from happening, future documents may define behavior that 
allows resolvers to identify and distinguish among different homenets on 
which they have resolved names, and take appropriate measures to avoid 
such confusion."


/a