Imprint | Privacy Policy

Naming and DNS

(Usage hints for this presentation)

Winter Term 2018/2019
Dr. Jens Lechtenbörger (License Information)

DBIS Group
Prof. Dr. Gottfried Vossen
Chair for Computer Science
Dept. of Information Systems
WWU Münster, Germany

1 Introduction

1.1 Today’s Core Questions

  • How are names typically managed in computer systems?
  • What is the DNS?
    • How to interpret names such as
    • How does it work?

1.2 Learning Objectives

  • Explain DNS as example for namespace management
    • Explain notions of name server, zone, resource record
    • Explain iterative DNS resolution
  • Discuss properties of Zooko’s triangle in relation to DNS
  • Perform DNS lookups for different resource types via nslookup
  • Position DNS names in the wider context of URIs

1.3 Recall: DNS in Internet Protocol Stack

1.4 Namespaces and Name Services

  • Name service = System managing namespace, in particular mapping names to values
    • E.g., DNS names and IP addresses, E-Mail addresses and public keys, file names and storage locations
    • Names may be flat or hierarchical, potentially infinitely many
    • Namespace often structured
      • Similar name parts without conflict
        • E.g., server named www in lots of organizations
      • Grouping of related names
        • E.g., all university computers with names ending in
      • Typically directed graphs
        • Leafs: Named entities
        • Inner nodes: Directories
      • Enable transparent restructuring

2 Domain Name System (DNS)

2.1 Basics

  • DNS specified in RFC 1034 and RFC 1035
  • DNS is a distributed name service
    • Collectively manages DNS names
      • Names mapped to resource records by name servers
        • Resource record: Next slide
    • Scalable (today’s Internet)
    • Fault tolerance via replication

