TCP/IP Notes

Intro / Network Addressing / Network Addressing IPv6 / Packet Headers / Networking and Data Link Layers / Transport Layer Protocols / Application Layer Protocols / IP Routing / ICMP / DHCP / Name Resolution and DNS / Security

NAME RESOLUTION AND DNS

The goal of Domain Name System (DNS) is to convert symbolic domain names ("google.com") to numeric IP addresses which represent the networking and host address of the actual server/"area" where the website is hosted. DNS also supports email addresses. Without DNS people using the internet would have to essentially remember all of the numeric IP addresses.

The entire mapping of the web relies on DNS, which operates as distributed and decentralized servers spread across the globe.

Before a IP packet is sent from source to destination, the name-to-address resolution process occurs, so that the source can determine the actual address of the destination to know exactly where to direct packets. Three methods for doing this include:

1) Source computer consults internal name-to-address file/table (ideally must be dynamically updated).

2) Source computer sends network broadcast requesting IP address of the intended destination.

3) Source computer contacts a server which maintains a large dynamically updated database containing name-to-address entries and lookup capability.

In the early days of name resolution, the process was a lot less complex since entries were often edited manually in the UNIX /etc/hosts file. In the 1970s, ARPANET was small enough such that name resolution could be handled using a single text file. As the network grew, manually editing each node created the need for an automated process, which led to standard name resolution protocols.

NetBIOS/NBT
-----------------

In Windows, NetBIOS over TCP/IP was used to allow the Windows operating systems to share files between versions. In Windows 7 the default is to use NetBIOS settings provided by DHCP (automatically for static IPv4 addresses).

NetBIOS works by maintaining a list of unique names assigned to network resources (files, services/processes, users, computers, Windows workgroups and domains). Applications use an API to communicate a desire to discover/access named resources, which then prompts NetBIOS to resolve the address name. NetBIOS has two serious drawbacks: first, NetBIOS only determines host names ("flat namespace" versus hierarchical IP namespace), and second, NetBIOS is excessively "chatty," which can be troublesome for larger networks.

RFC 1001 (https://tools.ietf.org/html/rfc1001) describes "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport." This is intended to correct NetBIOS shortcomings, and is typically found on networks which do not have access to a DNS server (not operating in a domain and using older versions of Windows and Microsoft services and applications).

NBT can be manually enabled in Windows via the TCP/IPv4 Properties box --> General tab --> Advanced --> WINS.

As of Windows 7, NBT is becoming nearly obsolete, especially for smaller/home office networking environments. It is not supported in IPv6.

WINS
-------

Windows Internet Name Service (WINS) resolves NetBIOS names to IP addresses in routed networks, which requires the use of a WINS server located within a network (e.g., Windows Server 2003). Ideally this is used in networks which require NBT for name resolution. WINS is able to automate dynamic name resolution due to DHCP server changes such as a changed IP address of a network node. A WINS server has its own database which reduces the need for IPv4 requests for name resolution. If a Windows computer workstation requires NetBIOS, it first checks its local NetBIOS name and name cache for remote names. If not found, the computer sends a NetBIOS query to the primary WINS server, then secondary and finally it's own HOST files. WINS servers use unicast, and WINS clients pre-2000 and XP can use only one primary and one secondary WINS server but versions after 2000/XP can use 11 secondary servers.

The process of how a client ---> server communicates is as follows:

1) NetBIOS client sends Name Registration Request packet to WINS server.
2) The WINS server sends back a positive Name Registration Reply packet and enters the name into its database.
3) The response includes a TTL (six days by default) for the client name, and attempts to renew at half the TTL value.

If the name of a NetBIOS client is already in the WINS server database, the server sends back a Wait Acknowledgement (WACK) message and attempts to contact the registered owner to see if the name is still in use. If the owner responds the WINS server sends a negative Name Registration Reply packet and attempts to register the name. If the registered owner doesn't respond the WINS server grants the client name by sending a positive Name Registration Reply packet.

