Re: [mif] Last Call for MIF DNS server selection document

[Brian E Carpenter <[e-mail]>]

Teemu,

I think that is the best approach in order to get this document out
without launching a war about the integrity of the DNS namespace.

>> Private namespaces MUST only consist of subdomains of the domains communicated 
>> for nodes (e.g. subdomains of example.com)

I'm wondering whether that doesn't have to be a bit more elaborated.
Something like:

Private namespaces MUST only consist of subdomains of domains for which the
relevant operator provides authoritative name service. Thus, subdomains
of example.com are permitted in the private namespace served by an operator's
DNS servers only if the same operator provides an SOA record for example.com.

Thanks

   Brian

On 2011-09-12 20:08, [e-mail] wrote:
> Brian,
> 
> I agree with that very reasonable suggestion. I think the problem described in 
> section 2.3 is one symptom of issues caused by non-uniqueness (and for which I 
> have not figured out automated solution).
> 
> I mostly rewrote (for the -04 draft version) section 7 "Considerations for 
> network administrators" as follows. Would that address this concern?
> --
> Network administrators deploying private namespaces should assist advanced 
> nodes in their DNS server selection process by providing information described 
> within this document.
> 
> Private namespaces MUST be globally unique in order to keep DNS unambiguous 
> and henceforth avoiding caching related issues and destination selection 
> problems (see section 2.3). An exception to this rule are domains utilized for 
> local name resolution (such as .local).
> 
> Private namespaces MUST only consist of subdomains of the domains communicated 
> for nodes (e.g. subdomains of example.com). This means that a DNS server MUST 
> NOT resolve any domains that are not globally resolvable and are not 
> subdomains of said communicated domains.
> 
> To mitigate against attacks against local namespaces, administrators utilizing 
> this tool SHOULD deploy DNSSEC for their zone.
> --
> 
> The .local remains open issue though, I encountered this also in homenet 
> mailing list.. well it works fine as long as node is not connected to multiple 
> local networks at the same time... If node is, then I guess the application 
> must be able to select the right local network interface to use..
> 
> Best regards,
> 
> Teemu
> 
>> -----Original Message-----
>> From: ext Brian E Carpenter [mailto:[e-mail]]
>> Sent: 10. syyskuuta 2011 00:01
>> To: Savolainen Teemu (Nokia-CTO/Tampere)
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [mif] Last Call for MIF DNS server selection document
>>
>> Teemu,
>>
>> I think the reference to multiple namespaces in the requirements draft is 
>> too
>> short to really generate discussion, and in any case it's only an 
>> Informational
>> document.
>>
>> However, I was trying to be quite careful in what I wrote.
>>
>>>> if the network administrator just does not want names to be
>>>> resolvable on the public Internet.
>> That is one thing, and an *ambiguous* namespace is another.
>>
>> I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or
>> elsewhere that make it clear that any domains that are not globally
>> resolvable must nevertheless be globally unique. That needs to be expressed
>> a bit more precisely and there might have to be an exception for .local.
>> However, if a host can see a DNS server from example.com, a rule could
>> be: that server MUST NOT resolve any domains that are not globally
>> resolvable and are not subdomains of example.com.
>>
>> I am sure there is a better way to express this. It just needs to guarantee 
>> a
>> strict hierarchy in the namespace.
>>
>> Regards
>>    Brian Carpenter
>>
>> On 2011-09-09 18:15, [e-mail] wrote:
>>> Keith, Brian,
>>>
>>> The problem this draft is addressing has been acknowledged in the
>>> draft-ietf-mif-problem-statement-15.txt section 4.1. The problem
>>> statement is already at the RFC editor's queue.
>>>
>>> Based on the acceptance of the problem, this WG was chartered with a
>>> goal
>>> of:
>>> --
>>>   1) DNS server selection solution: a specification for describing a way
>>>   for a network to communicate to nodes information required to perform
>>>   advanced DNS server selection at name resolution request granularity
>>>   in scenarios involving multiple namespaces. The specification shall
>>>   describe the information to be delivered for nodes and the protocol to
>>>   be used for delivery.
>>> --
>>>
>>> This draft is the solution that has been accepted as a WG work item.
>>>
>>> The topic has been discussed for a quite long time and I don't think
>>> there are any such surprises you refer to (except perhaps for
>>> individuals who just now start following the work).
>>>
>>> Furthermore, I cannot easily buy the argument (I hope I read your
>>> points
>>> right) that a solution should not be developed for an acknowledged
>>> problem out of fear of "legitimizing" the problematic behavior.
>>>
>>> I do agree BCP or similar might be nice to have, but would such BCP
>>> really make any difference e.g. if the network administrator just does
>>> not want names to be resolvable on the public Internet.
>>>
>>> Best regards,
>>>
>>> 	Teemu
>>>
>>>> -----Original Message-----
>>>> From: ext Keith Moore [mailto:[e-mail]]
>>>> Sent: 09. syyskuuta 2011 01:22
>>>> To: Brian E Carpenter
>>>> Cc: Savolainen Teemu (Nokia-CTO/Tampere); [e-mail];
>>>> [e-mail]; [e-mail]
>>>> Subject: Re: [mif] Last Call for MIF DNS server selection document
>>>>
>>>>
>>>> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote:
>>>>
>>>>> Teemu,
>>>>>
>>>>> On 2011-09-08 18:16, [e-mail] wrote:
>>>>>> Brian,
>>>>>>
>>>>>> Thank you for review. I agree it is a good idea to consult those
>>>>>> WGs (and DHC as well I suppose), but what makes you so concerned of
>>>>>> this
>>>> text:
>>>>>>>>   In deployments where multiple namespaces are present, selection
>> of
>>>>>>>>   correct route and destination and source addresses for the
>>>>>>>> actual
>>> IP
>>>>>>>>   connection is crucial as well, as the resolved destination's IP
>>>>>>>>   addresses may be only usable on the network interface over
>>>>>>>> which
>>> the
>>>>>>>>   name was resolved on.
>>>>>> I wrote that as I thought it would be useful to talk a little about
>>>>>> bigger picture of some deployments (like in the demo we had few
>>>>>> IETFs back - without presence of DHCPv6 more specific route options
>>>>>> the system would not have worked properly) .. but if that text
>>>>>> creates an unwanted link or dependency or confusion, I think we can
>>>>>> drop the text just as well and focus on the document just to the
>>>>>> new options and leave this kind of additional system-level
>>>>>> consideration out of the
>>>> doc.
>>>>> As Andrew pointed out, the draft starts
>>>>>
>>>>>   "...from the premise that operators sometimes include private
>>>>>    namespaces in the answers they provide from DNS servers, and that
>>>>>    those private namespaces are at least as useful to clients as the
>>>>>    answers from the public DNS."
>>>>>
>>>>> I believe that you will discover during IETF LC that many people
>>>>> have strong feelings about this premise; as Andrew implied,
>>>>> conceptually the DNS is a unified global namespace. This draft is a
>>>>> backdoor way of legitimising an ambiguous namespace. I don't think
>>>>> that will have an easy time in IETF LC, especially if it is dropped
>>>>> as a surprise into the DNS community. It's your choice, but I would
>>>>> suggest that exposing it to the DNS WGs now would be a smart move.
>>>> Frankly, I consider this very nearly a showstopper, in the sense that
>>>> MIF needs an extremely good reason to do this, and I haven't seen
>>>> even a hint
>>> of
>>>> such a reason.    You may recall that I raised this issue in Quebec,
>>> though
>>>> perhaps I was too polite about it.  (Since I hadn't read the document
>>>> yet,
>>> and
>>>> was coming late into the discussion, I wanted to give the group the
>>> benefit
>>>> of the doubt.)
>>>>
>>>> I'm quite surprised that MIF was able to get this far with the document
>>>> without the issue being raised.    I'm shocked that this issue appears to
>>> be a
>>>> surprise to the WG.  I think that by itself is likely a sign of a
>>>> serious
>>> process or
>>>> management failure.
>>>>
>>>>
>>>>> It goes further. The IETF has a longstanding issue with technology
>>>>> that encourages walled gardens. See for example RFC 3002. I think
>>>>> there will be quite some discussion, and this will definitely happen
>>>>> even if you try to remove the "system-level" considerations, because
>>>>> they are strongly implied anyway.
>>>>>
>>>>> Personally I'm not sure what I think about this, but it needs to be
>>>>> discussed in the community IMHO.
>>>> +1.
>>>>
>>>> Keith