Strange DNS problems: a challenge for experts who wanna try and help
Danny Mayer
mayer at gis.net
Mon Jan 28 05:10:05 UTC 2002
At 02:20 PM 1/27/02, Luca Morisi wrote:
>Hi to everyone and thank you in advance for your attention.
>I'll try and explain our DNS problem. I'm gonna be a little verbose,
>but I want to explain it as clearly as possible.
>
>We recently migrated our DNS primary server from Linux to Win2k.
>Since we had little experience with DNS issues, we probably configured
>the Win2k DNS server in a way that causes many random errors and we
>would appreciate very much some help.
If you insist on downgrading, expect problems.
>We have two registered host names to use as nameservers (I'll use fake
>names and fake IP addresses):
>NS1.OURCOMPANY.NET (212.200.200.1)
>NS2.OURCOMPANY.NET (212.200.200.2)
>
>When we installed Win2k Advanced Server on the PC, we probably made
>the first mistake, choosing a different domain name than
>OURCOMPANY.NET.
>So, now, we have our DNS server installed on a PC called:
>DNSSERVER.MACHINEDOMAIN.NET
>with the right NSI registered IP address (212.200.200.1).
That doesn't matter though you should change the name and domain
for consistency.
>Anyway, we went on with the configuration, hoping we could have DNS
>Win2k Server running on a PC with a different name than the one
>registered.
>We set up many forward zones, one for each domain we wanted to manage.
>Each zone has its own configuration file in %SystemRoot%\system32\dns
>folder (we didn't choose Active Directory integration).
>
>For each zone, we set up various resource records.
>The following is the content of our typical zone configuration file
>(remember: NS1.OURCOMPANY.NET and NS2.OURCOMPANY.NET are the two
>registered nameserver, while MACHINEDOMAIN.NET is the PC domain):
>
>;
>; Database file fakedomain.it.dns for fakedomain.it zone.
>; Zone version: 24
>;
>
>@ IN SOA ns1.ourcompany.net.
>admin.machinedomain.net. (
> 24 ; serial number
> 900 ; refresh
> 600 ; retry
> 86400 ; expire
> 3600 ) ; minimum TTL
>
>;
>; Zone NS records
>;
>
>@ NS ns1.ourcompany.net.
>ns1.ourcompany.net. A 212.200.200.1
>@ NS ns2.ourcompany.net.
>ns2.mediatechs.net. A 212.200.200.2
These A records are out of zone. You shouldn't be defining A records
belonging to a different zone. BIND will reject them.
>;
>; Zone records
>;
>
>@ A 212.200.200.7
>@ MX 10 ns1.ourcompany.net.
>www CNAME fakedomain.it.
>
>*******************************************************
>
>Please note: 212.200.200.7 is our web server IP Address, where IIS is
>configured to host www.fakedomain.it web site.
>
>We also set up a Reverse Lookup Zone:
>;
>; Database file 200.200.212.in-addr.arpa.dns for
>200.200.212.in-addr.arpa zone.
>; Zone version: 12
>;
>
>@ IN SOA ns1.ourcompany.net.
>info.machinedomain.net. (
> 12 ; serial number
> 900 ; refresh
> 600 ; retry
> 86400 ; expire
> 3600 ) ; minimum TTL
>
>;
>; Zone NS records
>;
>
>@ NS ns1.ourcompany.net.
>ns1.ourcompany.net. A 212.239.122.3
>@ NS ns2.ourcompany.net.
>ns2.ourcompany.net. A 212.239.122.5
These A records are also out-of-zone.
>;
>; Zone records
>;
>******************************************************************
>
>We didn't set up any PTR records (other possible cause of errors?)
Then there's no point to the above file.
>Anyway, this way everything SEEMED to work: web browsing and email
>connectivity seemed OK (the DNS primary server PC acts also as mail
>server, with Exchange 5.5.).
>
>As you can imagine, having named our DNS server PC as
>DNSSERVER.MACHINEDOMAIN.NET, a zone with the name MACHINEDOMAIN.NET
>was automatically created (with many subzones called _msdcs, _sites,
>_tcp, _udp: we didn't touch these ones, leaving the automatically
>created names, all pointing to MACHINEDOMAIN.NET and not to
>OURCOMPANY.NET).
ADS might not like that if it's wrong. If ADS is expecting a domain of
MACHINEDOMAIN.NET, just leave it.
>In order to set up in the zone the NSI registered host names
>(NS1.OURCOMPANY.NET and NS2.OURCOMPANY.NET), we filled in them
>manually, since we couldn't browse them. Then we thought it could help
>if we set a zone called OURCOMPANY.NET. In this zone, we created two A
>records called NS1 and NS2 with the right registered names and the
>right IP addresses, so we could
>browse them when creating a new zone. Anyway, we think that the
>IMPORTANT THING is the zone configuration text file.
>
>Now, you're wondering what the problem is.
>I said everything SEEMED to work, but it was a mere illusion.
>We realized that using certain Internet providers, SOME of the domains
>we manage
>(not always the SAME domains...) and only SOMETIMES don't work! If you
>try and load in a browser, let's say, WWW.FAKEDOMAIN.IT, the host is
>not found! You can try and ping it or fire a TRACERT command: same
>result! The strange thing is that this behaviour appears really
>RANDOM.
Not at all random. See below.
>NOT always the same domains are involved: for example, it happens that
>WWW.FAKEDOMAIN.IT doesn't work and WWW.OTHERFAKEDOMAIN.IT - which is
>configured in the same exact way on the same DNS server with the SAME
>Resource Records - works! We really can't figure out why this happens.
>At other moments, WWW.FAKEDOMAIN.IT works and WWW.OTHERFAKEDOMAIN
>doesn't.
>
>We think it depends on a DNS misconfiguration and on the provider's
>DNS servers not having the correct information about our DNS server
>and the domains we manage.
No, it's your domain, you are responsible for it.
>If we use other Internet providers, everything seems to work correctly
>and our domain names are always resolved without hesitation. The
>problem occurs with two providers (one of which happens to be the most
>used Italian internet provider), but probably other ones could have
>the same problem and we don't know yet. Very subtle and
>
>One interesting behaviour that could help understand our
>misconfiguration problem is that when WWW.FAKEDOMAIN.IT is
>unreacheable, FAKEDOMAIN.IT is perfectly reachable. It seems that the
>provider's DNS server cache has got the right information for
>FAKEDOMAIN.IT but NOT for the www CNAME record and, as you can see
>from the config file I reported above, CNAME appears to be correctly
>configured.
That's because webmedia1.mediatech.it which is where the www CNAME
points to does not exist on ns2, while ns1 points the www CNAME at
mediatech.it which does have an A record.
>Now, what can we do? Any suggestion would be greatly appreciated.
>We are wondering if the problem could be related to the difference
>between the PC domain name where Win2k DNS is running
>(MACHINEDOMAIN.NET) and the registered NSI host name
>(OURCOMPANY.NET)... We are seriously thinking to er-install everything
>from scratch...
No, but it doesn't help. If everything else is right, you can just rename
the machine.
>One thing I forgot to say is that our secondary DNS server is still
>running on a Linux box. It doesn't seem to have any problem: the only
>difference we noticed is that the zone files serial number are managed
>in different ways (Linux uses a date format, Win2k a single number).
That's the reason for your apparently random problems. You reset your
serial number on the master to be lower than the slave. The slave sees
that the value is lower than what it already has and does not do a zone
transfer since what it already has is more current. You cannot just
reset the serial number. See the archives (and it's most likely in the FAQ)
for details how to do this properly. Serial numbers need to be increasing.
Querying ns1.mediatech.net for the mediatech.it zone (line wrapped) shows:
mediatechs.it. 3600 IN SOA ns1.mediatechs.net.
admin.webmediadns1.net. 24 900 600 86400 3600
while ns2.mediatech.net shows:
mediatechs.it. 86400 IN SOA ns1.mediatechs.net.
postmaster.mediatechs.net. 2001051401 10800 3600 604800 86400
24 < 2001051401. The randomness happens because sometimes a client
gets ns1 and sometimes ns2 and ns2 is not in synch with ns1.
Also, upgrade the version of BIND you are running on ns2.
8.2 is way out of date and vunerable to lots of attacks. Don't hide your
problem domain names next time you post, it makes it more difficult to help
you out.
Danny
More information about the bind-users
mailing list