DNS From Dummies_v 0 1

DNS FROM DUMMIES

DNS by Javi & Leo

INDEX 1. GENERAL INFORMATION ……………………………………………………………………4 1.1 - Introduction 1.1.1 - The DNS protocol role 1.1.2 - Logical names vs. numerical identifier 1.1.3 - OSI stack & packet shape 1.1.4 - DNS and revDNS 1.1.5 - Official documentation: the RFC's for DNS Eliminated, directly in documentation chap 4

[note:1034-1035 & more] –

1.2 - General structure …………………………………………………………………..…….9 1.2.1 - RIPE IP European registry 1.2.2 - Official registries & references 1.2.3 - National registries 1.2.4 - Registrars 1.2.5 - DNS tree, TLD, subTLD 1.2.6 - Hierarchical structure & recursive resolution: how to reach the right IP 1.2.7 - Authoritative servers, zone transfers 1.2.8 - Registrar vs. maintainer: who do what? 1.2.9 - How to read and interpreter fields in a query (example)

2. SERVER SIDE SW …………………………………………..………………………………….. 2.1 - Bind & Microsoft DNS Server 2.2 - Zone Files; record, entries, fields - TTL 2.3 - RR types: SOA,A,MX,PTR,CNAME,TXT, SPF, NS & others 2.4 - Examples: - use of A - use of PTR - MX record - use of CNAME - use of TXT and SPF - Domain zone for MBE Colt

3. CLIENT SIDE SW ………………………………………………………………………………25 3.1 – Nslookup 3.1.1 - Flags and their use 3.1.2 - examples 3.2 – Dig 3.2.1 - flags & use 3.2.2 - examples (exaustive) 3.3 - Online tools: Ping, lookup, trace, whois, dns records, dig, MX Lookup, SPF check

DNS from Dummies by Javi & Leo

2

4. DOCUMENTATION 4.1 - Useful books 4.2 - Online & free documentation

