how to configure dns slave and dhcp

Sir, Thank you very much for the reply,

1. I too exactly want to host one linux box at each spoke and also able to manage to dedicate one linux box to function as dns slave where ever 15 and above users at spoke locations this linux box will work as dns slave but the ISP provider's cisco router at the spoke will be configured as DHCP server or dhcp realy please suggest me is this going to work.

2. we have many spoke locations where users are less than 05 here planning to tell ISP service provider to configure the cisco router at the spoke to point or forward to master dns  IP and also configure the same router for DHCP server .

3. At spoke is it required to configure DHCP server or DHCP realy please suggest

Request you to please suggest me in the above 1, 2  and 3, Thanks in advance.

The spoke becomes useless when it looses connectivity to the HUB.
Setting up a local DHCP and DNS server would let the spoke function if access to the HUB is lost.

Other than the HUB and Spoke setup, I have no idea what the inter dependencies there might be such that the spoke is useless if the HUB is inaccessible. etc.

What are the interactions if any, between/among the spoke users?

You could as point 2 suggest centralize everything where each spoke will forward the DHCP requests and dns queries back to servers at the HUB.

"you must first on the master configure allow-transfer and deny the spoke DNS servers in the list"

1. I did not understand deny the spoke DNS servers in the list  # request to please explain
2. How to deny the spoke DNS servers

Thanks in advance.

I do not believe I ever suggested a deny for the spoke.  Not sure what you mean; could you clarify.
Oh, the type should be define.
When setting up, you must first on he master configure allow-transfer and define the spoke DNS servers in the list.

allow-transfer {spokeA;spokeb;spokec;defined_acl;}
also-notify {spokeA;spokeB;spokeC;defined_acl;}

This can be within the options section at the top to apply globally, or per zone
zone "domain" {
type master;
file "pathtofile/domain';
allow-transfer {IPs; defined_acl;};
also-notify {IPs;defined_acl;};
}

Sir, sorry it is my mistake of understanding, finally before closing the post can you please tell me is it required to create the zone files at the slave server or only adding below entries in the named.conf.local file will do , master will automatically trasnfer the zones to slave, please help.

 [...]

        zone "orange.com" {
             type slave;
             file "/var/cache/bind/db.orange.com";
             masters { @ip_master; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type slave;
             file "/var/cache/bind/db.192";
             masters { @ip_master; };
        };

        -------------------------------------------------------------

You must create the entry for the zone in /etc/named.conf or the include file depending on your setup.

The file will be created when the zone is transferred in from the master.

Just to be clear the master does not transfer anything to the slave, the mechanism is that the slave contacts the master and retrieves the information.
The only thing the master does is to notify the slave instance that a change has occurred.
In your example above the notification will go out only if and when the NS record in the zone points to the slave dns server as well as the master.
In the event that the zone does not have an NS reference to the slave the refresh,retry is what will govern when the slave dns server will check with the master to see whether the zone has changed.

Hi sir, please suggest me

what entry should contain in the etc/resolv.conf of secondary master/save # should it require to point to the primary master server IP, please suggest.

2. in the secondary master/salve what should be the entry in the /etc/bind/named.conf.options, should it require to point to the primary master server IP address as the forwarder.

3. Also have added the A and PTR record of the secondary/slave server in the primary master server, i mean  seconday master/salve gets resolved by the primary master name server as these entries are added in the primary master server.

Please help , Thanks in advance.

The /etc/resolve.conf should refer to itself as the primary resolver this is what its task is, putting something else would at times get the local named service to send out the requests to resolve to the server listed there.

You have two issues here. In your setup, the named instance has two duties.
1) provide authoritative information about data in zones that it is retrieving from the master server.
2) Provide domain name resolution to local clients.

