topic Re: create a stub zone on BIND9 in Operating System - Linux

create a stub zone on BIND9

'chris' — Thu, 05 Mar 2009 11:25:10 GMT

hi

At the moment our DNS servers are authorative for the main domain via slave zones, which will be generating unnecessary replication traffic.

Howto create stub zone instead of slave zone on BIND 9.3.4?

Re: create a stub zone on BIND9

Ivan Ferreira — Thu, 05 Mar 2009 13:31:00 GMT

Stub zones are used for delegation. It only transfers the NS records. I don't know your final objective, but probably you need a conditional forwarding (proxy) zone.

Just remember, that with secondary zones, you also have redundancy, and if the zones are static, then you won't get mostly traffic.

http://www.zytrax.com/books/dns/ch4/

Re: create a stub zone on BIND9

'chris' — Thu, 26 Mar 2009 15:54:16 GMT

thx, I've created a forward zone:

zone "mydomain.net" {
type forward;
forwarders {
10.10.100.3;
10.10.100.4;
};
};

but my BIND seems not to cache the queries.
how to create a forward zone to cache queries in case the forwardes are unreachable?

Re: create a stub zone on BIND9

Ivan Ferreira — Thu, 26 Mar 2009 17:51:32 GMT

How did you determined that is not caching requests?

NS records are not cached.

Re: create a stub zone on BIND9

'chris' — Thu, 26 Mar 2009 22:18:08 GMT

thx, but howto create a stub zone under BIND?

Re: create a stub zone on BIND9

Ivan Ferreira — Fri, 27 Mar 2009 12:34:54 GMT

It's similar to a secondary zone:

zone domain_name IN {
type stub;
file path_name;
masters { ip_addr; } ;
};

Re: create a stub zone on BIND9

'chris' — Sun, 29 Mar 2009 15:46:41 GMT

thx, but do I get more redundancy and less synchronisation traffic with the stub instead of secondary zone?

Re: create a stub zone on BIND9

Matti_Kurkela — Mon, 30 Mar 2009 08:36:46 GMT

A stub zone does not give you any meaningful redundancy. It only replicates the NS records from the zone's master server, so that your server knows where to refer the queries to. Anything beyond that is caching.

If there is a network problem, the data you'll need may or may not be in the cache, depending on previous traffic and TTL values.

Slave zones are the only way to guarantee that your server has a full up-to-date copy of the master server's zone. If the amount of replication traffic is a problem, you should examine the reasons for it.

If the replication traffic is caused by a large number of dynamic DNS updates, you should consider putting the workstations (which usually create the most of the DNS updates) into a separate zone (a sub-domain). Then you can be a slave for the zone that has the server addresses only.

If there are not that much DDNS updates, another reason for excessive replication traffic might be poorly-chosen time values in the SOA record of the zone. These values determine how often the slaves check if the master zone has been updated. If your master server can send DNS NOTIFY messages to the slaves, you can set the update-check timeouts to reasonably large values.

Does your master server support incremental DNS zone transfers (RFC 1995, IXFR)? If it doesn't, any change in the domain causes the slaves to transfer the entire zone file from the master. If incremental zone transfers are supported, only the changes are transferred. That should cut back the amount of zone transfer traffic.

MK