[& link to official RFC's]

4.3 - Common terms

DNS from Dummies by Javi & Leo

3

1. GENERAL INFORMATION 1.1 – Introduction 1.1.1 – The DNS protocol role

The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166. The Domain Name System makes it possible to assign domain names to groups of Internet users in a meaningful way, independent of each user's physical location. Because of this, World-Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite meaningful URLs and e-mail addresses without having to know how the machine will actually locate them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated. In general, the Domain Name System also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet. Other identifiers such as RFID tags, UPC codes, International characters in email addresses and host names, and a variety of other identifiers could all potentially utilize DNS. The Domain Name System also defines the technical underpinnings of the functionality of this database service. For this purpose it defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite (TCP/IP). The DNS protocol was developed and defined in the early 1980s and published by the Internet Engineering Task Force

DNS from Dummies by Javi & Leo

4

1.1.2 - Logical names vs. numerical identifier As we have seen, in the internet working structure, the DNS protocol has the fundamental task to dynamically mapping the correspondence between logical names of internet resources, normally well managed by humans, and their relative numerical address expressed in a 4-byte dotted notation, well managed by binary machines. Whenever a user or a program makes the request of any resource, by simply clicking an hyperlink in a webpage, by sending a message via email or an appliance that need the exact time from an NTP server, the DNS system allow them to reach the needed resource in internet. Hereby we can also see the particularity of DNS protocol: even if it’s an Application Layer protocol, as WWW,SMTP or NTP, it works ‘under’ and supporting all the other Application protocols, obviously excepted those that requires a normal binary interaction, for example a VPN tunnel.

This fundamental role of DNS protocol, is the main reason because is frequently involved in a lot of issues, normally masking an unreachable resource (for some name resolution problems), with his physical unavailability. One of the most important side effects of DNS system, is that it separate the name of a resource from his physical location, maintaining consistency of all internet’s information stored into the servers. For example a link to an external webpage, will always works if referred by his logical name (i.e. www.multisite.com/site1/home3/page5/image4.jpg ), also if the server location (and so his IP address) changes, because the DNS system has in charge to retrieve the up-to-date IP address of the resource we need. This is possible because the information pairs between logical names and their relative IP addresses are stored in a centralized manner in a distributed database, and more important, in a logical hierarchical structure that allows an intrinsically recursive and very faster resolution of names. Normally after a couple of DNS queries, the IP address of a resource is available to the requester.

DNS from Dummies by Javi & Leo

5

We’ll see the logical details of the distributed hierarchical database of DNS system and how a resolution is made in chapter 1.2 We finally would like to notice that the paradigm of layering of addresses that DNS system follow, it’s extensively used in internet technology. One layer below the same role is taken by ARP, that allow the pairing and resolution between an IP address and the hardware physical address associated with it.

1.1.3 - OSI stack & packet shape As we noticed in the previous paragraphs, DNS it’s an Application layer protocol, but is ‘special’, because normally used by other protocols of the same layer in order to reach the correct destination.

As his most important function is to map logical names and address, we can also see some diagrams in which DNS protocol stands between transport layer and the other Application layer’s protocols. This ‘support’ function of DNS protocol not appear in this picture, but we can imagine a graphical situation similar to ARP protocol, as we can see above and as noticed at the end of previous chapter.

We can take a quick view to the DNS header and packet shape.

DNS from Dummies by Javi & Leo

6

The below image begin from layer three (IP) and you have obviously imagine that all this packet will be inserted into a layer-2 packet, i.e. it’s the variable - from 46 to 1500 bytes ‘data’ field of a canonical layer-2 packet

On the upper headers the only thing to be noticed from our point of view it’s that in case of a query, the ‘Destination port’ is normally the standard 53. For an answer it’s obviously the ‘Source port’ that take the 53 value. The interesting fields in the header of the ‘DNS Data’ section are: -

Query ID: unique identifier for a query, permit association between question and answer; QR: this bit take the value 0 if it’s a query, 1 for an answer from DNS server Opcode:4 bits field, normally take the value 0000 that stands for ‘query’; AA: take the value 1 if it’s an Authoritative Answer; TC: take the value 1 if the answer is truncated RD: Recursion Desired, set to 1 if client wish that server perform the recursion of the lookup RA: recursion Allowed, set to 1 if the server can recurse the lookup for the client Z: must be all 0 Rcode: response code from the server;

DNS from Dummies by Javi & Leo

7

-

Question count/Answer count/Authority Count/Additional record Count: indicate the number of the relative fields filled in the ‘DNS question or answer data’. We will see in details how this field are filled in a question/answer example.

You can found a complete reference of the DNS parameters for example at: http://www.iana.org/assignments/dns-parameters

1.1.4 – DNS and revDNS

Reverse DNS lookup or reverse DNS resolution (rDNS) is the determination of a domain name that is associated with a given IP address using the Domain Name System (DNS) of the Internet. Computer networks use the Domain Name System to determine the IP address that is associated with a given domain name. This process is also known as forward DNS resolution. Reverse DNS lookup is the inverse process of this, the resolution of an IP address into its designated domain name. The reverse DNS database of the Internet is rooted in the Address and Routing Parameter Area (arpa) top-level domain of the Internet. IPv4 uses the in-addr.arpa domain and the ip6.arpa domain is delegated for IPv6. The process of reverse resolving an IP address is facilitated with the pointer DNS record type (PTR record). Internet standards documents (RFC 1033, RFC 1912 Section 2.1) specify that "Every Internet-reachable host should have a name" and that such names are matched with a reverse pointer record.

[¿Some more? ¡Leo have to fill!]

DNS from Dummies by Javi & Leo

8

1.2 - General structure

1.2.1 - RIPE IP European registry

RIPE IP European registry The RIPE NCC is an independent, not-for-profit membership organisation that supports the infrastructure of the Internet through technical co-ordination in its service region. The most prominent activity of the RIPE NCC is to act as the Regional Internet Registry (RIR) providing global Internet resources and related services (IPv4, IPv6 and AS Number resources) to members in the RIPE NCC service region. The membership consists mainly of Internet Service Providers (ISPs), telecommunication organisations and large corporations located in Europe, the Middle East and parts of Central Asia. The RIPE NCC also provides services for the benefit of the Internet community at large. These services include: * Development and maintenance of the RIPE Database * Administrative support for the RIPE community. Other activities include: * Outreach activities with governments and industry-related organisations, * Management of one of the 13 root name servers (K-root), * Deployment of a routing database * Co-ordination support for ENUM delegations * Neutral measuring network that provides publicly accessible and authoritative statistics on the operation of the Internet. All RIPE NCC's activities and services are listed in the annual RIPE NCC Activity Plan.

1.2.2 - Official registries and references

A domain name registry, is a database of all domain names registered in a top-level domain. A registry operator, also called a Network Information Center (NIC), is the part of the Domain Name System (DNS) of the Internet that keeps the database of domain names, and generates the zone files which convert domain names to IP addresses. Each NIC is an organisation that manages the registration of Domain names within the top-level domains for which it is responsible, controls the policies of domain name allocation, and technically operates its top-level domain. It is potentially distinct from a domain name registrar. Domain names are managed under a hierarchy headed by the Internet Assigned Numbers Authority (IANA), which manages the top of the DNS tree by administrating the data in the root nameservers. IANA also operates the .int registry for intergovernmental organisations, the .arpa zone for protocol administration purposes, and other critical zones such as root-servers.net.

DNS from Dummies by Javi & Leo

9

IANA delegates all other domain name authority to other domain name registries such as VeriSign. Country code top-level domains (ccTLD) are delegated by IANA to national registries such as DENIC in Germany, or Nominet in the United Kingdom. Some name registries are government departments (e.g., the registry for Sri Lanka nic.lk). Some are co-operatives of internet service providers (such as DENIC) or not-for profit companies (such as Nominet UK). Others operate as commercial organizations, such as the US registry (nic.us). The allocated and assigned domain names are made available by registries by use of the WHOIS system and via their Domain name servers. Some registries sell the names directly (like SWITCH in Switzerland) and others rely on separate entities to sell them. For example, names in the .com TLD are in some sense sold "wholesale" at a regulated price by VeriSign, and individual domain name registrar sell names "retail" to businesses and consumers.

1.2.3 – National registries

A country code top-level domain (ccTLD) is an Internet top-level domain generally used or reserved for a country (a sovereign state or a dependent territory). All ccTLD identifiers are two letters long, and all two-letter top-level domains are ccTLDs. Creation and delegation of ccTLDs is performed by the Internet Assigned Numbers Authority (IANA) as described in RFC 1591, corresponding to ISO 3166-1 alpha-2 country codes with few exceptions explained below. The IANA (currently contracted to ICANN) is responsible for determining an appropriate trustee for each ccTLD. Administration and control is then delegated to that trustee, which is responsible for the policies and operation of the domain. The current delegation can be determined from IANA's list of ccTLDs. Individual ccTLDs may have varying requirements and fees for registering subdomains. There may be a local presence requirement (for instance, citizenship or other connection to the ccTLD), as for example the Canadian (ca) and German (de) domains, or registration may be open. Lenient registration restrictions on certain ccTLDs have resulted in domain names like I.am, tip.it, start.at and go.to. Other variations of ccTLD usage have been called domain hacks, where the Second-level domain and ccTLD are used together to form one word or one title. This has resulted in domains like blo.gs of South Georgia and the South Sandwich Islands (gs), del.icio.us of United States of America (us), and cr.yp.to of Tonga (to). (Non country code TLDs have also been used, like inter.net which uses the .net gTLD, probably the first domain hack ever.) Another form of hacks on ccTLDs results from speculation over typographical errors. The .co domain of Colombia has generated interest ever since it was realized that people might miss typing the "m" for sites in the .com domain, or similarly reach the domain .cm for Cameroon due to a missed "o". A number of the world's smallest countries have licensed their TLDs for worldwide commercial use. For example, Tuvalu and the Federated States of Micronesia, small island-states in the Pacific, have partnered with VeriSign and FSM Telecommunications respectively, to sell domain names using the .tv and .fm TLDs to television and radio stations.

DNS from Dummies by Javi & Leo

10

1.2.4 – Registrars

A domain name registrar is an organization or commercial entity, accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or by a national country code toplevel domain (ccTLD) authority, to manage the reservation of Internet domain names in accordance with the guidelines of the designated domain name registries and offer such services to the public. An end-user cannot directly register a domain and manage their domain information with ICANN. A designated registrar must be chosen. Prior to 1999, the only com registrar was NSI, but the approval of the SRS opened up the opportunity for other companies to be designated as registrars. Each ICANN-accredited registrar must pay a fixed fee of US$4,000 plus a variable fee. The sum of variable registrar fees are designed to total US$3.8 million. Only the designated registrar may modify or delete information about a domain name. The competition that the SRS created enables end users to choose from many registrars offering different services at varying prices. It is not unusual for an end user to switch registrars which invokes a domain transfer process governed by specific domain name transfer policies. When a registrar registers a com domain name for an end-user, it must pay a maximum annual fee of US$6.86 to VeriSign, the registry operator for com, and a US$0.20 administration fee to ICANN. Most domain registrars price their services and products to address both the annual fees and the administration fees that must be paid to ICANN. Barriers to entry into the bulk registrar industry are high for new companies without an existing customer base. Many registrars also offer registration through reseller affiliates. An end-user registers either directly with a registrar, or indirectly through one or more layers of resellers. As of 2008, the cost generally ranges from a low of about $7.50 per year to about $35 per year. The maximum period of registration of a domain name is generally 10 years. Some registrars are offering longer periods of up to one hundred years, but such offers involve the registrar renewing the registration for their customer. The one hundred year domain name registration would not be in the official registration database. Some packages of Internet services, such as web hosting, include the domain registration in the total package pricing.

DNS from Dummies by Javi & Leo

11

1.2.5 – DNS tree, TLD, subTLD

The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or more resource records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a collection of connected nodes authoritatively served by an authoritative nameserver. (Note that a single nameserver can host several zones.) Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of subdomains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone.

A domain name usually consists of two or more parts (technically labels), which are conventionally written separated by dots, such as example.com. * The rightmost label conveys the top-level domain (for example, the address www.example.com has the top-level domain com). * Each label to the left specifies a subdivision, or subdomain of the domain above it. Note: “subdomain” expresses relative dependence, not absolute dependence. For example: example.com is a subdomain of the com domain, and www.example.com is a subdomain of the domain example.com. In theory, this subdivision can go down 127 levels. Each label can contain up to 63 octets. The whole domain name may not exceed a total length of 253 octets. In practice, some domain registries may have shorter limits. * A hostname refers to a domain name that has one or more associated IP addresses (e.g., the 'www.example.com' and 'example.com' domains are both hostnames, whereas the 'com' domain is not).

DNS from Dummies by Javi & Leo

12

The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD). The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address. A DNS query may be either a non-recursive query or a recursive query: * A non-recursive query is one in which the DNS server provides a record for a domain for which it is authoritative itself, or it provides a partial result without querying other servers. * A recursive query is one for which the DNS server will fully answer the query (or give an error) by querying other name servers as needed. DNS servers are not required to support recursive queries. A top-level domain or domain name (TLD) is the highest level of domain names in the root zone of the Domain Name System of the Internet. For all domains in lower levels, it is the last part of the domain name, that is, the label that follows the last dot of a fully qualified domain name. For example, in the domain name www.example.com, the top-level domain is com, or COM, as domain names are not case-sensitive. Management of most top-level domains is delegated to responsible organizations by the Internet Corporation for Assigned Names and Numbers (ICANN), which operates the Internet Assigned Numbers Authority (IANA) and is in charge of maintaining the DNS root zone. Originally, the top-level domain space was organized into three main groups, Countries, Categories, and Multiorganizations. An additional temporary group consisted only of the initial DNS domain, arpa, intended for transitional purposes toward the stabilization of the domain name system. Countries are designated in the domain name system by their English two-letter ISO country code. This group of domains is therefore commonly known as country-code top-level domains (ccTLD). The Categories group has become known as the generic top-level domains. Initially this group consisted of GOV, EDU, COM, MIL, ORG, and NET. In the growth of the Internet, it became desirable to create additional generic top-level domains. Some of the initial domains' purposes were also generalized, modified, or assigned for maintanance to special organizations affiliated with the intended purpose. As a result, IANA today distinguishes the following groups of top-level domains: * country-code top-level domains (ccTLD): Two letter domains established for countries or territories. With some historical exceptions, the code for any territory is the same as its twoletter ISO 3166 code. * generic top-level domains (gTLD): Top-level domains with three or more characters o unsponsored top-level domains: domains that operate directly under policies established by ICANN processes for the global Internet community. o sponsored top-level domains (sTLD): These domains are proposed and sponsored by private agencies or organizations that establish and enforce rules restricting the eligibility to use the TLD. Use is based on community theme concepts. o infrastructure top-level domain: This group consists of one domain, the Address and Routing Parameter Area (ARPA). It is managed by IANA on behalf of the Internet Engineering Task Force for various purposes specified in Request for Comments.