2.1.1 Resource Records

  • Name servers manage resource records
      • E.g., (, 7200, IN, A,
      • NAME, VALUE: Mostly names and IP addresses
      • TTL: Time to live (caching period in seconds) of resource record
      • Sample TYPE values
        • A: DNS name NAME has IPv4 address VALUE (IPv6 is AAAA)
        • NS: VALUE is DNS name for authoritative name server of domain NAME
        • CNAME: VALUE is canonical name; used for aliasing
        • MX: VALUE is DNS name for mail server of domain NAME
        • SOA: Start of Authority, management and name server information
      • CLASS: Constantly IN in Internet
  • Live examples in-class

2.2 DNS Names

  • DNS defines namespace with absolute and relative names
    • Absolute: ending in dot (.)
      • . (Root)
    • Relative: not ending in dot
      •, www
      • de, org (Top Level Domains, TLDs)
      • Completed in local domain
        • E.g., www might mean,, or, while means
        • Final dot almost always omitted when typing names
    • Reserved names: RFC 2606, e.g.,

2.3 DNS Zones

  • DNS namespace partitioned into so-called zones
    • Zones reflect administrative structure of Internet
      • E.g., is a subzone of de., which in turn is a subzone of the root zone .
      • Various registries (e.g., DENIC for .de., university for
    • Zones managed by authoritative name servers
      • A form of decentralization
      • At least two replicated name servers per zone for fault tolerance

2.3.1 DNS Namespace

image/svg+xml Domain Name Space = resource recordsassociated with name see also: RFC 1034 4.2:How the database is divided into zones. = zone of authority,managed by a name server "delegated subzone" "zone delegation" NS RR ("resource record")names the nameserverauthoritative fordelegated subzone When a system administratorwants to let another administratormanage a part of a zone, the firstadministrator's nameserver delegatespart of the zone to anothernameserver.

Domain name space ” by LionKimbro under Public domain; from Wikimedia

2.3.2 DNS Root Zone and Servers

  • Root zone . managed by ICANN (Internet Corporation for Assigned Names and Numbers)
    • Names and addresses of root name servers
    • 13 root name server names as redundant entry points
      • Single letter names, …,
        • Those 13 names are implemented by hundreds of replicated servers
        • (Using a routing technique called anycast)
      • Root servers are responsible for TLD lookups

2.3.3 Resolution Challenge

  • No DNS server knows all names
  • E.g., university’s name server knows everything about names ending in, but nothing about names ending in
    • What to do if client in university asks for
    • Answer: Our name server asks somebody else
      • Our name server does not know a name server for
      • Every name server is preconfigured with names and addresses of root name servers …

2.4 Name Resolution

  • Obtaining information for a DNS name is called name resolution
  • Components responsible for resolution are called resolvers
    • Each with cache for recent results (up to TTL of resource record)

2.4.1 DNS Resolvers

image/svg+xml Web Browser Mail Client Your Computer Client Programs Operating System DNS Resolver localcache Your ISP DNS Resolver localcache minicache cache timeout:1-30 min recursiveDNSsearch

DNS in the real world ” by Lion Kimbro under Public domain; from Wikimedia

2.4.2 Local Resolver

  • Application calls OS, e.g., InetAddress.getByName(String) in Java
  • OS uses local configuration and network services
    • “hosts file”: /etc/hosts, %systemroot%\system32\drivers\etc\hosts
      • List of DNS names with IP addresses
    • Name services such as DNS, LDAP, NIS
      • OS configured with IP address(es) of DNS name server(s)
        • E.g.,, within university
        • Automatic configuration with DHCP
  • Beware of profiling
    • Your DNS server learns every hostname contacted by your computer

2.4.3 Iterative DNS Resolution


Example of an iterative DNS resolver ” by Lion Kimbro under Public domain; from Wikimedia

2.5 DNS as Network Application

  • DNS follows request/reply communication pattern
    • Queries and answers are network messages
      • “Small,” fit into single IP datagram
      • Delivery either via UDP or TCP
        • Typically, DNS uses UDP on well-known port 53
        • Best effort service model
        • Why is that good enough?
  • Originally, no security mechanisms
  • DNSSEC under deployment since 2010
    • Integrity protection with digital signatures

3 In-Class

3.1 Dynamic DNS (DynDNS)

  • Aim: Permanent DNS name for dynamic IP address
  • Idea
    • Special DNS servers allow updates in real-time
    • TTL of 60s
    • Special client software to notify DNS server of changed IP address
      • Sometimes integrated into DSL router/modem

3.2 DNS Query Tools

  • dig (next slide) or nslookup as command line tools
  • nslookup (monitor with Wireshark to see all details)
    • Query for IP address
    • Query for mail server
      • set type=MX
    • Query for name server, ask specific server
      • set type=NS
      • server
  • Further info on domain names: whois
    • whois

3.2.1 Example for dig

  • Why 13 name servers?
  • Answer: Compatibility issues
    • UDP replies restricted by DNS (RFC 1035) to 512 bytes
    • dig . soa
      • With 13 servers, response had 497 bytes; no space for 14th
  • Now larger responses with Extension mechanisms for DNS

3.3 URIs, URLs, URNs

  • More on names

3.3.1 Uniform Resource Identifier (URI)

3.3.2 URIs

  • (Somewhat) Uniform
    • Different types of IDs under consistent format
  • Syntax for absolute URIs
  • Subsume URLs and URNs

3.3.3 URLs, URNs

  • Clarification in RFC 3305
    • Uniform Resource Locator (URL)
      • “URL is a useful but informal concept”
      • Identification of web resources via primary access mechanism
        • Network location, address of access point
      • Scalable
      • Address, thus potentially invalid
    • Uniform Resource Name (URN)
      • Permanent, location independent name of web resource
      • Registration of URN and URL for resource with URN-service
      • urn:… (RFC 8141)
      • E.g., urn:nbn:de:1111-200606299

3.4 Decentralized Namespaces

  • Desirable properties
    • Security, with variations
      • Self-authenticating: Given name-value pair, anyone can verify that both belong together
      • Strong ownership: Proof of name ownership with digital signatures
    • User-chosen names: Readable, memorizable
    • Decentralization: Users register names without central authorities

3.4.1 DNS in Relation to Zooko’s Triangle?

4 Conclusions

4.1 Summary

  • DNS is prime example for name service and distributed system
  • DNS servers manage resource records in zones
  • Zooko’s triangle points to limitations

4.2 Outlook

  • Recent discussion about DNS over HTTPS (DoH)
    • Resolve DNS names over HTTPS
      • No plaintext
    • Ungleich blog, August 2018
      • Firefox Nightly uses Cloudflare as default
      • Centralization step, single point of failure, single point of surveillance


License Information

Source code and source files for this presentation are available on GitLab under free licenses.

Except where otherwise noted, this work, “Naming and DNS”, is © 2018 by Jens Lechtenbörger, published under the Creative Commons license CC BY-SA 4.0.

No warranties are given. The license may not give you all of the permissions necessary for your intended use.

In particular, trademark rights are not licensed under this license. Thus, rights concerning third party logos (e.g., on the title slide) and other (trade-) marks (e.g., “Creative Commons” itself) remain with their respective holders.