Hello Bob,
Your situation is moderately common. Would it be acceptable to
employ an additional dns server?
You could place this DNS server on the internal DMZ. I will draw:
{ World } ------+
|
[router_ext]
|
=========ethernet_ext_dmz=========
|
|
[Internal_DNS_Server] [Firewall]
| |
| |
=========ethernet_ext_dmz=========
|
|
{Internal_Corporate_"Intranet"}
In this manner, the Firewall would run a proxy DNS server.
-
The "Internal_DNS_Server" would run a DNS server, and forward
all information he didn't know to the "Firewall".
* The DNS Server would also secondary all internal domains, as well
as the parent domain (or primary, irrelevant).
(this addresses your quandry wrt departmental DNS servers
accessing intranet zones)
-
Each departmental DNS server would then be primary for its domain,
and forward all other requests to the "Internal_DNS_Server".
-
This approach does two things that are relevant:
1/ Moves most load from Firewall to new DNS server
2/ Increases initial DNS query time (until cache is built)
department -> internal -> firewall -> source
This is one suggestion that may meet your needs.
Of course, another obvious solution is to upgrade/tune the
firewall so that it can handle the DNS requirements.
......... Bob Gammage is rumored to have said:
]
]
] BACKGROUND:
] Historically, all end-users at my company (three Class-B's
] spread across a PARENT domain and about 180 CHILD domains)
] have enjoyed unrestricted direct access to The Internet.
] In addition to being authoritative for the local-CHILD-domain,
] each CHILD NS's is a secondary for the PARENT (so each CHILD
] NS knows all its sibling NS's rather than query the PARENT NS
] for them) to improve inTRAnet communications.
] Now we are implementing tighter security. This involves a
] FireWall that will not pass DNS-Queries and the vendor's
] suggestion is to implement forwarding on all our existing NS's.
] I have been tasked to do this with minimal additional hardware
] and minimal impact to our users.
]
] Unfortunately, once we setup the forwarding (to the firewall)
] on the PARENT NS and got all the CHILD NS's setup to forward,
] we discovered that NameD had become too big a resource drain
] on the hardware to run the firewall software. Unacceptable.
]
] QUANDRY:
] Ideally, CHILD NS would know all other CHILD NS and be able to
] communicate with them directly on our intranet, and forward all
] non-PARENT (anything not *.PARENT) queries to a single point
] (be that the Firewall or some other internal choke-point).
]
] Unfortunately, forwarding appears to be an all-or-nothing
] proposition. So even if I create an internal-root NS (for
] the PARENT domain I assume) and replace the root cache on
] every other NS we have, I'm still unclear on how to gracefully
] choke queries of external NS's down to a single source
] internally.
]
] Without Forwarding :
] Root queries would be submitted directly to a Root NS
] (whether internal or external).
] *** Non-PARENT queries would be submitted directly to the
] appropriate external NS.
] Non-Local-CHILD queries would be submitted to the
] appropriate internal CHILD NS.
] *** This behavior is inconsistent with our FireWalling
] goals.
]
] With Forwarding :
] Root queries, Non-PARENT queries, and Non-Local-CHILD
] queries would all be submitted to the designated
] forwarders recipient.
] This behavior is inconsistent with our goal to minimize
] inTRAnetwork impact.
]
] Suggestions Welcome.
]
] Bob Gammage
] rlgammag @
use .
usit .
net
]
]
References:
|
|