DNS from Dummies by Javi & Leo

13

In addition, a group of internationalized domain name (IDN) top-level domains has been installed under test for testing purposes. The authoritative list of currently existing TLDs in the root zone is published at the IANA website at http://www.iana.org/domains/root/db/ In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is part of a larger domain. The Domain Name System (DNS) has a tree structure or hierarchy, with each node on the tree being a domain name. A subdomain is a domain that is part of a larger domain, the only domain that isn't also a subdomain is the root domain. For example, "mail.example.com" and "calendar.example.com" are subdomains of the "example.com" domain, which in turn is a subdomain of the "com" top-level domain (TLD). A "subdomain" expresses relative dependence, not absolute dependence: for example, wikipedia.org comprises a subdomain of the org domain, and en.wikipedia.org comprises a subdomain of the domain wikipedia.org. In theory, this subdivision can go down to 127 levels deep, and each DNS label can contain up to 63 characters, as long as the whole domain name does not exceed a total length of 255 characters. But in practice some domain registries have shorter limits than that. Subdomains are commonly used by organizations that wish to assign a unique name to a particular department, function, or service related to the organization. For example, a university might assign "cs" to the computer science department, such that a number of hosts could be used inside that subdomain, such as mail.cs.example.edu or www.cs.example.edu. A subdomain is sometimes termed a vanity domain, can be a subdomain of an ISP's own domain aliased to an individual user account or expresses the individuality of the person on whose behalf it is registered. Depending on application, a record inside a domain, or subdomain might refer to a hostname, or a service provided by a number of machines in a cluster. Some websites use different subdomains to point to different server clusters. For example, www.example.com points to Server Cluster 1 or Data centre 1, and www2.example.com points to Server Cluster 2 or Data centre 2, etc.

