Strange DNS problems: a challenge for experts who wanna try and help
Danny Mayer
mayer at gis.net
Tue Jan 29 02:49:25 UTC 2002
At 04:13 AM 1/28/02, Luca Morisi wrote:
>Dear Danny,
>
>thank you so much for your kind and quick reply.
>You have to excuse our little knowledge of DNS issues.
>I have some more questions for you, regarding your reply, in order to
>definitely fix our problems:
>
>1) when you say that the A records in our typical zone configuration
>file are out-of-zone (and BIND will reject them), you mean that we
>should DELETE them? And only leave:
>@ NS ns1.mediatechs.net
>@ NS ns2.mediatechs.net
>??
Yes. mediatechs.net is a different domain from mediatechs.it.
>2) we don't understand this sentence of yours (in reply to the fact
>that when www.mediatechs.it is not reachable, mediatechs.it (without
>www) is perfectly reachable):
>
>"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."
ns1 ands ns2 have different data even though they are both authorative for
the mediatechs.it domain. That means that either the are both masters
Which they shouldn't be, or one is a master and the other a slave and
the zone transfer is not being done. In your case, because the SOA serial
number of the slave (ns2) is greater than the serial number of the master
(ns1), the slave see that it has a later version of the zone than the master
and does not need to update the zone. You need to set the serial number
of the master to be greater than the serial number of the slave so that the
zone transfer can take place. You cannot arbitrarily change the serial
number to anything you want without consequencies. The serial number
must be a monotonically increasing number. You cannot decrease it
with some magic explained elsewhere in the archives.
mediatechs.it now has the same serial number on both ns1 and ns2.
Did you change the serial number of the slave or delete the zone?
>Could you please explain it again? You mean that the problem is the A
>record in the NS1 zone "mediatechs.it" (as you explained above)?
>Should we delete it and, this way, solve the "www" problem?
It has nothing to so with the A record in this case, but you should delete
it or the slave may reject the zone.
>3) The serial number issue: last week (on thursday) we manually
>modified the serial number of one of our NS1 zones (fcbsim.com), just
>to see if the fact that NS2 serial was higher than NS1 serial was
>causing our problems. Even though now NS1 serial for fcbsim.com is
>higher than NS2, in the last days this domain had the same problems
>the other ones had. By the way, Win2k has correctly increased the
>manually set serial number for fcbsim.com, so we don't understand when
>you say that "we can't just reset it". All the same we're gonna search
>the archives as you suggested. We know we are really ignorant about
>these things.
I see nothing wrong with fcbsim.com.
Danny
>If you could give us further help by answering our questions, we would
>appreciate it very much.
>We'll find the way to return the favour!
>
>Regards
>
>Luca
>
>
>Danny Mayer <mayer at gis.net> wrote in message
>news:<a32mk1$m33 at pub3.rc.vix.com>...
> > 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