DNS: Difference between revisions

From 44Net Wiki
Jump to navigation Jump to search
Cross (talk | contribs)
Skeletal DNS page
 
Cross (talk | contribs)
No edit summary
Line 1: Line 1:
= DNS: The Domain Name System =
= DNS: The Domain Name System =


The Domain Name System is the mechanism by which symbolic host names, such as ''kz2x.ampr.org'' are translated into numeric host IP addresses, such as 44.44.48.2.  It is heavily used on AMPRNet. Cleverly
The Domain Name System is the primary mechanism by which symbolic host names, such as ''kz2x.ampr.org'' are translated into numeric host IP addresses, such as 44.44.48.2.  It is implemented as a network protocol, understood by both clients and servers, that use the network itself to effect translation. The DNS protocol is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs; the current revision of the DNS specification is in [https://datatracker.ietf.org/doc/html/rfc1035 RFC1035].  It is used heavily on AMPRNet.
 
DNS is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs.  The current revision of the DNS specification is in [https://datatracker.ietf.org/doc/html/rfc1035 RFC1035].


== Historical Background ==
== Historical Background ==


Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer.  However, as the network grew, this quickly became untenable: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort.  Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.
Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer.  However, this quickly became untenable as the network grew: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort.  Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.


A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses.  Early work around this idea ultimately lead to DNS.
A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses.  Early work around this idea ultimately lead to the design of the DNS.


== Concepts ==
== Concepts ==


The DNS on the client/server model, in which ''client'' machines send name service queries to DNS ''servers'' scattered around the Internet, which in turn, provide answers.  The process of answering a query related to a host name is called "resolution."  Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server.
The DNS uses the client/server model, in which ''client'' machines send name service queries to DNS ''servers'' scattered around the Internet, which in turn, provide answers.  The process of answering a query related to a host name is called "resolution."  Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server.  The DNS allows clients to make requests about a fixed set of types of information for a particular ''domain name''.  For example, one might request make an "address" (or "A") query for a name.  For each name, a set of "records" corresponding to these  information types name are input by an administrator and held in DNS server; these are called "resource records" or "RRs".


=== Domains, Zones, and Authority ===
=== Domains, Zones, and Authority ===
Line 20: Line 18:


Collections of domains that fall under a single administrative entity form "zones".  A zone is said to be authoritative for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries.  Authoritative responses to queries always override cached data.
Collections of domains that fall under a single administrative entity form "zones".  A zone is said to be authoritative for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries.  Authoritative responses to queries always override cached data.
Just as domain names themselves are hierarchical, so too are DNS servers arranged into a logical hierarchy, with different servers serving information about different levels of the hierarchy.  At the root are a set of well known "root servers," the IP addresses of which are well-known: these provide information about top-level domains and specifically include references to the name servers that are known to be authoritative about those domains.


=== Servers, Resolvers, and Stub Resolvers ===
=== Servers, Resolvers, and Stub Resolvers ===


As mentioned, clients resolve queries about domain names by sending those queries to servers, but different kinds of servers play different roles:
As mentioned, clients resolve requests for information about domain names by sending queries to servers, but different kinds of servers play different roles:


* Servers, or Authoritative Servers, are the ultimate sources of authority for domains under some zone.  They accept queries answer them, either with resolved data or with an error, such as when a query is issued for name that does not exist.
* Non-Recursive, Authoritative Servers, or just Authoritative Servers, are the ultimate sources of authority for domains under a zone.  They accept queries answer them, either with resolved data or with an error, such as when a query is issued for name that does not exist.
* Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply.  They then usually cache the results so that subsequent requests for the same query can be answered quickly.  The cached data expires once its TTL is exceeded.
* Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply.  They then usually cache the results so that subsequent requests for the same query can be answered quickly.  The cached data expires once its TTL is exceeded.
* Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them the rest of the program.
* Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them the rest of the program.


Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns about what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use.
Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns about what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use.

Revision as of 12:25, 17 May 2024

DNS: The Domain Name System

The Domain Name System is the primary mechanism by which symbolic host names, such as kz2x.ampr.org are translated into numeric host IP addresses, such as 44.44.48.2. It is implemented as a network protocol, understood by both clients and servers, that use the network itself to effect translation. The DNS protocol is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs; the current revision of the DNS specification is in RFC1035. It is used heavily on AMPRNet.

Historical Background

Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer. However, this quickly became untenable as the network grew: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort. Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.

A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses. Early work around this idea ultimately lead to the design of the DNS.

Concepts

The DNS uses the client/server model, in which client machines send name service queries to DNS servers scattered around the Internet, which in turn, provide answers. The process of answering a query related to a host name is called "resolution." Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server. The DNS allows clients to make requests about a fixed set of types of information for a particular domain name. For example, one might request make an "address" (or "A") query for a name. For each name, a set of "records" corresponding to these information types name are input by an administrator and held in DNS server; these are called "resource records" or "RRs".

Domains, Zones, and Authority

Names are hierarchical, and organized into domains: Starting from ".", the "root", and descending through a "top-level" domain (TLD) such ".org", then through an organizational domain such as "ampr". Each such level forms a "domain", so that ".org" and "ampr.org" are separate domains. This organization provides resilience against collisions, since names need only be unique within a domain, and and facilitating separation of administrative concerns.

Collections of domains that fall under a single administrative entity form "zones". A zone is said to be authoritative for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries. Authoritative responses to queries always override cached data.

Just as domain names themselves are hierarchical, so too are DNS servers arranged into a logical hierarchy, with different servers serving information about different levels of the hierarchy. At the root are a set of well known "root servers," the IP addresses of which are well-known: these provide information about top-level domains and specifically include references to the name servers that are known to be authoritative about those domains.

Servers, Resolvers, and Stub Resolvers

As mentioned, clients resolve requests for information about domain names by sending queries to servers, but different kinds of servers play different roles:

  • Non-Recursive, Authoritative Servers, or just Authoritative Servers, are the ultimate sources of authority for domains under a zone. They accept queries answer them, either with resolved data or with an error, such as when a query is issued for name that does not exist.
  • Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply. They then usually cache the results so that subsequent requests for the same query can be answered quickly. The cached data expires once its TTL is exceeded.
  • Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them the rest of the program.

Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns about what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use.