To deal with multiple concurrent Name Registration Requests, WINS servers use 'burst mode,' in which the server responds to each Name Registration Request with a positive Name Registration Reply but does not attempt to resolve any conflicts, assigning each node a different TTL value to defer conflict resolution until after a spike in network usage has occurred. Using the WINS server console the queue size triggering burst mode can be modified. When name conflicts happen, a Name Conflict Demand or Name Release Demand packet is sent instructing the receiving node to alert the user and to remove the name from its name table and to release the current user.

Unix and Unix-like operating systems can access NetBIOS via Samba (https://www.samba.org/), which uses SMB and NetBT for sharing resources on IP networks.

Similar to NBT, WINS has become unnecessary in modern networking environments due to the widespread use of DNS servers for name resolution. Microsoft has officially stopped supporting the versions of Windows which use NBT and WINS, meaning this form of name resolution may eventually become obsolete, especially in terms of IPv6 which WINS does not support.

DNS
------

The Domain Name System (DNS) is described in RFC 1034 & 1035 (https://tools.ietf.org/html/rfc1034 & https://tools.ietf.org/html/rfc1035). DNS is used for naming computers and network services using a hierarchal structure for organizing these computers and networks into "domains" using human-readable names. DNS servers contain databases which allow a name resolution query to retrieve the IP address for the requesting host.

In IPv6, there are some new extensions for DNS (https://tools.ietf.org/html/rfc3596), which are required to deal with the 32 vs 128 bit address space. To support DNS in IPv6, there needs to be name-mapping, address lookup, and a transition query system. These extensions are not intended to create a new DNS version but rather are designed to be compatible with existing applications and backwards-compatible with IPv4.

LLMNR
---------

Link-Local Multicast Name Resolution (LLMNR), defined in RFC 4795 (https://tools.ietf.org/html/rfc4795) is a protocol based on DNS allowing IPv4 and IPv6 network hosts to do name resolution for devices connected to the same local link (protocol is not designed to cross router boundaries), and is supported in Windows Server 2008, Vista, and 7. The protocol uses a request/reply exchange for resolving addresses:

1) LLMNR node sends query to link-scope multicast address.
2) The responding node answers the query and responds with a unicast UDP packet to the sending node.
3) Sending node processes the response and completes name resolution.

For IPv4 hosts, the link-scope multicast address is 224.0.0.252. In IPv6, the address is FF02::1:3. Unlike DNS servers, LLMNR hosts are only authoritative for specifically assigned names.

The LLMNR packet format is based upon the DNS packet format, and the header is similar in structure.

Name Resolution in IPv4 Networks
---------------------------------------------

In the early days of the Internet, resolving symbolic names to numberic IP addresses relied on static HOSTS text files, which contained a list of known hostnames and related IP addresses. In the mid 1980s, it became difficult to manage the growing number of internet connected hosts. In response, Paul Mockapetris created the original RFCs for DNS (882 & 883) and the first implementation called JEEVES. Another version written by Kevin Dunlap called BIND (Berkeley Internet Name Domain) for BSD UNIX 4.3 soon followed and became the most popular DNS implementation, used today in UNIX and Windows Server 2003 & 2008.

DNS was designed to be a distributed database, with individual parts known as 'database segments' and containing only a portion of the namespace for a particular DNS server and its clients. This decentralized approach allows servers to maintain their own domain names and part of the Internet as a whole simultaneously (makes it possible to find domain names and addresses anywhere on the Internet).

Two main design features are resiliency and robustness. It does this through:

- Allowing multiple copies of the same data to be maintained on separate servers.
- Caching DNS data from one or more database segments on one or more DNS servers.
- Providing a mechanism for responding to name resolution requests locally before attempting remotely.

DNS Database Structure
--------------------------------

The structure of the DNS database mirrors the structure of the domain namespace (tree structure with root at the top). TLD or primary domains follow the 3 letter code:

.com, .edu, .gov, .mil, .net, .org

There are also two or three letter country codes, specified in ISO Standard 3166, such as .us (United States), .ca (Canada), .fr (France), etc. A complete list of these codes can be found at: https://iana.org/cctld/cctld-whois.htm.

Recently, the TLD has been expanded to include new codes (.biz, .info, .name, etc.).

Underneath root (symbolized by ".") resides the domain space for the Internet. At the top of the DNS hierarchy are 13 root name servers (A.ROOT-SERVERS.NET., B.ROOT-SERVERS.NET., etc.) which provide the ultimate source of name lookups if they can't be resolved further down the tree. Domain name start at the bottom of the tree and work up, each domain name or subdomain specified by a dot. Fully Qualified Domain Names (FQDN) as found in records in DNS databases include the period at the end to designate "root."

DNS Namespace
----------------------

Each part of a DNS namespace corresponds to a point in the tree structure (as well as roots of a new subtree, each subtree representing a database segment). The subdomain design is known as 'delegation of authority,' in that local administrators have local control over these database segments. This addresses the need to manage the Internet by breaking it down into smaller parts, each of which act as containers for DNS servers, addresses, users and hosts.

DNS Database Records
-------------------------------

DNS database records are referred to as resource records (RRs), which are divided into 4 classes, one of which representing the Internet. Within the Internet class, records are named based on type (RFC 1035: https://tools.ietf.org/html/rfc1035). The nine most commonly used are:

Address (A) - Stores domain name-to-IP address translation data.

Canonical name (CNAME) - Used to create aliases.

Host information (HINFO) - Stores descriptive information about a specific host.

Mail exchange (MX) - Used to route SMTP-based email, identifies IP address for a domain's master email server.

Name server (NS) - Identifies all DNS servers in a domain.

Pointer (PTR) - Stores IP address-to-domain name translation data, supports reverse DNS lookup.

Start of Authority (SOA) - Identifies authoritative name server for specific DNS database segment (master DNS server for specific domain or subdomain).

Service location (SRV) - Provides information about available services in Windows Active Directory to map services and servers together, used by Active Directory clients (RFC 2052: https://tools.ietf.org/html/rfc2052).

Text (TXT) - Adds arbitrary text information to a DNS database, usually for documentation.

Well-known services (WKS) - Lists IP-based services of an internet host (Telnet, FTP, HTTP, etc.).

Delegation of DNS Authority
-------------------------------------

Once authority for a domain is delegated, the database for the domain name server includes NS records pointing to name servers authoritative for specific subdomains.

Types of DNS Servers
-----------------------------

Primary DNS Server - Also called master server, stores primary DNS database files for domains or subdomains for which the server is authoritative. Files are sometimes called "zone files" and are always read from the disk of the server. Designating this server is important when configuring a DNS server of any kind. For any DNS zone (database segment), there can only be one master or primary DNS server.

In the Internet Protocol Properties in Windows the "primary first server" is not the same as the Primary DNS Server, but merely where the individual client first reads DNS data (recommended to be cached).

Secondary DNS Server - Receives zone data from Primary DNS Server, reads data from a local file but checks to see if this version is the same as the primary via SOA record data. When differences are encountered, the Secondary DNS server updates from the primary ("zone transfer"), which can be done incrementally. It is recommended for at least one Secondary DNS Server to be connected to a primary, as they provide backup copies of the data in case the primary is out of service. Secondary DNS servers can also distribute the load for DNS lookups.

Caching Servers - Store recently accessed DNS records to minimize the overhead of remote querying for a resource located outside of the local domain.

How Domain Name Servers Work
---------------------------------------------

Domain Name Resolution:

1) DNS servers retrieve name data from the domain namespace.

2) If the DNS server is authoritative, it provides data about the zones to which this extent covers.

3) When a DNS server is queried, it will search its cached domain name data and provide information based on authority.

