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

[Fred Baker <[e-mail]>]

On Jun 17, 2012, at 2:29 AM, Brian E Carpenter wrote:

> 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.

You're correct that DNS-land hasn't liked it. I think the point being made here is that, with or without help from namedroppers@, something akin to what Ray described is an operational reality. It's not unusual for a company to have an internal and external set of names, the latter much smaller. Servers that are externally-accessible don't translate names that the company doesn't authorize for external access, even if they have global addresses, and even for names that are so advertised, they might be internally read/write while externally read-only, and in fact be instantiated as separate servers, the read/write one periodically over-writing the read-only one.

Speaking for myself, I would rather have a frank discussion of a bad idea that is an operational reality than to play pretend (see my draft on firewalls, which has the same logic underlying it), because discussion may improve it or may convince people it is in fact a bad idea - or may demonstrate that it's a good idea that is unpopular.

> 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
>> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops