Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00)

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

Re split DNS, someone pointed me at this interesting draft:
http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view

Not a popular topic in DNS land, of course.

Regards
   Brian

On 2012-06-14 18:06, Ray Hunter wrote:
> inline
>> Lee Howard <mailto:[e-mail]>
>> 14 June 2012 17:01
>>> -----Original Message-----
>>> From: Ray Hunter [mailto:[e-mail]]
>>> Sent: Wednesday, June 13, 2012 11:28 AM
>>> To: Lee Howard
>>> Cc: 'Victor Kuarsingh'; 'IPv6 Operations'
>>> Subject: Re: [v6ops] Enterprise Guidance on IPv6
>>> (draft-chkpvc-enterprise-incremental-
>>> ipv6-00)
>>>
>>> Regardless of whether this draft is the vehicle or not, one thing
>>> that I think is missing is that
>>> large enterprises currently almost universally use some sort of
>>> centralized gateway or proxy
>>> to access the Internet, coupled with "split DNS" (whether the IETF
>>> likes that or not
>>
>> "Split DNS" meaning that different responses are returned depending on
>> whether the query
>> comes from within the enterprise or from outside?
>> For instance, an employee can reach ACCOUNTING.EXAMPLE.COM internally,
>> because the
>> name server returns a net 10 address, but a query from outside receives
>> NXDOMAIN?
> I believe "Split DNS" can mean several things, which is why I placed it
> in quotes.
> 
> I don't think Split DNS was ever acknowledged as a standard. But it is
> widely deployed in enterprises AFAIK. One reason was to mitigate against
> cache poisoning. Another was to be able to use DNS with RFC1918
> addresses before this was supported on common implementations. Another
> was just so that internal name and address space was completely private
> in manufacturing environments. Another was for test & development
> environments. Another was so that dynamically updated names in AD could
> remain relatively secure from external interference.
> 
> So the namespace can be split, or the transport, or both.
> 
> I believe I've seen:
> 
> 1) internal hidden servers that serve different zones internally as the
> external servers. These internal hidden masters may be used to source
> zone transfers to sacrificial external slave servers that serve a subset
> of the namespace. So ext.example.com may be served externally, but
> int.example.com may be restricted to the internal servers (simply by not
> having the secondary zone configured on the external server). The
> internal servers may or may not be able to resolve Internet names
> (sometimes via a proxy DNS setup) Here we have a split namespace, and
> potentially a split transport (depending on how internal hosts resolve
> external addresses)
> 
> 2) A single set of DNS servers that serve different answers based on
> some parameter from the query e.g. a single DNS server using BIND
> "views" to provide an answer for accounting.example.com based on the
> source address of the query matching an on-enterprise-net pattern, that
> is not resolvable for off-enterprise-net addresses. Here we're clearly
> talking about split namespace, but contiguous transport.
> 
> 3) Completely separate internal and external servers serving the same
> logical zone but with different content and sometimes managed completely
> separately e.g. www.example.com hosted externally at a hosting provider
> for a corporate website for public consumption, and a separate
> employee's version of the same website iww.example.com hosted internally
> by the IT department. The external DNS servers may have an Internet
> hints file and a be managed by the hosting provider. The internal DNS
> servers may have a (fake) master root zone and be managed by the IT
> department. Internal hosts normally will not be able to resolve
> www.external.com or www.example.com and are pointed to an appropriate
> web proxy via a proxy pac file. Here we're talking about split namespace
> and split transport. Sometimes there may even be conflicting or
> overlapping namespace.
> 
> 4) Completely fictitious internal A record entries for trusted 3rd party
> companies where there is a private link between the two companies
> together with a contractual agreement defining responsibilities e.g. for
> B2B transactions or for managing outsourced systems, or providing
> outsourced services to example.com. This is just a horrible kludge.
> 
> 5) Equivalent of a .local namespace for dev, test & production. So
> there'd be overlapping address space for hostname-x.dev.company.com
> hostname-x.test.company.com hostname-x.production.company.com. As
> software moved from one environment to the next, all that was changed
> was the DNS default search domain (no machine renumbering needed in
> order to avoid problems with high availability scripts having to be
> edited). Some people even used identical setups for all 3 environments
> (identical names, addresses & domains) to avoid changing anything as
> solutions were transported between environments (via hard media).
> 
> 6) Manufacturing environments that were meant to be completely isolated
> (yes I know) that use private RFC1918 IP space.
> 
> Don't shoot the messenger.
>>> Many enterprises have expressed a desire to become "Internet Centric"
>>> whatever that is. They're also moving very rapidly to cloud services for
>> generic applications.
>>> However, they'll still need private enterprise networks with SLAs for
>>> many
>> other business
>>> critical services ad interim, at least until the generic Internet
>>> supports
>> an equivalent of
>>> Diffserv.
>>> Multiple IPv6 addresses per node, with a combination of PI space for the
>> enterprise network
>>> and PA space fromlocal providers, is making direct proxy-free nat-free
>> local Internet
>>> breakout potentially possible (together with MIF and appropriate address
>> selection).
>>> DNSSEC is also potentially attractive to facilitate/ restore a basic end
>> to end trust model.
>>> So I think we know where we're starting, and I think we know where we
>>> end
>> up, but is there
>>> any operational advice available on the steps that would be required to
>> e.g. "unsplit DNS"
>>> (and remove proxies) when introducing IPv6?
>>
>> What changes?  You can still return NXDOMAIN if you don't like the
>> querier.
>> Or you can
>> respond with a AAAA and rely on your security to protect your accounting
>> system.
> You're assuming that the transport has always been contiguous between
> internal and external hosts and DNS servers,  and that there is a single
> consistent set of authoritative name servers for a common Worldwide
> namespace. That is rarely the case AFAIK.
>>> In other words, how do we restore the end to end model without breaking
>> stuff on the way?
>>
>> I may be misunderstanding you, though, since I'm not sure how the
>> end-to-end
>> principle
>> applies to this DNS setup.
>> Yes, GUA addressing makes it possible to eliminate NAT, but whether
>> enterprises eliminate
>> proxies depends on their policy reasons for implementing them in the
>> first
>> place.
>>
>> What should we say about all this?
> It's relatively easily to define a flexible PI based IPv6 addressing
> plan so that return routes can be de-aggregated as necessary (based on
> Internet latency) as the number of direct Internet gateways grows. That
> might be a useful hint for enterprises as they remove proxies and
> increase local breakout.
> 
> But I really don't know at the moment what's the best roadmap for
> migrating the DNS and the namespace to being "Internet centric", which
> is why I asked the WG ;)
> 
> It could get very complex because you can learn or leak IPv4 information
> (e.g. RFC1918 addresses, private namespace, or conflicting namespace)
> over an IPv6 transport connection (which will be end-to-end
> transparent), but which would not be transported over an IPv4 connection
> (the IPv4 transport either never existed, was DNS forwarded or proxied,
> or was NATted). Then add caching and mobile end nodes into the mix.
> 
> I suspect it will be quite easy for enterprises to paint themselves into
> a corner, if they haven't already. And if they already have, what do
> they do?
> 
> regards,
> RayH
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>