4) If a local server does not have the information available in its database or name cache, it may go to a cache server or to other known name servers within its neighborhood (secondary or primary).

5) If these queries do not produce a result, the name server sends a request for name resolution to the root server, which forwards the query to the authoritative server for the specific zone via NS pointers.

Recursive Query
----------------------

From the client side, resolvers use what is called "recursive query," which means they contact the first DNS server for finding the address translation. If the first server contacted cannot resolve the domain name, it asks other name servers within the neighborhood. The first DNS server keeps asking until an answer or ultimately an error message is reached, following pointers to other name servers through higher levels within the domain name hierarchy or within different subtrees of the DNS name hierarchy.

When a server receives a recursive query, it issues iterative queries (nonrecursive). When a query arrives at a root server which cannot handle the request from its own cache, the server launches its own recursive query for domains within its purview.

DNS Caching
-----------------

The resolution process is sped up by 'nonauthoritative responses.' When an outside zone request is made to a DNS server, the server first checks its own cache, which can end the query. But, if the information is not found, iterative requests from the DNS server can contact other servers to see if they have the information along the name hierarchy. Conversely, an authoritative response indicates that root server requests always go to the name server authoritative for the domain which contains the name or address requested.

Overtime, the names and addresses in DNS caches can become old, and have expiration dates for when they are to be deleted. DNS servers can have procedures whereby clean up operations are performed (checking each record and deciding whether to keep). Through a process called 'negative caching,' DNS servers can also store names and addresses which have resulted in error messages, allowing these messages to be stored locally.

