Centralizing all hostnames and IP address information on one central machine is a possibility even with DNS . This is not how DNS was intended to be used. Where we have geographical, political, economic, structural, or organizational boundaries, it may make sense to distribute the authority for managing a collection of hostnames and IP addresses to a delegated authority, a master name server. This is the basic idea behind how DNS operates across the Internet; many distributed hosts are authoritative for the hostnames/IP addresses within their zone. Further delegation is possible where it makes sense using the same criteria as before. Having a single master server within a zone imposes its own problems ”for example, if a single server becomes a Single Point Of Failure within the network. Introducing secondary servers distributes the responsibility among other machines in the network. Now we can see why DNS can be said to offer a distributed name resolution service.
A2:
A caching-only server will communicate with the designated name server for the local domain, normally primary master name server. This will be configured in an upper-level domain. When a caching-only server cannot resolve a query, it will contact a top-level name server. Through an iterative process, it will eventually establish the IP address of the local name server. It can then communicate with the local name server to load its cache with the requested hostname/IP address.
Caching-only name servers alleviate the pressure to resolve queries from other name servers. Although the process of loading its cache can be a little time consuming initially, once the cache is loaded in memory, it can resolve subsequent queries for the same hostname/IP address as quickly as any other type of name server.
A3:
The delegated name server need not update any of its configuration files to reference the delegating name server. If the delegated name server needs to contact a higher-level domain, it can use the hints file ( db.cache by default) to contact a top-level name server. A delegated name server may use the delegating name server as a forwarder , but this is not necessary and not always desirable.
A4:
It is highly unlikely that the configuration files work as they exist. There are two areas of conflict:
The ddns_address specified in /etc/dhcptab appears to be for another machine (192.1.2.2). The address specified should be the address for this machine. Currently, HP strongly suggests that Dynamic DNS updates from a DHCP server be configured on the same machine as the DNS server.
The zone " 1.192.IN-ADDR.ARPA " does not have an allow-update statement configured. This means that any IP addresses that are to be added dynamically to that zone will fail. The following line should be added to the zone definition:
allow-update { 192.1.1.1 ; };
A5:
As well as rndc-confgen , we can use the dnssec-keygen command. The main reason to use dnssec-keygen over rndc-confgen is that dnssec-keygen is guaranteed to create keys conforming to RFC2845: Secret Key Transaction Authentication for DNS ( TSIG ). The secret keys are stored in /etc/rdc.conf ( rndc configuration file) and /etc/named.conf (the named boot file).
