Is it Bad Practice to Use NS Server that is Usually Turned Off?

Barry Margolin barmar at
Thu Jun 26 02:50:39 UTC 2008

In article <g3uer6$28of$1 at>, s.fenster at wrote:

> Hi,
> I want to know if it is considered bad practice to use a name server
> that is usually not responding.  My goal is to quickly be able to
> change name servers in the case of a disaster at the main site.
> Our setup is the following:
> ISP hosts our zone file, which looks like this:
> myserver    IN NS
>                  IN NS
>    IN A
>    IN A
> I control and have A records for my servers.  In order
> to prevent requests from going to wan2 (which is our backup site), I
> would disable access to that dns server.  As I understand it, there is
> no priority for NS records like there is for MX records.  I understand
> this might create more traffic on, but it may be an acceptable
> consequence.
> My question is, will my users see a delay when resolving
> I saw that BIND uses a relatively smart (as
> compared to round robin) algorithm to determine which name server to

Most DNS servers keep track of nameserver response times, and prefer the 
ones with better response times.  But they also periodically try the 
other servers, so that they'll detect when their performance improves.  
So this will result in occasional lookup delays.

> query.  I assume my ISP is using BIND (but I am not sure).

And even so, what you care about is the ISPs for all the people who 
might try to access your domain.

> The alternative is to use a managed DNS service that detects down
> links and switches NS servers.  It would be great if my ISP did this,
> but I suspect they don't.  And I don't want to wait for them to change
> my zone file and wait for it to propagate.  I also don't want to give
> my DNS over to a managed provider - I like to be in control of my DNS.

Why don't you keep both nameservers running, but update the zone 
contents when you need to fail over?  Do you really need to avoid DNS 
traffic to the backup site?

Barry Margolin, barmar at
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

More information about the bind-users mailing list