1.2.6 - Hierarchical structure & recursive resolution: how to reach the right IP?

The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use of recursive service using bits in the query headers. Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can communicate only with a single name server. These simple resolvers (called "stub resolvers") rely on a recursive name server to perform the work of finding information for them. A domain name may have several name components (e.g., ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, full host names will frequently consist of just three segments: ahost.inadomain.example, and most often www.inadomain.example. For querying purposes, software interprets the name segment by

DNS from Dummies by Javi & Leo

14

segment, from right to left. At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult. A DNS recursor consults three nameservers to resolve the address www.wikipedia.org. As originally envisaged, the process was as simple as: 1. the local system is pre-configured with the known addresses of the root servers in a file of root hints, which need to be updated periodically by the local administrator from a reliable source to be kept up to date with the changes which occur over time. 2. query one of the root servers to find the server authoritative for the next level down (so in the case of our simple hostname, a root server would be asked for the address of a server with detailed knowledge of the example top level domain). 3. querying this second server for the address of a DNS server with detailed knowledge of the second-level domain (inadomain.example in our example). 4. repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought. The diagram illustrates this process for the real host www.wikipedia.org. The mechanism in this simple form has a difficulty: it places a huge operating burden on the root servers, with every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system, such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is used to overcome this problem, and, in fact, root nameservers deal with very little of the total traffic.

Name servers in delegations appear listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record. For example, assume that the sub-domain en.wikipedia.org contains further sub-domains (such as something.en.wikipedia.org) and that the authoritative name server for these lives at ns1.something.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will thus first have to resolve ns1.something.en.wikipedia.org. Since ns1 is also under the something.en.wikipedia.org subdomain, resolving ns1.something.en.wikipedia.org requires resolving something.en.wikipedia.org which is exactly the circular dependency mentioned above. The dependency is broken by the glue record in the nameserver of en.wikipedia.org that provides the IP address of ns1.something.en.wikipedia.org directly to the requestor, enabling it to bootstrap the process by figuring out where ns1.something.en.wikipedia.org is located.

DNS from Dummies by Javi & Leo

15

1.2.7 - Authoritative servers, zone transfers

In computing, a name server (also spelled nameserver) consists of a program or computer server that implements a name-service protocol. It maps a human-recognizable identifier to a system-internal, often numeric, identification or addressing component. For example, on the Internet, a special case of name servers, so called Domain Name System (DNS) servers, are used to translate a hostname or a domain name (for example, 'en.wikipedia.org') to its corresponding binary identifier (the IP address 145.97.39.155), or vice versa. The Internet maintains two principal namespaces, the domain name hierarchy and the Internet Protocol (IP) address system. The Domain Name System maintains the domain namespace and provides translation services between these two namespaces. Internet name servers implement the Domain Name System. A DNS name server is a server that stores the DNS records, such as address (A) records, name server (NS) records, and mail exchanger (MX) records for a domain name (see also List of DNS record types) and responds with answers to queries against its database. The top hierarchy of the Internet Domain Name System is served by the root name servers maintained by delegation by the Internet Corporation for Assigned Names and Numbers (ICANN). An authoritative name server is a name server that gives original, first-hand, definitive answers (authoritative answers) to DNS queries and not just cached answers that were obtained from another name server. Therefore it only returns answers to queries about domain names that are installed in its configuration system. An authoritative name server can either be a master server or a slave server. A master server is a server that stores the original (master) copies of all zone records. A slave server uses an automatic updating mechanism of the DNS protocol in communication with its master to maintain an identical copy of the master records. Every domain name must be assigned a set of authoritative name servers that are installed in NS records in the parent domain. When domain names are registered with a domain name registrar their installation at the domain registry of a top level domain requires the assignment of a primary name server and at least one secondary name server. The requirement of multiple name servers aims to make

DNS from Dummies by Javi & Leo

16

the domain still functional even if one name server becomes inaccessible or inoperable. The designation of a primary name server is solely determined by the priority given to the domain name registrar. For this purpose generally only the fully qualified domain name of the name server is required, unless the servers are contained in the registered domain, in which case the corresponding IP address is needed as well. Primary name servers are often master name servers, while secondary name server may be implemented as slave servers. An authoritative server indicates its status of supplying definitive answers, deemed authoritative, by setting a software flag (a protocol structure bit), called the Authoritative Answer (AA) bit in its responses. This flag is usually reproduced prominently in the output of DNS administration query tools (such as dig) to indicate that the responding name server is an authority for the domain name in question. In principle, authoritative name servers are sufficient for the operation of the Internet. However, with only authoritative name servers operating, every DNS query must start with recursive queries at the root zone of the Domain Name System and each user system must implement resolver software capable of recursive operation. To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in the configuration (time-to-live) of the domain name record in question. Typically, such caching DNS servers, also called DNS caches, also implement the recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers of the queried domain. With this function implemented in the name server, user applications gain efficiency in design and operation. The combination of DNS caching and recursive functions in a name server is not mandatory, the functions can be implemented independently in servers for special purposes. Internet service providers typically provide recursive and caching name servers for their customers. In addition, many home networking routers implement DNS caches and recursors to improve efficiency in the local network.

1.2.8 - Registrar vs. maintainer: who do what?

1.2.9 - How to read and interpreter fields in a query

[PENDING]

DNS from Dummies by Javi & Leo

17

2. SERVER SIDE SOFTWARE

2.1 - Bind & Microsoft DNS Server

BIND, for Berkeley Internet Name Domain, is the most commonly used Domain Name System (DNS) server on the Internet. On Unix-like systems it is the de facto standard. BIND was originally created by four graduate students at the Computer Systems Research Group at the University of California, Berkeley, and was first released with 4.3BSD. Paul Vixie started maintaining it in 1988 while working for DEC. Today, BIND is maintained by the Internet Systems Consortium. A new version of BIND (BIND 9) was written from scratch in part to address the architectural difficulties with auditing the earlier BIND code bases, and also to support DNSSEC (DNS Security Extensions). Other important features of BIND 9 include: TSIG, DNS notify, nsupdate, IPv6, rndc flush (remote name daemon control), views, multiprocessor support, and an improved portability architecture. rndc uses a shared secret to provide encryption for local and remote terminals during each session. Earlier versions of BIND offered no mechanism to store and retrieve zone data in anything other than flat text files. Since BIND 9.4 DLZ has been available as a compile time option allowing for zone storage in a variety of database formats including LDAP, Berkeley DB, PostgreSQL, MySQL, and ODBC. Like Sendmail, WU-FTPD and other systems dating back to the earlier days of the Internet (when security was not such an issue as it has since become) BIND 4 and BIND 8 have had a large number of serious security vulnerabilities over the years and as such their use is now strongly discouraged. While BIND 9 was a complete rewrite, it has still experienced numerous vulnerabilities. The configuration files are not checked automatically for errors at runtime, but a configuration syntax verification tool is included in the distribution. Microsoft DNS is the name given to the implementation of domain name system services provided in Microsoft Windows operating systems. The Domain Name System support in Microsoft Windows NT, and thus its derivatives Windows 2000, Windows XP, and Windows Server 2003, comprises two clients and a server. Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS lookups. Some machines have a Dynamic DNS client, to perform Dynamic DNS Update transactions, registering the machines' names and IP addresses. Some machines run a DNS server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to service DNS update requests from DNS update clients. The server software is only supplied with the server versions of Windows. Applications perform DNS lookups with the aid of a DLL. They call library functions in the DLL, which in turn handle all communications with DNS servers (over UDP or TCP) and return the final results of the lookup back to the applications. Microsoft's DNS client also has optional support for local caching, in the form of a DNS Client service (also known as DNSCACHE). Before they attempt to directly communicate with DNS servers, the library routines first attempt to make a local IPC connection to the DNS Client service on the machine. If there is one, and if such a connection can be made, they hand the

DNS from Dummies by Javi & Leo

18

actual work of dealing with the lookup over to the DNS Client service. The DNS Client service itself communicates with DNS servers, and caches the results that it receives. Microsoft's DNS client is capable of talking to multiple DNS servers. The exact algorithm varies according to the version, and service pack level, of the operating system; but in general all communication is with a preferred DNS server until it fails to answer, whereupon communication switches to one of several alternative DNS servers. There are several minor differences in system behavior depending on whether the DNS Client service is started: * Parsing of the "hosts" file: The lookup functions read only the hosts file if they cannot offload their task onto the DNS Client service and have to fall back to communicating with DNS servers themselves. In turn, the DNS Client service reads the "hosts" file once, at startup, and only re-reads it if it notices that the last modification timestamp of the file has changed since it last read it. Thus: o With the DNS Client service running: The "hosts" file is read and parsed only a few times, once at service startup, and thereafter whenever the DNS Client service notices that it has been modified. o Without the DNS Client service running: The "hosts" file is read and parsed repeatedly, by each individual application program as it makes a DNS lookup. * The effect of multiple answers in the "hosts" file: The DNS Client service does not use the "hosts" file directly when performing lookups. Instead, it (initially) populates its cache from it, and then performs lookups using the data in its cache. When the lookup functions fall back to doing the work themselves, however, they scan the "hosts" file directly and sequentially, stopping when the first answer is found. Thus: o With the DNS Client service running: If the "hosts" file contains multiple lines denoting multiple answers for a given lookup, all of the answers in the cache will be returned. o Without the DNS Client service running: If the "hosts" file contains multiple lines denoting multiple answers for a given lookup, only the first answer found will be returned. * Fallback from preferred to alternative DNS servers: The fallback from the preferred DNS server to the alternative DNS servers is done by whatever entity, the DNS Client service or the library functions themselves, is actually performing the communication with them. Thus: o With the DNS Client service running: Fallback to the alternative DNS servers happens globally. If the preferred DNS server fails to answer, all subsequent communication is with the alternative DNS servers. o Without the DNS Client service running: Any fallback to the alternative DNS servers happen locally, within each individual process that is making DNS queries. Different processes may be in different states, some talking to the preferred DNS server and some talking to alternative DNS servers. Linux distributions and various versions of Unix have a generalized name resolver layer. The resolver can be controlled to use a hosts file or Network Information Service (NIS), by configuring the Name Service Switch. Whilst DNS lookups read DNS data, DNS updates write them. Both workstations and servers running Windows attempt to send Dynamic DNS update requests to DNS servers. Workstations running Windows attempt to register their names and their IP addresses with DNS servers, so that other machines may locate them by name. This is done not by the DNS Client service, but by the DHCP Client service. It is thus necessary to run the DHCP Client service, even if DHCP isn't being used to configure the machine, in order to dynamically register a machine's name and address for DNS lookup. The DHCP Client service registers name and address data whenever they are changed (either manually by an administrator or automatically by the granting or revocation of a DHCP lease).

DNS from Dummies by Javi & Leo

19

Servers running Microsoft Windows also attempt to register other information, in addition to their names and IP addresses, such as the locations of the LDAP and Kerberos services that they provide. Microsoft Windows server operating systems can run the DNS Server service. This is a monolithic DNS server that provides many types of DNS service, including caching, Dynamic DNS update, zone transfer, and DNS notification. DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when it is updated. Microsoft's "DNS Server" service was first introduced in Windows NT 3.51 as an add-on with Microsoft's collection of BackOffice services (at the time was marked to be used for testing proposes only). Its code is a fork of ISC's BIND, version 4.3, and remains largely compatible with it including the format of all master files. As of 2004, it was the fourth most popular DNS server (counting BIND version 9 separately from versions 8 and 4) for the publication of DNS data. Like various other DNS servers, Microsoft's DNS server supports different database back ends. Microsoft's DNS server supports two such back ends. DNS data can be stored either in master files (also known as zone files) or in the Active Directory database itself. In the latter case, since Active Directory (rather than the DNS server) handles the actual replication of the database across multiple machines, the database can be modified on any server ("multiplemaster replication"), and the addition or removal of a zone will be immediately propagated to all other DNS servers within the appropriate Active Directory "replication scope". (Contrast this with BIND, where when such changes are made, the list of zones, in the /etc/named.conf file, has to be explicitly updated on each individual server.) Microsoft's DNS server can be administered using either a graphical user interface, the "DNS Management Console", or a command line interface, the dnscmd utility. Prior to Windows Server 2003 and Microsoft Windows 2000 Service Pack 3, the most common problem encountered with Microsoft's DNS server was cache pollution. Although Microsoft's DNS Server had a mechanism for properly dealing with cache pollution, the mechanism was turned off by default. A long-known issue are the incompatibilities with BIND configuration files: in particular, the lack of support for DNS wildcards. This can be partially attributed to the fact that Microsoft's DNS server is based on BIND 4.3, before BIND added the support for DNS wildcards. Loose Wildcarding can be enabled as described here. To create a wildcard character record, the Dnscmd command-line tool can be used. Also the support of IPv6 is implemented using a different technique from that of BIND 9, further driving even more incompatibles between the two products. In 2004, a common problem involved the feature of the Windows Server 2003 version of Microsoft's DNS server to use EDNS0, which a large number of firewalls could not cope with.

DNS from Dummies by Javi & Leo

20

2.2 - Zone Files; record, entries, fields – TTL

A zone file is a text file that describes a portion of the domain name system (DNS) called a DNS zone. A zone contains information that defines mappings between domain names and IP addresses and other resources, organized in form of resource records (RR). The format a zone file is defined in RFC 1035 section 5 and RFC 1034 section 3.6.1. This format was originally used by the Berkeley Internet Name Domain (BIND) software package, but has been widely adopted by other DNS server software. Each line typically defines a single resource record. A line begins with a domain name, but if left blank, defaults to the previously defined domain name. Following the domain name is the TTL, the class (which is almost always "IN" for "internet" and rarely included), the type of resource record (A, MX, SOA, etc.), followed by type-specific data such as the IPv4 address for A records. Comments can be included by using a semi-colon and lines can be continued by using parenthesis. There are also file directives that are marked with a keyword starting with a dollar-sign. A simple example of a zone file: $ORIGIN example.com.     ; designates the start of this zone file in the name space $TTL 1h   ; The default expiration time of a resource record without its own TTL value example.com.  IN  SOA  ns.example.com. username.example.com. (                2007120710 ; serial number of this zone file               1d         ; slave refresh (1 day)               1d         ; slave retry time in case of a problem (1 day)               4w         ; slave expiration time (4 weeks)               1h         ; minimum caching time in case of failed lookups (1 hour)               ) example.com. NS  ns             ; ns.example.com is the nameserver for example.com example.com. NS   ns.somewhere.com.       ; ns.somewhere.com is a backup nameserver for example.com example.com.   MX   10   mail.example.com.;   mail.example.com   is   the   mailserver   for example.com @ MX 20 mail2.example.com. ; Similar to above line, but using "@" to say "use $ORIGIN" @ MX 50 mail3     ; Similar to above line, but using a host within this domain example.com. A     10.0.0.1              ; ip address for "example.com" ns           A     10.0.0.2              ; ip address for "ns.example.com" www          CNAME ns            ; "www.example.com" is an alias for "ns.example.com" wwwtest      CNAME www ; "wwwtest.example.com" is another alias for "www.example.com" mail         A 10.0.0.3; ip address for "mail.example.com", any MX record host must be                              ; an A or AAAA record, it should never be a CNAME record                                       ; as explained in RFC 2181 (section 10.3)

As a minimum, the zone file should specify the default "time to live" (TTL) for a record in a client's cache after which it should repeat the lookup, and the 'Start of Authority' (SOA) record with the name of the primary authoritative nameserver for the zone, the email address of someone responsible for management of the nameserver and the zone, and some information for backup nameservers, that is, other servers that keep a backup copy of the zone information in case the main nameserver is not reachable. The email address has the @ symbol replaced by a period (.). In the zone file, host names that do not end in a period are assumed to be relative to the zone origin. For example, in the example above, "www" refers to "www.example.com", but "example.com." does not refer to "example.com.example.com", but rather to "example.com". Names ending with a period are said to be 'fully qualified' domain names. A zone file is referenced by the configuration file of the nameserver software such as bind, typically by a statement such as: zone "example.com" { type master; file "/var/named/db.example.com";  };

DNS from Dummies by Javi & Leo

21

TTL Time to live (sometimes abbreviated TTL) is a limit on the period of time or number of iterations or transmissions in computer and computer network technology that a unit of data (e.g. a packet) can experience before it should be discarded. In IPv4, time to live (TTL) is an 8-bit field in the Internet Protocol (IP) header. It is the 9th octet of 20. The time to live value can be thought of as an upper bound on the time that an IP datagram can exist in an internet system. The TTL field is set by the sender of the datagram, and reduced by every host on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender. The purpose of the TTL field is to avoid a situation in which an undeliverable datagram keeps circulating on an internet system, and such a system eventually becoming swamped by such immortal datagrams. In theory, time to live is measured in seconds, although every host that passes the datagram must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every hop. To reflect this practice, the field is named hop limit in IPv6. TTLs also occur in the Domain Name System (DNS), where they are set by an authoritative nameserver for a particular resource record. When a caching (recursive) nameserver queries the authoritative nameserver for a resource record, it will cache that record for the time (in seconds) specified by the TTL. If a stub resolver queries the caching nameserver for the same record before the TTL has expired, the caching server will simply reply with the already cached resource record rather than retrieve it from the authoritative nameserver again. Nameservers may also have a TTL set for NXDOMAIN (acknowledgment that a domain does not exist); but they are generally short in duration (3 hours at most). Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions. The units used are seconds. A common TTL value for DNS is 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that if a DNS record was changed, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

DNS from Dummies by Javi & Leo

22

2.3 - RR types: SOA,A,MX,PTR,CNAME,TXT, SPF, NS & others

SOA, start of authority record. Specifies authoritative information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone. A, address record. Returns a 32-bit IPv4 address, most commonly used to map hostnames to an IP address of the host, but also used for DNSBLs, storing subnet masks in RFC 1101, etc. MX, mail exchange record. Maps a domain name to a list of mail exchange servers for that domain. PTR, pointer record. Pointer to a canonical name. Unlike a CNAME, DNS processing does NOT proceed, just the name is returned. The most common use is for implementing reverse DNS lookups, but other uses include such things as DNS-SD. CNAME, canonical name record. Alias of one name to another: the DNS lookup will continue by retrying the lookup with the new name. TXT, text record. Originally for arbitrary human-readable text in a DNS record. Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework (deprecated), DomainKeys, DNS-SD, etc. NS, name server record. Delegates a DNS zone to use the given authoritative name servers. SPF, spf record. Specified as part of the SPF protocol, as an alternative to storing SPF data in TXT records. Uses the same format as the TXT record. Other records are AAAA, AFSDB, CERT, DHCID, DLV, DNAME, DNSKEY, DS, HIP, IPSECKEY, KEY, LOC, NAPTR, NSEC, NSEC3, NSEC3PARAM, RRSIG, SIG, SRV, SSHFP and TA.

DNS from Dummies by Javi & Leo

23

2.4 - Examples - use of A - use of PTR - MX record - use of CNAME - use of TXT and SPF - Domain zone for MBE Colt

DNS from Dummies by Javi & Leo

24

3. CLIENT SIDE SW

3.1 - nslookup

A simple command line tool that we can use to check DNS fields and internet resources is nslookup, normally provided with both Windows and Unix OS. Nslookup can be a useful tool for a first step troubleshooting, but we will see in the other sections some more sophisticated tools to make more accurate queries to name servers. Please finally notice that we will see the Windows version but the flags and examples are also valid in a Unix environment, and normally integrated into the TCP/IP stack of all the modern OS. We will also see in the appropriate section, that the same tool is provided by a lot of website, but for most of them user can’t set all parameters that will be available using the command line tool. We can start an interactive nslookup session by typing ‘nslookup’ at the command line prompt:

As we can see above, we obtain as answer, the default server that will try to resolve our query (normally the primary DNS server set in our network connections). We can obviously change this default server, so we can try resolve our query using, for instance, a particular name server we wants to check (for example the DNS server used by a particular customer, to see if he could correctly resolve a domain name) Will be also provided to the user an interactive prompt where he can set some details for the query parameter and other useful things, that we now will see.

DNS from Dummies by Javi & Leo

25

3.1.1 - Flags and their use

Typing ‘?’ or ‘help’ at the nslookup internal shell we can obtain the list of all parameters that we can use to retrieve some canonical name information we need.

Here some basic notes on the options, leaving an exhaustive explanation in the examples of the next paragraph. As a basic task we can simply insert the name of the resource we need to resolve, introducing a ‘NAME’ at the nslookup prompt. When we use the notation > NAME1 NAME2 we ask to the program to check the canonical name ‘NAME1’ using the ‘NAME2’ DNS server instead of the default server indicated at the beginning of the nslookup session. Using the keyword ‘set’ we can set some details to resolve our canonical name, adding some optional keywords. For example typing > set all > set type=MX

we can see all the parameters set for our session all the next queries will be on MX record

You can also find an exhaustive explanation man page of nslookup at: http://www.kloth.net/services/nslookup-man.php

DNS from Dummies by Javi & Leo

26

3.1.2 - Examples

Typing the comman ‘set all’, we can see here the default settings of nslookup. In this example we can see among the other information that: -

the answering server will not be provide us debug informations (nodebug,nod2); we will ask for a recursive resolution; to use canonical 53 server’s port; the default request will be an ‘A’ field; the default root server;

If we now type the domain microsoft.com we obtain the answer:

that reports for this domain the two ‘A’ field, which is the default type query as we have seen in the previous picture. If we want to know the mail servers for the domain microsoft.com, we have to first change the type of query, and after ask again for the microsoft domain:

Note that after have setting the type of record we obtain again the prompt of the interactive nslookup session. To end the entire session you must type ‘x’ or ‘exit’ or ‘control-C’.

DNS from Dummies by Javi & Leo

27

As final thing we can see the answer, changing the type of record and setting it to ‘ANY’:

For space problem we avoid to provide the output of debug information. You can try yourself to see what is the nslookup output, setting the two debugs options: > set debug > microsoft.com or > set d2 (more exhaustive) > microsoft.com

3.2 - Dig

Dig it’s a very powerful program for check and troubleshoot DNS issues. Like NSLookup has a lot of features, but permit a more accuracy in your searches. You can find it in a lot of websites. For example you can download it from: http://members.shaw.ca/nicholas.fong/dig/ or on more other web pages, as the window porting doesn’t have a dedicated website. There isn’t need to install it. You have only to unzip it in a folder and run it via CLI. For a better work environment you have only to edit your system PATH variable and to edit and put into %systemroot%\system32\drivers\etc\ the resolv.conf file. Normally you’ll find detailed instruction on how to setup dig on the same page where you have downloaded the dig zip file.

DNS from Dummies by Javi & Leo

28

3.2.1 - Flags and use

3.2.2 – Examples

3.3 - Online tools - Ping, lookup, trace, whois, dns records, dig, MX Lookup, SPF check

4. DOCUMENTATION - useful books - online & free documentation - link to official RFC's

DNS from Dummies by Javi & Leo

29

DNS from Dummies by Javi & Leo

30