DNS Configuration Files and Resource Record Formats
------------------------------------------------------------------------

The files matching host names to addresses are usually named "local/sub domain name".dns, and reverse lookups are usually called "domain network number in reverse order".in-addr.arpa.dns.

For example, the website ipv6testlabs.com, whose IP address is 75.32.168.188, would have a reverse lookup address of 188.168.32.75.in-addr.arpa.dns.

Every DNS zone must contain SOA and NS records.

Start of Authority Record
---------------------------------

SOA records identify authoritative name servers for specific DNS database segments. They are also the first entries in DNS files. Both primary and secondary DNS servers can declare themselves authoritative via SOA records (which is what allows for load balancing). An example given for a SOA record is as follows:

tree.com. IN SOA orange.tree.com. nancy.orange.tree.com(
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day

* semicolons are inline comments

In this example, "tree.com" is the domain to which the zone applies. IN means the record belongs to the Internet class of record types. SOA indicates the type of record. orange.tree.com is the fully-qualified domain name, and nancy.orange.tree.com is a way of expressing the email address 'nancy@orange.tree.com'.

The attribute values (in parentheses) from top to bottom are:

Serial - 32 bit number used for comparing primary and secondary DNS servers. The number is incremented each time an update occurs.

Refresh - Number of seconds which can elapse until the zone database needs to be refreshed, syncs primary and secondary servers within a certain timeframe and specifies the interval at which the secondary server checks the primary.

Retry - Number of seconds allowable before a refresh is attempted again.

Expire - Number of seconds allowable before the zone database is no longer authoritative. Allows DNS server to calculate how long it has been since a last update.

Minimum TTL - Specifies how long a resource record should be allowed to persist in another nonauthoritative DNS server cache. Larger values mean the server handles fewer queries but users will have to wait longer for the information changes to take place. Shorter values make changes more immediate, but also increase traffic.

Address and Canonical Name Records
---------------------------------------------------

This example shows how A and CNAME records are used (typical in domain.dns files):

; Host addresses
localhost.tree.com. IN A 127.0.0.1
pear.tree.com. IN A 172.16.1.2
apple.tree.com. IN A 172.16.1.3
peach.tree.com. IN A 172.16.1.4
; Multihomed host
hedge.tree.com. IN A 172.16.1.1
hedge.tree.com. IN A 172.16.2.1
; Aliases
Pr tree.com IN CNAME lemon.tree.com
h.tree.com IN CNAME hedge.tree.com
a.tree.com IN CNAME apple.tree.com
h1.tree.com IN CNAME 172.16.1.1
h2.tree.com IN CNAME 172.16.2.1

The first line in this example uses the FQDN for localhost, which translates into localhost.tree.com (loopback).

The second line sets the FQDN pear.tree.com to the IP address 172.16.1.2.

h1.tree.com IN CNAME 172.16.1.1 & h2.tree.com IN CNAME 172.16.2.1 under Aliases define names for individual interfaces (attached to multiple subnetworks). By default, DNS accesses only the first IP address for a host when multiple entries for a single domain name are defined. This is a shorthand way of referencing the IP address via an alias which is easier to remember.

A technique called DNS Round Robin is a method for load balancing when a DNS server responds to requests for name-to-address resolution and one domain name corresponds to multiple IP addresses. In this method, the DNS server keeps track of all recent IP addresses for a specific resolution and rotates the addresses within the list of available addresses (allows no one server to become overloaded). This technique is commonly used in concert with other load-balancing methods, as it can have some drawbacks which would need to be covered.

Mapping Addresses to Names
----------------------------------------

db.addr files are used to support reverse DNS lookup (which explains why the order of octets in the address is also reversed). For security, reverse lookups are used to make sure domain names and IP addresses match (possible IP Spoofing if they do not). In Unix-like environments, this functionality is included in several applications such as rlogin.

Here is an example of a file named 16.172.in-addr.arpa.dns:

1.1.16.172.in-addr-arpa. IN PRT hedge.tree.com
2.1.16.172.in-addr-arpa. IN PRT pear.tree.com
3.1.16.172.in-addr-arpa. IN PRT apple.tree.com
4.1.16.172.in-addr-arpa. IN PRT peach.tree.com

The file structure in reverse DNS lookups is classful (must follow logical subdivisions of IP addresses into Classes A, B, & C, corresponding to a network organized in /8, /16, & /24 subnets). On classless networks (e.g., CIDR-based), the in-addr.arpa tree can be extended downward so that the first address forms the first component of the name for each sub zone (described in RFC 2317: https://tools.ietf.org/html/rfc2317).

Name Resolution in IPv6 Networks
---------------------------------------------

The basic functions inherent in DNS under IPv4 apply to IPv6, however name resolution is made more complex by the multiple addresses which IPv6 hosts and interfaces can own. This makes hierarchy more important for resolving IPv6 name lookups, which has led to the creation of a new reverse hierarchy tree named ip6.arpa to replace the old in-addr.arpa tree.

Currently there is no single RFC which completely describes DNS running on IPv6, but unofficially people may refer to "DNSv6." Currently, RFCs which address DNS and IPv6 include RFC 2874 (https://tools.ietf.org/html/rfc2874) "DNS Extensions to Support IPv6 Address Aggregation and Renumbering," RFC 3901 (https://tools.ietf.org/html/rfc3901) "DNS IPv6 Transport Operational Guidelines," and RFC 4339 (https://tools.ietf.org/html/rfc4339) "IPv6 Host Configuration of DNS Server Information Approaches."

DNS server implementations supporting IPv6 include Microsoft Server 2003 and 2008. IPv6 is also supported in Windows Vista, Windows 7, and Unix-like distributions via BIND.

DNS in IPv6
---------------

When IPv4 addresses began to run out and IPv6 was first specified by the IETF, DNS was extended to support the longer address space. The DNS A record will not support a 128-bit address, so RFC 1886 defined the DNS extension for accommodating the longer address but was obsoleted by RFC 3596 (https://tools.ietf.org/html/rfc3596), creating the 'AAAA record,' allowing each record to store a single IPv6 address:

ipv6-host IN AAAA 2001::2D57:C4F8:8808:80D7

An AAAA query for a particular domain name will return all related AAAA records but will not do any further processing.

In ipv6.arpa, each level of the subdomain represents 4 bits out of the 128-bit IPv6 address, with the least to most significant bits going from left to right. Addresses within the domain are represented by a sequence of hexidecimal nibbles separated by periods with ip6.arpa as the name suffix:

e.g., the IPv6 address of '2001:db8:4321:12:34:567:89ab:ef' is represented as 'f:e:0:0:b:a:9:8:7:6:5:0:4:3:0:0:2:1:0:0:1:2:3:4:8:b:d:0:1:0:0:2.ip6arpa'

Current hybrid challenges include redefined A record query types (NS, SRV and MX). In IPv6 source and destination address selection, there is a proposed standard specified by RFC 3484 (https://tools.ietf.org/html/rfc3484), intended to allow multiple unicast addresses to be assigned to a network interface, each with different reachability scopes (link-local and global). In this situation if a network is also to accommodate IPv4, it can have one or more tunnel interfaces with link-local and global address scopes defined, using algorithms for determining source and destination addresses.

Further Reading
---------------------

rlogin
https://www.freebsd.org/cgi/man.cgi?query=rlogin&sektion=1