What will BIND do?

[Kevin Darcy]

Yes, in a split DNS setup, the external data needs to be entered in
*both* versions of the zone, if it is to be visible both internally and
externally. Note that if the same machine is master for both internal and
external versions of the zone (either externally-accessible or a
"hidden" master for the external version), you might be able to play
$INCLUDE-file tricks to make the maintenance a little easier. Alternatively,
tweak your DNS maintenance system to maintain the external entries in parallel
with the internal ones. I doubt QIP is capable of this, but some homegrown
systems may be (I'm working on implementing "parallel maintenance" here).


- Kevin

Christopher Fellows wrote:

> Hello everyone, First time poster here...
>
> I have a situation that I need a little bit of advice on. We are currently
> designing a rooted DNS architecture for a large (global) company and are not
> sure what will happen under some very specific circumstances. First let me
> tell
> you a little bit about the design.
>
> Requirements:
>
> 1. Internal rooted DNS - several root servers sprinkled around the globe
> acting
> as "."
>
> 2. Default route to Internet for some internal clients - currently DNS is
> proxied along with WWW content. We require some (if not all) internal
> clients to
> have direct access to the Internet (non-proxied) This is due to some
> Internet
> based applications that require direct communication with the client (mostly
> JAVA applets and Citrix systems).
>
> 3. Secure Intranet zone files - We don't want the dirty outside people to be
> able to resolve all Intranet objects, only specific ones.
>
> 4. All internal clients need to be able to resolve both Intranet and
> Internet
> names.
>
> Design:
>
> Here is what I have come up with.
>
> 1. Several (11) Sun boxes at hubs around the planet running QIP (QDNS) as
> rooted
> DNS servers for the company. They will contain all internal name and address
> information.
>
> 2. On these servers we will implement DNS "views" or conditional forwarding
> to a
> Bastion host in the DMZ. Any request that is not "company.com" will be
> forwarded
> to this name server who has a foot on both the Internet and the Intranet.
> This
> host will run a caching only name server and have allow-query access lists
> option enabled so that only internal queries will be answered. Zone transfer
> requests will be sent to internal name servers.
>
> 3. A spit DNS server on the perimeter network hold company.com "shadow" name
> space information. Basically pared down zone information about company.com
> advertising only those hosts and mail gateways that we want seen from the
> Internet. This server is authoritative for comapny.com on the Internet.
>
> Opperation:
>
> Here is how I believe this should work.
>
> 1. An internal client requests "www.company.com" - Normal DNS function, uses
> internal name root name servers to answer client requests.
>
> 2. An internal client requests "www.suborg.company.com" - Normal DNS
> function,
> same deal as above
>
> 3. An internal client requests "www.anothercompany.com" - Root server
> forwards
> request based on it's view option to the Bastion host who performs recursive
> lookups on the Internet.
>
> 4. An external client requests "www.company.com" - Since the "Shadow" name
> server is authoritative for "company.com" on the Internet, and
> "www.company.com"
> is advertised in it's zone, it will answer the request.
>
> 5. An external client requests "mypc.company.com" - Since the "Shadow" zone
> file
> contains nothing about this object DNS will return "host not found".
>
> Questions: (finally)
>
> 1. What happens if "www.company.com" is on the Internet? - Will an internal
> client be able to resolve it? Or, will the internal root servers simply
> return
> "host not found"?
>
> 2. Is the only answer here to enter the external name-to-address information
> for
> external objects on the internal root servers by hand?
>
> 3. Is there any other problems with this design that I haven't thought of?
>
> Thanks for any help that you can offer. Please send replies to
> christopher.fellows at ins.com as I don't have constant access to the list
> email.
> Have a great one.
>
> Chris F