DNS is implemented as a distributed database with “weak” replication mechanisms. The term “weak” refers to the fact that the replicas are updated across the network, according to predefined schedules and/or trigger and notification mechanisms. This approach can result in some delay in the update process which can (sometimes) become noticeable for the end users.

The master copy of DNS data for a particular domain is stored and maintained in a zone file at the Primary Name Server to which a domain has been delegated. Note that a particular host (a name server) can support many different domains at the same time, both as a master and as a slave name server for distinct domains.

In order to maintain consistency, the terms “Master Server” (or simply “master”) and “Slave Server”(or “slave”) are used. For most aspects the term “Master Server” is equivalent to the (traditional) notion of a “Primary Name Server”, and the term “Slave Server” is equivalent to “Secondary Name Server”. Explaining the subtle implementation differences that were introduced in BIND for version 9, which led to the change in terminology is beyond the scope of this book.

In order to ensure proper operation of the whole system, the types of data stored in the database (RRs:resource records) and the flow of information between the servers and the clients (resolvers) need careful attention. One of the most important aspects here is that there is no “fixed” relationship between the types of records stored in the database (e.g. type A for an IPv4 address, type AAAA for an IPv6 address) and the transport protocol used to send data back and forth between name servers and between name servers and a resolver (IPv4 or IPv6).

Indeed, it is perfectly normal these days to already store IPv6-related data in some zones (in the distributed database), but to still use IPv4 to submit queries, perform recursion (also known as “treewalk”) and return the results. Also, most of the zone transfers between slave servers and a master server actually use IPv4 (TCP) for the data transfer.

These considerations apply equally to communication with the root name servers and the TLD name servers.

Using this approach has the big advantage that the software in the existing system of nameservers (root, TLD, second level domains) requires very little change. In order to preserve the stability of the DNS for the Internet, the community is reasonably reluctant to embark on big or hurried upgrade projects.

The big disadvantage of this approach is the fact that end systems (usually hosts) typically still need an IPv4 protocol stack to talk to the DNS, even if the applications would already be able to use IPv6 exclusively. If this dual-stack method is not appropriate, then a more complex system of resolvers and (forwarding or translating) name servers needs to be deployed. This can take care of the continued IPv4 address space consumption but adds complexity, and sometimes single points of failure, to the whole systems.