| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1816.1 | nameservers not in sync | NETRIX::"[email protected]" | Jan-Erik Pedersen | Wed Feb 26 1997 12:05 | 12 |
| Ask yourself the question:
Why are the two nameservers for xyz.com not in sync.
My guess is that you run a primary nameserver both on the firewall and
on the NT box. This is not a good idea, you have chose which will be primary
and which will be secondary.
If not make sure that the secondary gets updated, eg.
check that named-xfer runs correctly
make sure the serial # gets updated.
[Posted by WWW Notes gateway]
|
| 1816.2 | | ZEKE::ranger.zko.dec.com::dilsworth | Keith Dilsworth | Wed Feb 26 1997 13:48 | 23 |
| Back when I worked with the Firewall Service this was called "Split
Brained DNS".
redgate had a primary SOA record for xyz.com that only had entries
for nodes on the red net (203.152.13.xxx) and had a wild card MX
entry like "*.xyz.com. IN MX redgate.xyz.com." Anything from
the outside trying to resolve using redgate could get to nodes on the
red net and any mail destined to blue net would be passed to redgate.
redgate, www and other nodes on the red net (203.152.13.xxx) would
have their resolv.conf pointing to 10.1.1.2 so all DNS translation
initiated from those hosts would get the real internal IP Addresses.
The primary SOA for xyz.com on 10.1.1.2 would have all the real names
and IP addresses for all 10.xxx.yyy.zzz nodes and 201.152.13.xxx
nodes. 10.1.1.2 would also have a primary SOA for
13.152.201.in-addr.arpa and 10.in-addr.arpa.
IT IS VERY IMPORTANT THAT 10.1.1.2 HAVE A "FORWARDERS 203.152.13.33"
ENTRY IN NAMED.BOOT. This tells 10.1.1.2 if it doesn't have the
answer and can't reach a root name server (it can't) then to pass the
request though redgate who can reach a root nameserver.
|
| 1816.3 | | QUICHE::PITT | Alph a ha is better than no VAX! | Thu Feb 27 1997 05:13 | 17 |
| Re .2: This is NOT NOT NOT called split brain DNS. This is the other sort of
DNS, called open DNS. (Split brain DNS is also referred to as Hidden DNS.)
The problem here is alluded to in .1. When you run open DNS, the whole point is
that your internal DNS for the top level domain is the same as the external DNS.
In your case, you've broken this rule.
You will fix the problem immediately, if you synchronise the internal and
external (firewall) DNS servers, and ensure that all records from both servers
are included.
I would, however, suggest you think hard about why you're doing open DNS in the
first place. I've yet to come across a customer who really needs it. Digital
uses open DNS, and I understand the reason for that concerns our large number of
internal DNS servers and subdomains.
T
|
| 1816.4 | Internal DNS leakage ? | TLAV01::CHENSAK | | Thu Feb 27 1997 10:29 | 7 |
| Thanks for your help. I think that I will configure the firewall to be
the secondary name server of the internal DNS (exchange.xyz.com), this
will let the firewall to know the exchange.xyz.com. But what about the
internal DNS information , I guess that the outside world could query
the internal DNS information. If I 'm wrong ,please clarify me.
chensak
|
| 1816.5 | | QUICHE::PITT | Alph a ha is better than no VAX! | Thu Feb 27 1997 10:40 | 6 |
| You are absolutely right. That is the point of Open DNS.
If you want the internal DNS hidden from the outside, as would usually be the
case, then use hidden DNS!
T
|