a forwarder falls into the second group.
Creating a forwarder on the slave instance that points to the master will mean that when the master server becomes inaccessible, the slave instance becomes useless since it will continue to forward requests to a system that is no longer available.
It is best to let each name service resolve information directly.  You could if you wish/must use forwarders to point them to the ISPs name servers (note you have to keep them up to date if the ISP changes) the forwarders from ISP1 will not respond to requests from IPs on ISP2.

When you add an entry to the zone on the master server and update the serial number, the master server notifies all servers listed in the Zone with the NS record and if your master configuration has also-notify {ip}; the IP.
Upon receipt of a notification, the slave instance will schedule the zone for a refresh this is why updating the serial number is extremely important.

If you do not list the slave server with an NS record in the zone and/or do not have the also-notify {slave;};, a notice will not be received and the zone will only be checked on the schedule set in the refresh setting.
If you do not update the serial number of the zone, the slave will no download the zone since it will not see a change. i.e. it has serialnumber for zone A as 12, you've updated zone A on the master server 20 times without altering the serial number.  Each time the slave bind service checks with the master effectively saying what is your serialnumber for zone A which always comes back as 12 which is what the serial number on the slave is.

Hi sir, thank you very much for the explaination, so far i am not updating serial number at the master as i use nsupdate for adding the A and PTR . please suggest me as long as i use nsupdate for adding entries of hosts updating the serial number manually is not required.

Please suggest me is this correct if wrong request to correct.

nsupdate automatically adjusts the serial numbers
nslookup -q=soa yorudomain.com master_server
nsupdate
nslookup -q=soa yorudomain.com master_server

The serial should be incremented by one.

Now all that remains is to make sure that both master and slave are referenced within the zone with ns records.
nslookup -q=NS yorudomain.com master_server

echo "update add yourdomain.com. IN NS <hostname of the slave>
" | nsupdate -v
then make sure your named.conf file is configured with the also-notify {slave_server_ip;}

Future updates will propagate at a quicker rate .

Hi sir, thanks for your valuable support, finally before closing the the post can i understand the below:

"For changes to propagate if you do not include the spoke dns servers in the zone, you should use the also-notify rule on the master and include all the spoke DNS servers"

Is it like if  A and PTR record of the spoke dns slave entries are added in the master zone file in this case also-notify is not required.

Please suggest.

Any zone that is accessed by the slaves should have the also-notify to make sure an addition is propagated in a timely fashion.
Listing all the slave servers as an NS record within each zone that is slaved.

Hi sir, thank you very much , added also-notify for each forward zone
Doubt:
is it required to define  notify no; for the reverse zones like the below or even in the reverse zone also notify to be defined please suggest.

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/var/cache/bind/db.1.168.192.in-addr.arpa";
--------------------------------

Why would you want to maintain the reverse zone without the data or at least without accurate data?

I am sorry for the confusion, since also-notify is defined in the options when so ever zone is updated also notify triggers the slave.  we are in the MPLS hub and spoke, master at hub and dns slave at each spoke location,

"I have created zone files for all the spokes in the master server with the "A "and "PTR" records of all the desktops/workstations available at each spoke,  when the DNS slave is configured at the spoke location, salve will contact the master and retrives the information hence on that particular spoke for all desktop/workstations salve becomes the dns server  hence not required to add A and PTR on the spoke dns slave

Please correct me if the above is wrong.

There is no need to explicitly specify notify no, which is the question of why you are adding it.

also-notify as a global setting is there in the event the zone omits a name server reference or a name server that was at that location has been replaced but was not replaced in the zone.

If you forget to update the list of the IPs in the also-notify {nameservers;}; where nameservers is an acl that includes all the name servers that you have, some spokes will have outdated information for reverse zone it might be ok, for the forward zones it could lead to some requests for hosts whose changes did not propagate as an issue.

The local DNS server will usually be the one that will receive the update from the local clients which the local dns server then will forward to its master server. When it reaches the server that has authority over the zone, the record will be added and the subordinates will be notified that a change has occurred.
I believe I previously covered the update cycle.

Thank you very much