Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Root DNS Server fall-over from Master to Slave problem

0 views
Skip to first unread message

Thane

unread,
Feb 23, 2002, 3:08:33 PM2/23/02
to

My ISP just cut my connection and will not be able to fix it for
several days. We have a backup web server in another location.

What we don't understand is that lookups against the root servers we
are still getting the IP for the primary web server. The master DNS
server is also cut off and the secondary web server has the new IP
address for the failover web site.

Since we have had recent problems, our ttl has been set to one hour.
Why aren't the root servers realizing that the master server is down
and check the slave?

Thank you,

TT

Simon Waters

unread,
Feb 23, 2002, 3:44:42 PM2/23/02
to

Thane wrote:
>
> Why aren't the root servers realizing that the master server is down
> and check the slave?

They don't realize anything.

The name servers for your parent domain, not usually the root
nameservers unless you have a very important domain, always
return the address of all nameservers, and other nameservers
querying the DNS will use all the nameservers listed until they
get an answer.

If you want more help post the domain name.

Thane

unread,
Feb 24, 2002, 4:04:03 AM2/24/02
to

Simon,

The domain, bahai.org has fixed by our changing the domain record.
That kicked in sometime this afternoon. Below is another domain that
we have that we have not altered. This is what the bahai.org record
would have looked like except the ttl settings were lower, I believe.

Until we changed the domain record, we were being directed to the
..139.18 address. The slave servers had been changed to point at a
backup server.

I understand we are not a major domain, but why does list a secondary
DNS server when registering a domain is the root is not going to
provide only the address of the primary server?

==TT

;; ANSWERS:
globalprosperity.org. 86400 A 208.218.188.52

;; AUTHORITY RECORDS:
globalprosperity.org. 86400 NS ns1.bwns.org.
globalprosperity.org. 86400 NS newdns.juxta.com.
globalprosperity.org. 86400 NS newmail.juxta.com.

;; ADDITIONAL RECORDS:
ns1.bwns.org. 86400 A 216.236.139.18
newdns.juxta.com. 60 A 216.232.79.116
newmail.juxta.com. 60 A 216.232.79.115

Fred Viles

unread,
Feb 24, 2002, 4:30:32 AM2/24/02
to
tter...@hotmail.com (Thane) wrote in <a58ss1$1...@pub3.rc.vix.com>:

The gTLD servers never "check" your DNS servers for anything, because
they don't accept recursive queries. I would *guess* that the name
you are using for your website has been registered as a nameserver,
so there is an A record for it in the TLD zone. You will have to
submit a host record update request to change it (or delete it, if it
is not actually delegated-to).

Guesswork would not be necessary if you had mentioned the domain name
you are asking about.

- Fred

Simon Waters

unread,
Feb 24, 2002, 5:54:08 AM2/24/02
to

Thane wrote:
>
> globalprosperity.org.

This domain seems to be working fine at the DNS level.

juxta.com look like they may need a bit more of a clue on DNS
configuration.

If the Internet loses access to the juxta.com servers (On
sequential ip addresses, which is usually a bad sign for
redundancy) this domain will stop resolving, as your DNS server
is not listed in the delegation data.

Juxta are using an old version of BIND with known security
flaws, and have extrememly unusual and low values in their SOA
record for various timeouts. It's possible (likely I'd suggest)
their DNS isn't very reliable as a consequence.

If they were my ISP I'd kick them hard about why their DNS is so
strangely configured.

Juxta have featured here before.

Thane

unread,
Feb 24, 2002, 11:15:39 PM2/24/02
to

Fred & Simon,

Thank you for your help. I'm not very good at DNS, yet.

Fred: the domain name, bahai.org, was in my message. It was just that
we had already shifted the domain records to point to the slave unit
as the new master so as to get around the problem we had with users
not reaching the slave unit. I didn't want to give that domain name
since everyone would have seen it working. The other domain, on the
other hand, was not changed since it is not really used. I could not
get into the DNS server to copy the zone records.

> Guesswork would not be necessary if you had mentioned the domain name
> you are asking about.

Let me see if I can summarize what you're saying.

1. Juxta needs a newer version of Bind.
2. Adjust the SOA values.
3. Check out delegations.

A couple pieces of additional information that might be helpful.

1. The two servers at Juxta are on indeed on the same network, but
they are never master DNS servers.
2. The regular master -- off line now thanks to my ISP -- is on our
web server, but the dns name is not the same web server name. We
learned this lesson the hard way some months ago.

The part that I'm still unclear on is what is suppose to happen with
the master DNS server goes off-line. We had our backup server on-line
and yet typing in the URL just got a message about the domain not
being findable. Is there someting in our DNS record that stopped the
user from finding the slave DNS server?

Thanks again for your help.

==TT

Sparro, Dave

unread,
Feb 25, 2002, 11:28:37 AM2/25/02
to

The first thing you have to be clear on is that DNS is _not_ a
Primary/Secondary failover type environment, it's a distributed Master/Slave
environment. The only distinction between a master and a slave is where
they get their information. A master server for a domian gets its data from
a configuration file. A slave gets its information from another server (It
doesn't even have to be a master server).

When you list the authorative name servers during a domain name
registration, that's all you're doing. It's an unordered list of servers
that (should) have more specific DNS information for hosts in that domian.


Getting back th the SOA problems others have mentioned, the problem is as
they are set now, the slave servers are set to "forget" everything in the
domiain if they can't communicate with the master for about 40 minutes.

Dave


> -----Original Message-----
> From: tter...@hotmail.com [mailto:tter...@hotmail.com]
> Sent: Sunday, February 24, 2002 9:58 PM
> To: comp-protoc...@isc.org
> Subject: Re: Root DNS Server fall-over from Master to Slave problem
>
>
>
{SNIP}

0 new messages