Course material - Norid

An Introduction to DNS The Domain Name System Jim Reid [email protected]

Thursday, 7 November 13

INTRODUCTION • The DNS in action • What does it do? • How is it used? • Components, roles & responsibilities • Weaknesses/vulnerabilities Thursday, 7 November 13

Objectives • An understanding of how the DNS works •

What happens when a lookup is made

•

Zone files and resource records

• The key components of DNS and how they interact • Core concepts & jargon • Fundamental building blocks • Debunk common misconceptions Thursday, 7 November 13

What is not covered • How to configure and manage a DNS server • Choosing DNS solutions •

hardware/software/services/tools/vendors

•

... or deploy it

• DNS debugging and troubleshooting • How to design a DNS solution for your environment Thursday, 7 November 13

THE DNS IN ACTION This Section outlines shows what happens when a DNS lookup is made: What actors are involved and what they do The processes that take place Some core concepts


DNS In Action • What happens when someone clicks on a link or types in a domain name into their web browser?

• • •

DNS finds the IP address of the web server Browser makes a connection to that IP address Web pages fetched over that connection

• But what’s going on behind the scenes? Thursday, 7 November 13

DNS In Action • Web browser on wallace.rfc1035.com wants to connect to Norid’s web server, www.norid.no

• DNS maps the domain name (www.norid.no) into its current IP address, 158.38.130.37

•

Something on wallace makes a DNS query to find out which IP address its web browser needs to contact

sends a DNS lookup to its local DNS server, • wallace gromit.rfc1035.com

• What actually happens? Thursday, 7 November 13

Before the Lookup • Starting conditions: •

wallace knows essentially nothing apart from the IP address of gromit where it should send DNS queries

•

DNS server on gromit knows where the Internet’s root name servers are and how to query them

• Don’t worry (for now) where this configuration information comes from


A DNS Lookup - 1 Web browser on wallace queries 195.54.233.69 - its local name server, gromit.rfc1035.com - for the IP address of www.norid.no

gromit.rfc1035.com

wallace.rfc1035.com

User clicks on a link to Thursday, 7 November 13

http://www.norid.no

A DNS Lookup - 1 Web browser on wallace queries 195.54.233.69 - its local name server, gromit.rfc1035.com - for the IP address of www.norid.no

gromit.rfc1035.com

What’s the IP address of www.norid.no? wallace.rfc1035.com

User clicks on a link to Thursday, 7 November 13

http://www.norid.no

A DNS Lookup - 2 The name server on gromit.rfc1035.com asks a root name server, f.root-servers.net, for www.norid.no’s address

gromit.rfc1035.com

wallace.rfc1035.com


f.root-servers.net

A DNS Lookup - 2 The name server on gromit.rfc1035.com asks a root name server, f.root-servers.net, for www.norid.no’s address What’s the IP address of www.norid.no?

gromit.rfc1035.com

wallace.rfc1035.com


f.root-servers.net

A DNS Lookup - 3 The root server f tells gromit to query the .no name servers This type of response is known as a referral

gromit.rfc1035.com

wallace.rfc1035.com


f.root-servers.net

A DNS Lookup - 3 The root server f tells gromit to query the .no name servers This type of response is known as a referral

gromit.rfc1035.com

wallace.rfc1035.com


Here’s a list of the .no name servers. Ask one of them.

f.root-servers.net

A DNS Lookup - 4 The name server on gromit now asks one of the .no name servers, x.nic.no.net, for www.norid.no’s address

gromit.rfc1035.com

f.root-servers.net

wallace.rfc1035.com x.nic.no


A DNS Lookup - 4 The name server on gromit now asks one of the .no name servers, x.nic.no.net, for www.norid.no’s address What’s the IP address of www.norid.no?

gromit.rfc1035.com

f.root-servers.net



A DNS Lookup - 5 x.nic.no returns a referral to gromit, but this time it’s for the norid.no name servers

gromit.rfc1035.com

f.root-servers.net



A DNS Lookup - 5 x.nic.no returns a referral to gromit, but this time it’s for the norid.no name servers

Here’s a list of the norid.no name servers. Ask one of them. gromit.rfc1035.com

f.root-servers.net



A DNS Lookup - 6 gromit now queries a .norid.no name server, server.nordu.net, for www.norid.no’s address

f.root-servers.net

gromit.rfc1035.com

wallace.rfc1035.com server.nordu.net


x.nic.no

A DNS Lookup - 6 gromit now queries a .norid.no name server, server.nordu.net, for www.norid.no’s address What’s the IP address of www.norid.no?

f.root-servers.net

gromit.rfc1035.com



x.nic.no

A DNS Lookup - 7 server.nordu.net, returns www.norid.no’s IP address to gromit

f.root-servers.net

gromit.rfc1035.com



x.nic.no

A DNS Lookup - 7 server.nordu.net, returns www.norid.no’s IP address to gromit

gromit.rfc1035.com

Here’s the IP address for www.norid.no.

f.root-servers.net



x.nic.no

A DNS Lookup - 8 At last! gromit returns www.norid.no’s address to wallace, who has been patiently waiting for an answer to the query it made

f.root-servers.net

gromit.rfc1035.com



x.nic.no

A DNS Lookup - 8 At last! gromit returns www.norid.no’s address to wallace, who has been patiently waiting for an answer to the query it made Here’s the IP address for www.norid.no.

f.root-servers.net

gromit.rfc1035.com



x.nic.no

After the Lookup - 1 • wallace is not much wiser: • it still knows where to send its DNS queries • that hasn’t changed web browser was told the IP address(es) for • its www.norid.no • web browser might (or might not) remember that for a few minutes or so

• nothing to do with the DNS if that happens or not...


After the Lookup - 2 • gromit has learned a few things: • the names and IP addresses of the .no name servers • the names and IP addresses of the .norid.no name servers

• the IP address(es) for www.norid.no

• gromit’s name server remembers this for a while • known as cacheing • DNS answers include time-to-live (TTL) values Thursday, 7 November 13

Cacheing - 1 Something on wallace now asks gromit for the IP address of Norid’s calendar server, cal.norid.no

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 1 Something on wallace now asks gromit for the IP address of Norid’s calendar server, cal.norid.no What’s the IP address for cal.norid.no?

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 2 gromit directly asks a norid.no name server for the IP address of cal.norid.no - no need to query the root or .no name servers first

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 2 gromit directly asks a norid.no name server for the IP address of cal.norid.no - no need to query the root or .no name servers first What’s the IP address of cal.norid.no?

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 3 server.nordu.net answers the query from gromit

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 3 server.nordu.net answers the query from gromit

Here’s the IP address of cal.norid.no f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 4 gromit returns the IP address of cal.norid.no to wallace

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Cacheing - 4 gromit returns the IP address of cal.norid.no to wallace Here’s the IP address for cal.norid.no.

f.root-servers.net

gromit.rfc1035.com



x.nic.no

Further Lessons

• The root servers don’t know or care about norid.no •

They do know where the name servers for .no are

• The name servers for .no don’t know or care about www.norid.no and cal.norid.no either

•

They know norid.no exists and where its name servers can be found

• The name servers for norid.no know about www.norid.no and cal.norid.no

• None of the above name servers go looking for stuff •

They answer queries but don’t make any


Even Further Lessons • There are no connections •

DNS traffic mostly uses UDP, not TCP

• • •

Eventually give up if nothing responds (or reply gets lost)

• Something makes a query and waits for an answer That’s why it’s bad to have just one DNS server If one server isn’t available, just try another

•

Hope some DNS server, somewhere will eventually reply

• DNS transactions (query/response) are small •

Overheads of setting up a connection are too high


It’s not quite that simple... • What’s just been described has been simplified • In reality, things are rather more complex: • • •

There are well over 300 root name servers Both .no and norid.no have many name servers wallace will/should have other name servers to query if gromit is dead or unreachable

• These operational details don’t matter (for now) •


Unless your job is to provide reliable DNS service!

Initial Configuration Info - 1 • When we started: •

wallace knew nothing apart from the IP address(es) where it could send DNS queries

• Key information for just about everything connected to the Internet

• •

/etc/resolv.conf - Unix (like) systems Registry settings - Windows

• Usually provided from the DHCP server whenever a device joins a network

• Thursday, 7 November 13

Sometimes gets configured by hand

Initial Configuration Info - 2 • DNS server on gromit knew the names and IP addresses for the Internet’s root name servers

•

Usually obtained from a name server configuration file or hard-coded in the software

•

Root server names and IP addresses rarely change

• When the name server on gromit started it issued a priming query to get the current names and addresses for the root servers

•

Initial configuration info just serves as a hint


What have we learned? • The DNS has dumb clients that just make queries • •

Known as stub resolvers

•

Ones which only answer queries

Usually configured via DHCP

• There are two main types of DNS server: •

•

Ones which make queries to authoritative servers and also answer stub resolvers

• • Thursday, 7 November 13

Known as authoritative servers

Known as resolving name servers Make priming queries to root servers at start-up

WHY DNS WAS INVENTED DNS is over 25 years old. This Section explains why it was invented and the problems it was designed to solve. Design goals Weaknesses


A Short History Lesson • Forerunner of the Internet was ARPAnet • Centralised HOSTS.TXT file (until 1980s) • •

Names and addresses of everything on the ARPAnet Obvious scaling & updating problems

• • • •

Every name had to be unique Everyone had to convert this file to their local format Propagation issues for updates Maintenance headache for everyone

• Solution: the Domain Name System (DNS) Thursday, 7 November 13

DNS Design Goals • Scalability •

Should have no constraints on growth

•

=> no centralised database

•

Local info managed & updated locally

•

Network of name servers would know how to traverse it

• Timely, accurate data • No centralised control • Robustness & Flexibility • Common, hierarchical name space Thursday, 7 November 13

Scalability • DNS protocol should have few limits • •

Largely constrained by hardware & laws of physics No practical limitations

• Hierarchical structure allows near-infinite delegation of control & administration

• •

Each organisational unit, a domain, is self-contained No need to know or care about what names someone else is using


Every Computer Science department would at last be able to call their minicomputer csvax

Timely, Accurate Data • Local address/name mapping data managed locally • •

Just update local DNS server when something changes No need to “push” updates to a central location

•

Or wait for the world to grab a new HOSTS.TXT file and update their local equivalent

• Local updates propagated immediately to everyone: •

The world simply navigates to the DNS server(s) holding the info for whatever’s on some other network as and when the need arises


Delegation • Notion of parent and child •

Parent delegates control of some part of the name space to a child

•

Someone else becomes responsible for that:

•

Managing its DNS servers, maintaining & updating zone data, naming conventions/standards, etc.

• Parts of the name space get delegated as and when needed for operational or policy reasons

• Hierarchical structure allows for sub-delegation •

And sub-sub-delegation and....


Robustness & Flexibility - 1 • ~30 years ago, it was not clear which network protocol(s) would win

•

DNS aimed to accommodate them all

• • •

Well, compared with X.500 or SNA or DECnet or...

• Simplicity was key, sort of Issues of security & authentication were side-stepped Priority was to get something out the door that worked and was straightforward to deploy

• Diversity at the root meant no single point of failure or control


Robustness & Flexibility - 2 • DNS was designed to accomodate all the network protocol families of the day: SNA, OSI, Chaosnet, DECnet, IP, etc.

•

Resource records could in theory represent anything

•

Delegation of authority could be done anywhere

•

Only limit is the length of a domain name

• The name space could be extended arbitrarily • No limitations on character sets • Design aimed to prevent single points of failure Thursday, 7 November 13

Hierarchical Name Space • Obvious choice: •

A tree structure which grows from a root

•

Pathnames in file systems, E.164 phone numbers, etc.

• Other examples: • DNS root started with a handful of “well known” top-level domains (TLDs):

• • Thursday, 7 November 13

.com, .edu, .org, .net, .gov, .mil & .arpa ~200 two-letter ISO-3166 country codes added later

•

.no, .us, .se, .fi, etc.

The DNS Name Space root com google maps Thursday, 7 November 13

facebook

www

no

tel

www

google

jim maps

www

norid epp

www

Vulnerabilities • No security model • • •

Authentication Privacy/confidentiality Access controls in the protocol:

•

Who gets to “see” or update what

• Datagram-based transport is a vector for spoofing and nasty (D)DoS attacks

• DNS root becomes focus for all sorts of concerns •


Operational, accountability, governance, political, etc.

Protocol Weaknesses • Initial design compromised by the then networks • •

Bandwidth was a concern

•

64KB link for an entire university campus...

=> DNS headers were tiny

•

DNS packets were tiny too

• Little space for header bits or opcodes • 16-bit query IDs • EDNS was developed later to “fix” this Thursday, 7 November 13

DNS CONCEPTS Key DNS concepts are explained in this Section: A definition of the Domain Name System Components: hardware/software/protocol The Name Space Fundamental principles


What is DNS? • Domain Name System • •

It's a protocol & ubiquitous, global lookup service

•

Mostly maps names to addresses and vice versa

DNS is NOT a directory

• Lookups keyed on domain name and type •

•

Not only for name-address mapping

Mail routing, identifying end-points for VoIP, etc.

• Buzzword bingo: •

A hierarchical, loosely coherent name space and lightweight, distributed lookup service


DNS Mapping Function • Not just address/name mapping: • • •

ENUM & .tel gTLD

• •

Lookup NAPTR records which identify URLs Private ENUM trees heavily used inside telco networks for call routing, number portability, etc.

RFID tags

•

Unique serial numbers on RFID tags become domain names and get looked up in the DNS

•

EPC Global’s ONS

IETF DANE Working Group

•


Store X.509 certificates & crypto keys in DNS

DNS Components • Clients & Servers • Hold data, make & answer queries

• Name Space • An inverted tree containing all the names and related data that are stored in the DNS

• Software • For making and answering queries (obviously) • Tools to provision/manage DNS data and servers

• Protocol • The standards used by client and server software to communicate with each other Thursday, 7 November 13

Basic Components Hardware • Clients: typical edge devices that make queries • Laptops, workstations, smart phones, tablets, DSL/cable modems etc. • Might also send DNS updates (or have them sent)

• Servers: hold data and answer queries • May also interrogate other name servers to find answers for clients • Some servers act as an “agent” for client that made the initial query • Also cache data returned from lookups Thursday, 7 November 13

Basic Components Software • Three elements/roles: • Stub resolver • Part of system software, usually a shared library or DLL • Resolving name server • Typically set up & run by local ISP or system administrator • Can be business-critical • Authoritative name server • Operated by people who publish DNS data • VERY important for some organisations Thursday, 7 November 13

Key DNS Concepts - 1 • Universality •

No matter where you are, what OS/hardware platform you use, which application you use or which name server you query, a DNS lookup will always return the same answer for the same query

• No single points of failure (SPoF) • •

Should be obvious enough If DNS fails, the Internet appears to stop even though everything else is working perfectly:


Routers, links, mail/web/SIP servers, etc.

Key DNS Concepts - 2 • DNS data organised into zones: •

Each zone is an individual component of the name space maintained and managed independently of any other

•

What someone stores in some zone is up to them alone

• •

Fundamental building blocks

• Zones are assembled from resource records Map some name on to “something else”: an IP address, a host name, service location, URL, etc.


The Name Space • The name space is the structure of the DNS database and everything in it

•

An inverted tree with the root node at the top

root com google Thursday, 7 November 13

facebook

no

tel jim

google

norid

The DNS Protocol • Defines how DNS clients and servers talk to each other:

• • •

Port number (53), packet format & headers, etc.

•

De facto behaviour is to follow the open source reference implementation, BIND

Designed to be simple and fast “Atomic” query/response, mostly datagram based

• Specifications controlled by IETF Thursday, 7 November 13

DNS Requests & Responses DNS packets consist of:


DNS Requests & Responses DNS packets consist of: A Header Section


DNS Requests & Responses DNS packets consist of: A Header Section A Question Section


DNS Requests & Responses DNS packets consist of: A Header Section A Question Section An Answer Section


DNS Requests & Responses DNS packets consist of: A Header Section A Question Section An Answer Section An Authority Section


DNS Requests & Responses DNS packets consist of: A Header Section A Question Section An Answer Section An Authority Section An Additional Section


DNS Requests & Responses DNS packets consist of: A Header Section A Question Section An Answer Section An Authority Section An Additional Section Responses include Header and Question Section of the original request Answer, Authority and Additional Sections empty in requests (obviously) Answer, Authority and Additional Sections can be empty in responses Thursday, 7 November 13

DNS Header Format

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


DNS Header Format Query ID (16 bits)




Query Response




Query Response

DNS Opcode




Query Response

DNS Opcode

Status bits




Query Response

DNS Opcode

Status bits


1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Response Code


Query Response

DNS Opcode

Status bits



Resource Record counts for Question, Answer, Authority & Additional Sections

Response Code

Resource Record Format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


R

Resource Record Format Domain Name


1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

R


Record Type



R


Record Type

Usually IN (Internet)



R


Record Type



32-bit Time to live (in seconds) Thursday, 7 November 13

R


Record Type



1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Length of 32-bit Time to resource record’s live (in seconds) RDATA

R


Record Type



1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Length of 32-bit Time to resource record’s Resource live (in seconds) RDATA Record’s RDATA

R

Basic Jargon - 1 •

Functionally two types of name server:

• •

•

Authoritative

• •

Serve data for some zone or set of zones Generally expected to just answer queries from other name servers

Recursive (or cacheing)

• •

Answer queries from stub resolvers (mostly) Query authoritative servers

The most common DNS implementation combines these roles in a single binary

•

Can be discrete executables


Basic Jargon - 2 • Clients generally perform naive lookups: • •

Just send a query and wait for a reply Done by a stub resolver

•

e.g. UNIX res_nmkquery() API in shared C library

• Queries sent to local resolving name server •

Known as full service resolver in DNS jargon

• •

This process is known as resolving

service resolver makes iterative queries to get • Full the answer Also caches answers from the servers it queried


Basic Jargon - 3 node in the tree - a location in the name space • Each is a domain

• •

Might also be a zone

• •

Typically administered as ASCII text files

Every domain includes any descendent nodes (subdomains)

• DNS data is organised into zones Zones contain resource records


Basic Jargon - 4

• Zones and domains •

These are different, though many people confuse them

•

Composed of many subdomains (nodes)

• Root domain consists of everything in the DNS •

•

Which are composed of even more subdomains

It’s far too big and impractical to enumerate

• Root zone is small: •

Info about the known top-level domains (TLDs)

• A zone’s analogous to a directory file in the filesystem domain is comparable to everything under that • Adirectory: ie all files and subdirectories Thursday, 7 November 13


• • •

Zone files

•

Contain resource records

• • •

Addressing info such as A & AAAA records DNS metadata: SOA & NS records ENUM: NAPTR & SRV records

Master (primary) server

•

Where all changes to the zone are performed

Slave (secondary) server

•

Automatically takes new copy of zone from master

Configuration file defines which zones are served and how/where their zone files are located



•

Delegation

• • • •

Creation of subdomains Transfer of authority Key to the success & scalability of the DNS Zone contents managed locally

Customer (registrant) gets a registrar to get their domain name entered in the appropriate registry

•

e.g. example.no registered in .no registry and delegation info is published in the .no zone

•

Customer is responsible for updating & managing the DNS data in example.no


RESOURCE RECORDS Resource records are the fundamental building blocks of the DNS. The most commonly used ones are explained in this Section DNS metadata Name to address mapping Address to name mapping Aliasing Mail delivery Service location Thursday, 7 November 13

Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA


Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA OWNER-NAME - a domain name


Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA OWNER-NAME - a domain name TTL - Time To Live (cache value in seconds)


Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA OWNER-NAME - a domain name TTL - Time To Live (cache value in seconds) CLASS - Almost always IN (Internet)


Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA OWNER-NAME - a domain name TTL - Time To Live (cache value in seconds) CLASS - Almost always IN (Internet) TYPE - resource record type


Resource Records • General representation as text: • OWNER-NAME TTL CLASS TYPE RDATA OWNER-NAME - a domain name TTL - Time To Live (cache value in seconds) CLASS - Almost always IN (Internet) TYPE - resource record type RDATA - data for this owner-name/type tuple


The A Record • Represents an IPv4 address: •

foo.rfc1035.com. 86400 IN A 10.1.1.1

• •

foo.rfc1035.com. 86400 IN A 10.1.1.1

• Use multiple A records for a multi-homed host: foo.rfc1035.com. 86400 IN A 10.1.1.2

• IP address written in dotted decimal notation • No limits on numbers of domain names for an IPv4 address or IP addresses for a domain name

• Names should conform to host name syntax


The AAAA Record • Represents an IPv6 address: •

localhost.example.net. 600 IN AAAA ::1

• •

example.net. 600 IN

AAAA 2001:500:2f::f

example.net. 600 IN

AAAA 2001:500:2f::53

• Use multiple AAAA records for a multi-homed host: • IPv6 address written in colon notation • No limits on numbers of domain names for an IPv6 address or IPv6 addresses for a domain name

• Names should conform to host name syntax


The MX Record

• For mail delivery •

norid.no. norid.no.

3600 3600

IN MX 10 dike-ac.uninett.no. IN MX 20 dike-ac.ipv4.uninett.no.

• RDATA fields: • •

• •

Priority - lowest is preferred Hostname - should exist as an A or AAAA record

dike-ac.uninett.no is norid.no’s mail server dike-ac.ipv4.uninett.no is a fallback

•

Deliver email there for store & forwarding whenever dike-ac.uninett.no is unreachable


The CNAME Record

• A nickname or alias for some other name • •

printer.norid.no. 3600 IN CNAME epson123.norid.no. printer.norid.no.

points to epson123.norid.no.

• Target can be in another domain •

•

www.rfc1035.com. 3600 IN CNAME host1234.webhost.net.

Web server for rfc1035.com is located at host1234.webhost.net.

• Can’t have ANY other RRtypes for a name that exists as a CNAME

• Avoid chains: CNAME1 points to CNAME2 which points to...


The TXT Record • Free format text: • norid.no

600 IN TXT “Once upon a time..”

• RDATA can be up to 64Kbytes • Typically used for version control and contact or status info

•

Sometimes used for SPF email validation

•

What if there are many TXT records for yourdomain.no?

• Use sparingly Thursday, 7 November 13

The SRV Record - 1 • For service location • • •

Can do load-balancing (sort of)

•

Think MX record on steriods...

Commonly found in Active Directory setups

•

Also seen in Bonjour environments

Some SIP & Jabber clients/servers use these too

• Not usually provisioned/managed by hand • Defined in RFC2782 Thursday, 7 November 13

The SRV Record - 2 _Service._Proto.Name TTL IN SRV Priority Weight Port Target


The SRV Record - 2 _Service._Proto.Name TTL IN SRV Priority Weight Port Target _Service -


Name of network service


Name of network service Transport protocol (ie UDP or TCP)

_Service _Proto -



Name of network service Transport protocol (ie UDP or TCP) - Domain name this RR refers to

_Service _Proto Name



Name of network service _Proto - Transport protocol (ie UDP or TCP) Name - Domain name this RR refers to Priority - Priority field (0 is highest priority) _Service -



Name of network service _Proto - Transport protocol (ie UDP or TCP) Name - Domain name this RR refers to Priority - Priority field (0 is highest priority) Weight - Server Selection (weighting factor) _Service -



Name of network service _Proto - Transport protocol (ie UDP or TCP) Name - Domain name this RR refers to Priority - Priority field (0 is highest priority) Weight - Server Selection (weighting factor) Port - Port Number _Service -



Name of network service _Proto - Transport protocol (ie UDP or TCP) Name - Domain name this RR refers to Priority - Priority field (0 is highest priority) Weight - Server Selection (weighting factor) Port - Port Number Target - Domain name for server _Service -


The SRV Record - 3 Example: _kpasswd._udp.norid.no. IN SRV 0 0 464 kerberos5.norid.no. _kpasswd._udp.norid.no. IN SRV 100 0 761 kerberos4.norid.no.

Find the kpasswd service for norid.no at kerberos5.norid.no and kerberos4.norid.no Use UDP Prefer UDP port 464 on kerberos5.norid.no (Kerberos 5?) Then UDP port 761 on kerberos4.norid.no (Kerberos 4?) Underscores used to prevent collisions with host names


The PTR record - 1 • Used for reverse lookups •

Address to name mappings

•

Get hostname for 10.1.2.3 by doing a PTR lookup for 3.2.1.10.in-addr.arpa

• IPv4 addresses in in-addr.arpa domain • Example: •

3.2.1.10.in-addr.arpa. IN PTR host1.example.com.

•

Hostname for 2001:700:0:4513::130:37 means a lookup for

• IPv6 addresses in ip6.arpa domain 7.3.0.0.0.3.1.0.0.0.0.0.0.0.0.0.3.1.5.4.0.0.0.0.0.0.7.0.1.0.0.2.ip6.arpa.


The PTR record - 2 •DNS doesn’t know or care if an A or AAAA record has a corresponding PTR record (or vice versa)

•Other applications might (e.g. mail servers) •An active IP address should have one PTR record for the actual hostname for the device

•Can be impractical for IPv6 SLAAC hosts •DNS allows >1 PTR record for an IP address •This is a very bad idea. Don’t do it. Thursday, 7 November 13

The SOA Record - 1 • Start Of Authority • Found at the start (apex) of a new zone • Fundamental DNS metadata • Fairly complicated Thursday, 7 November 13

The SOA Record - 2 no.

86400 IN SOA ( charm.norid.no. hostmaster.norid.no. 2013102928 14400 1800 2419200 86400 )





MNAME master server







RNAME admin contact







SERIAL - zone version number







REFRESH - serial number check interval







RETRY - retry interval for failed refreshes







EXPIRE - zone expiration interval







TTL - negative cache interval

The SOA Record - 9 • MNAME - usually the name of zone’s master server • •

Should be correct if using dynamic update

• • •

Replace first dot with @ sign:

Some just use a random string (in hostname syntax)

• RNAME - “email address” for zone administrator


i.e. [email protected] A bit clunky:

•

@ sign is a DNS metacharacter when representing resource records as text

The SOA Record - 10 • SERIAL - serial number • •

Must increase when the zone contents change

•

1, 2, 3.... shows a lack of imagination

•

Number of seconds between slave server checks of the zone’s SOA serial number

YYYYMMDDVV or seconds since UNIX epoch are common conventions

• REFRESH • Thursday, 7 November 13

If serial number has increased (i.e. master server has a newer version of the zone), fetch a new copy

The SOA Record - 11

• RETRY •

Time for a slave to try contacting the master after a failed refresh check

• EXPIRE •

How long (in seconds) a slave server can be authoritative for the zone without any contact with the master server

• TTL • •

Negative time-to-live interval in seconds

•

Remember how long some name/RRtype did not exist

Used to be default TTL

•


Behaviour changed in 1998 (RFC2308)

The NS Record - 1 • Fundamental DNS metadata: •

Key to creating a delegation

• •

NS record set in both zones should be the same

• Found in both the parent and child zones

•

Really should be at least 2 NS records for each zone

•

Avoid single points of failure

Lots of people get this wrong

• RDATA of an NS record should be a host name •

Lots of people get this wrong too


The NS Record - 2

• Example:

• norid.no. 86400 IN NS server.nordu.net. • norid.no. 86400 IN NS nac.no. • server.nordu.net. and nac.no. are name servers for norid.no.

• •

They should exist as an A or AAAA record They should not exist as a CNAME

•

Or a dotted-decimal IP address!

• Target of NS record can be in any domain provided that name resolves to an IP address


Glue

• Suppose ns1.example.no. is a name server for the example.no zone:

•

example.no. 600 IN NS ns1.example.no.

• •

This is known as glue or a glue record

• How can a name server resolve this? the parent adds an A or AAAA record for • Simple: ns1.example.no. Returned in the parent’s referral response

• Common mistake is to forget to get the glue

updated whenever a name server is renumbered


Visualising Delegation


Visualising Delegation In the .no zone: no. ...... SOA .... ... example.no. 600 IN NS ns1.example.no. example.no. 600 IN NS ns1.example.net. ns1.example.no. 600 IN A 10.9.8.7



In the example.no zone

example.no. ...... SOA ... example.no. 600 IN example.no. 600 IN ns1.example.no. 600 IN


.... NS ns1.example.no. NS ns1.example.net. A 10.9.8.7


In the example.no zone

example.no. ...... SOA ... example.no. 600 IN example.no. 600 IN ns1.example.no. 600 IN


....

These should match!

NS ns1.example.no. NS ns1.example.net. A 10.9.8.7

SOA & NS Records as DNS Metadata • These RRtypes are fundamental DNS metadata • Every zone MUST have exactly one SOA record • Every zone MUST have at least one NS record •

Two or more would be better...


HOW THE DNS WORKS This Section outlines how the DNS works and explains: Master and Slave Servers Zone transfers & NOTIFYs EDNS0 Dynamic Updates Single Points of Failures Popular DNS misconceptions


Master & Slave Servers • Every important DNS zone has at least 2 name servers • One of these is the master: the one place where the zone gets updated

• Changes propagated to the slave servers • Resolving servers don’t need to know (or care) which server is the master for some zone

•

They just query what should be an authoritative server

• Old jargon was primary/secondary rather than master & slave


Zone Transfers • Slave (secondary) servers periodically check if

there’s a new version of the zone at the master

•

Look at SOA serial nunber every REFRESH interval

• If/when there’s a new version, initiate a zone transfer (AXFR) to copy it from the master server

• •

uses TCP, not UDP AXFR is not a byte-for-byte file copy

• Incremental zone transfers (IXFRs) just move the deltas

•

Documented in RFC1995


Zone Synchronisation • Master server should increment the serial number whenever the zone is updated

•

Everyone has forgotten do this at some point!

• Serial numbers are unsigned 32-bit integers and just “wrap around” - see RFC1982

•

A value of 1 considered greater than 4294967295 (232-1)

• Slave servers periodically check SOA serial number on the master & slurp new versions as needed

• •

Hence loose coherency... Window when a slave may have older data than master


NOTIFY • Extra DNS operation defined in RFC1996 • Faster convergence of updated zones • Master server sends NOTIFYs to slaves when it loads a new version of the zone

• Slaves should do an immediate SOA serial number check and request a transfer of the new version

• No need to wait until slave’s REFRESH timer

expires before doing the serial number check


EDNS(0) • Need for bigger payload in UDP responses • Also needed more bits for header/status information • Couldn’t change existing DNS headers & formats • Solution: DNS Extension Mechanism, EDNS • • •

Defined in RFC2671 Clients can tell servers they accept jumbograms An EDNS header bit signals DNSSEC readiness:

•


DO - DNSSEC OK

Dynamic Update • Documented in RFC2136 • Send DNS request to master server to update the zone

• •

=> No more scripts or hand-editing of zone files Master server is in charge of everything

• Used by some registrars & enterprise DNS tools • Obvious access control & authentication issues • Underpins Active Directory setups Thursday, 7 November 13

Single Points of Failure • Avoid: • •

All servers running the same software (DNS & OS)

•

All servers in the same room, building, co-lo facility, city, country, continent

• • •

Depending on a single ISP (or AS number) for connectivity

All servers on the same subnet or behind one router, firewall, switch, etc.

Single physical paths for data cables, power, fibre, ducts Common system/network admin procedures

• Trade-offs & cost/benefit analyses have to be made


Common Misconceptions • Queries go to the master server first, and only fall back to the slave(s) on failure or timeout

• •

Resolving servers don’t know or care about that at all Resolving servers generally favour the authoritative server that answers quickest

•

The Right Things usually happen automatically whenever an authoritative server goes away or comes back or a new one gets added

• DNS traffic always goes over UDP • DNS queries and replies are always < 512 bytes Thursday, 7 November 13

Common Misconceptions • Queries go to the master server first, and only fall Resolving servers don’t know or care about that at all Resolving servers generally favour the authoritative server that answers quickest The Right Things usually happen automatically whenever an authoritative server goes away or comes back or a new one gets added

W

•

RO

• •

N G

!

back to the slave(s) on failure or timeout

• DNS traffic always goes over UDP • DNS queries and replies are always < 512 bytes Thursday, 7 November 13

Common Misunderstanding • “If my network connection goes down, DNS doesn’t matter”

• VERY WRONG! • The rest of the Internet will still try to reach you: •

Send email, visit web site, etc.

•

May cause operational problems elsewhere

• Their DNS lookups will time out or fail •

•

e.g. mail bounces, weird failures by server software

DNS servers would be considered “dead” and get ignored for a while even once they are back on-line


Common Misunderstanding • “If my network connection goes down, DNS doesn’t

!

matter”

N G

• VERY WRONG! • The rest of the Internet will still try to reach you: Send email, visit web site, etc.

•

May cause operational problems elsewhere

RO

•

•

•

W

• Their DNS lookups will time out or fail e.g. mail bounces, weird failures by server software

DNS servers would be considered “dead” and get ignored for a while even once they are back on-line


NAMING The protocol standards for names are explained in this section: Differences between domain names and hostnames How non-ASCII characters and scripts are handled


What’s a Domain Name? • A sequence of labels delimited by dots • Labels are up to 63 bytes long • •

No limitation on character set Yes, a label could contain white space or the ø character

•

Or even a dot....

• Maximum length of a domain name is 255 bytes, including the dot delimiters

• Effective maximum length is actually 253 bytes •

Implicit dot and terminating NUL byte not usually written


What’s a Host Name?

• A subset of the name space of domain names •

Uses a much more restricted character set

•

Labels for hostnames can only use letters, digits and the hyphen character: A-Z, a-z, 0-9 & -

• Defined in RFC1123 • This limitation is inherited by standards defining email addresses and URLs (amongst other things)

• Some protocols deliberately use domain names with underscore characters to avoid the possibility of collisions with legal hostnames


Case Sensitivity • Hostnames and domain names are case insensitive •

mydomain.com, MyDomain.Com & MYDOMAIN.COM are

identical in DNS terms

• Lookups and responses might not preserve case •

Query for example.com, get answer for EXAMPLE.COM or vice versa


IDNs • DNS is 8-bit clean •

Other protocols (e.g. email) are not...

• •

Awkward for many European languages/scripts

•

Horrifically complicated because languages are even more complicated

• How to deal with non US-ASCII characters? Far bigger problem for scripts like Chinese, Arabic, etc.

• Solution: Internationalised Domain Names • Thursday, 7 November 13

•

Social, cultural and sovereignty issues

Defined in a raft of RFCs 5890-5895

More on IDNs • General approach: • Use Unicode and “translate” to US-ASCII • •

Produce strings of the form “xn--something” Japanese for test - 測試 - encoded as xn--g6w251d

• In principle a web browser or mail client (say) would know how to do these conversions:

•

e.g. Present xn--something label as the relevant Unicode characters in (say) Kanji/Hiragana/Katakana

• ~60 IDN TLDs today: more coming soon Thursday, 7 November 13

Managing DNS Content • Lots of DNS zones use text-based files • • •

Historical legacy Manual editing with a screen editor is still common Naive users get a GUI of some sort

• Very large zones or large numbers of zones usually held in a database

•

Might feed the DNS servers directly or run scripts to generate text-based zone files

• Can use octal \000 notation for non-printable characters - depends on implementation


DNS VULNERABILITIES This Section explains some of the vulnerabilities in the DNS and outlines how to protect against them Interfering with DNS packets Cache poisioning The problems DNSSEC solves and does not solve


Remember this? gromit returns www.norid.no’s address to wallace, who has been patiently waiting for an answer to the query it made

f.root-servers.net

gromit.rfc1035.com



x.nic.no


f.root-servers.net

gromit.rfc1035.com



x.nic.no


f.root-servers.net

gromit.rfc1035.com



x.nic.no


f.root-servers.net

gromit.rfc1035.com



x.nic.no


f.root-servers.net

gromit.rfc1035.com



x.nic.no

What’s Wrong With That? • Nothing: it all works just fine….. • BUT there’s no authentication at all! • A client can’t tell: • Where an answer really came from • If the server that replied is telling the truth or not • If it received exactly what the server sent • This applies to wallace.rfc1035.com’s

query and the lookups gromit.rfc1035.com performed to resolve that query


So where are the vulnerabilities?

f.root-servers.net

gromit.rfc1035.com



x.nic.no


Here! f.root-servers.net

gromit.rfc1035.com



x.nic.no


Here! Here! f.root-servers.net

gromit.rfc1035.com



x.nic.no


Here! Here!


gromit.rfc1035.com



x.nic.no


Here! Here!


gromit.rfc1035.com

Here! wallace.rfc1035.com server.nordu.net


x.nic.no


Here! Here!

Here!

Here!


gromit.rfc1035.com

Here! wallace.rfc1035.com

Here! server.nordu.net


Here! x.nic.no

Attacking the DNS - 1 •

• •

Bombard client or resolving server with forged answers

• • •

Guess what the outgoing query might be Successful Kaminsky attack “predicts” Query IDs Brute force might well be viable

Intercept a response packet & modify it

•

Tends to only work well if adjacent to client or server

Set up a fake name server for some zone

•

Trick other name servers into querying the fake one

•

Cache poisoning attacks

• Inject bogus data into caches Thursday, 7 November 13

Attacking the DNS - 2 •

Take control of the name server(s) for some zone

•

Make it answer with false data

•

Gain unauthorised access to registrar account and change the victim zone’s delegation to point at bogus name servers

•

Several prominent examples recently:

• Compromise the registry

•

•

New York Times, twitter, google.ccTLD

Evil routing/peering tricks to hi-jack traffic

•

Introduce bogus routes for the root servers (or the name servers for any other “interesting” zone)


What Does This Mean? • A regular DNS client really can’t be sure of anything: a lookup for www.norid.no really get • Did answered by the norid.no name servers? it get what a real norid.no name server • Did actually sent? name server that answered telling the truth, • Isthethewhole truth and nothing but the truth?


OK, What Does This Really Mean? the DNS provide the actual address of Norid's • Did web/mail/whatever server? my web browser talking to the One True • Isnorid.no web site? I be sure my email is going to the norid.no • Can mail server? free to replace norid.no with your favourite • Feel domain name….

• amazon.no, ebay.com, google.no Thursday, 7 November 13

Don’t Panic! • DNS is only now emerging as a target for attackers •

Plenty of easier victims elsewhere

•

IETF started working on this in the late 1990s

•

Sometimes called DNSSEC: DNS Security Extensions

• DNS problems have been known about for a long time • The solution is now being deployed, Secure DNS Thursday, 7 November 13

What Secure DNS Proves • Data integrity •

Verify what was received was exactly what the name server sent

• Non-repudiation •

Authenticate who/what signed the data

•

An answer for foo.example.com comes from the genuine name servers for example.com

•

Should be a chain of trust to the root

• Name server authenticity (in theory anyway)


What DNSSEC Can’t Do • Prevent/thwart denial-of-service attacks • Stop name server compromises • •

Buffer overflows

•

The DNS is public after all...

Environment variable leakages

• Provide confidentiality of DNS data Thursday, 7 November 13

DNSSEC Overview • Underlying technology is cryptography and digital signatures

• •

Cryptographic hash functions (SHA family, MD5) Public key crypto: RSA, DSA, ECC

• New resource records • New tools • New admin procedures Thursday, 7 November 13

DNSSEC Deployment • Swedish ccTLD was first, September 2005 • Internet root got signed July 15th, 2010 • A very, very cautious roll-out for obvious reasons • •

Awkward political problems too No one organisation has the “master key”

• Nice animation here: •

https://www.dnssec-deployment.org/wp-content/uploads/2013/09/ cctld-2013-09-10.gif

• Now it’s Norway’s turn :-) Thursday, 7 November 13

DNS ADMINISTRATION The basics of DNS administration are described in this Section: How to set up a simple zone file Configuring a DNS server to be master or slave Useful DNS tools


A Simple Zone File example.com. IN SOA ns0.example.com. hostmaster.example.com. ( 2013103100 ; serial number 10800 ; refresh 3600 ; retry 2592000 ; expire 86400 ; time to live ) example.com. IN TXT "$Id: example.com,v 1.9 2013/10/31 13:11:59 jim Exp $" example.com. example.com.

IN IN

NS NS

ns0.example.com. ns1.example.com.

ns0.example.com. ns1.example.com. example.com. mail.example.com.

IN IN IN IN

A A A A

10.9.8.7 10.1.2.3 172.16.1.1 172.16.1.1

example.com. www.example.com.

IN IN

MX 10 CNAME

mail.example.com. example.com.


Outline Master Server Setup A BIND name server’s config file would contain something like this: zone "rfc1035.com" { type master; file "/var/named/masters/rfc1035.com"; };

Be the master for the rfc1035.com zone and load the zone file from /var/named/masters/rfc1035.com


Outline Slave Server Setup A BIND name server’s config file would contain something like this: zone "rfc1035.com" { type slave; file "/var/named/slaves/rfc1035.com"; masters { 10.9.8.7; }; };

Be a slave for the rfc1035.com zone and load/store the zone file from /var/named/slaves/rfc1035.com. The zone’s master server is at 10.9.8.7 so send SOA refresh checks and zone transfer requests there Thursday, 7 November 13

Useful DNS Tools • named-checkzone • Checks zone files for syntax and semantic errors • named-checkconf • Checks name server config file, named.conf • dig • The one and only DNS lookup tool • By far the best: accept no substitutes • drill - like dig but with added diagnostics for DNSSEC


DNS AS A BUSINESS & TECHNOLOGY This Section describes how the DNS is “managed”: Protocol (standards) development Governance/oversight Top-level domains Conventional DNS business model & roles


IETF • Internet Engineering Task Force • • •

Develops & maintains most Internet protocol standards

• •

Most work done on mailing lists

•

dnsop - DNS operations

Publishes standards documents (RFCs) Based on “Rough consensus and running code” - allegedly

• Organised into Working Groups IETF meets 3 time a year

• Effectively just one WG for DNS now Thursday, 7 November 13

ICANN • Internet Corporation for Assigned Names & Numbers • • •

US non-profit company

• •

Well over 200 full-time staff

•

https://www.icann.org Multi-stakeholder governance and policy-making, mostly on domain names Main meetings 3 times a year

•

Open to anyone: no fees or memberships

Mostly funded by fees on gTLD registrations


Generic Top-Level Domains • Abbreviated to gTLDs • Overseen by ICANN (with a few exceptions) •

Policies generally determined by ICANN

• • • •

ICANN has a contract with a registry

• Usual model Registry has a contract with a registry service provider Registry has contracts with registrars Registrars sell names to the public (registrants)

• Registry-registrar-registrant model used elsewhere Thursday, 7 November 13

gTLDs •

• • •

.com, .edu, .org, .net, .gov, .int, .mil & .arpa

• • •

.gov - limited to US government .int - for international treaty organisations .mil - only for US military

7 added in 2000 (or theresabouts)

•

.info, .pro, .biz, etc.

Another 7 added by 2007

•

.mobi, .xxx, .asia, etc.

ICANN plans to add another ~1600 “soon”


.arpa • A special case • •

Used to be for everything on the (long dead) ARPAnet Now mostly used for infrastructure mappings:

• •

in-addr.arpa maps IPv4 addresses to domain names ip6.arpa for maps IPv6 addresses to domain names

• Rebranded as “Address and Routing Parameter Area” • It’s the ONLY TLD that must exist •

The TLD name is hard-coded into every stub resolver: i.e. pretty much everything connected to the Internet


ccTLDs • Country code Top-Level Domains • •

ISO-3166 defines 2-letter codes for every country

•

Also includes territories which are not “countries”

United Nations ultimately responsible for this list

• These TLDs viewed as a National Matter • •

No ICANN oversight National government/regulator decides (sometimes)

• Generally operated as non-profit spin-offs from academia


Often follow classic registry/registrar/registrant model

Classic DNS Business Model • Three key roles which should be discrete • • •

Registries Registrars Registrants

• Boundaries between these sometimes them get blurred or are allowed to overlap

•

Not the case for .no

• Analogous (sort of) to wholesale/retail/customer model used for conventional shopping


Registries - 1 • Quasi-monopoly •

Can’t have two or more registries for .no!

•

Publishes these in DNS and whois

• • •

Usually done via EPP, Extensible Provisioning Protocol

• Maintains a register (database) of domain names • Operates DNS and whois servers for the public • Provides some way for names to be registered


EPP transactions update registry database Registry database feeds public DNS and whois servers

Registries - 2 • Typically have some policy-making mechanism •

How the TLD is used, who is allowed to register names, codes of conduct, accreditation, pricing, consumer protection, accountability, stakeholder participation, etc.

• Variety of legal entities: •

Private/public companies, foundations, government or university departments, mutually-owned, etc.

•

ccTLD registries usually have origins in academia

• In general, gTLD registries are for-profit businesses

& ccTLD registries aim to serve their local Internet community


Registrars • “Customers” of the registry •

Registrar usually has a contract with each registry they use

• •

Registry may have accreditation procedures/policies gTLD registries only work with ICANN-accredited registrars

• Registrars are agents for those who buy domain names • •

Typically for-profit businesses Usually sell or bundle other services to those buying domain names: email/web/DNS hosting,VoIP services, Internet connectivity, X.509 certificates, cloud computing, etc.


Registrants • People and organisations who buy domain names • Names usually sold on a first-come, first-served basis •

•

Checks sometimes apply

• • • •

Trademarks and other Intellectual Property Location or nationality Formally registered business Membership of relevant trade body

Depends on registry policy


Conventional DNS Model Registry updates zone

Registry

Zone DB Registrar submits add/modify/delete to registry

Registrar

Registrar

Registrar

End user requests add/modify/delete

Registrants Registrants


Master name server updated Slave name servers updated

IMPLEMENTATION CHOICES This Section gives a brief description of the most commonly used DNS implementations and services


DNS Choices • Open source solutions tend to dominate most DNS setups:

• • •

BIND on Linux or *BSD Obvious support concerns for some

• •

May be misplaced Platforms tend to be rock-solid

BIND included on most UNIX & Linux distributions

• Microsoft name server on Windows • DNS as a commodity service becoming popular Thursday, 7 November 13

BIND

• Berkeley Internet Name Domain • Reference DNS implementation from ISC •

Overwhelmingly dominant: 70-80% of the world’s name servers run BIND

•

Current release is 9.9

•

Hooks for database or LDAP back-ends

• Text-based config file: /etc/named.conf • Loads all zone data into memory from files •

Contributed but unsupported code available for these

• All-new rewrite (BIND10) just released


NSD

• Name Server Daemon

• Developed & maintained by NLnet Labs • http://www.nlnetlabs.nl/projects/nsd/ • Authoritative-only server

• “Compiles” all answers & stores them in wire format • • •

Very fast

•

Awkward at handling huge numbers of zones

Text-based configuration file - /etc/nsd/nsd.conf Used by some TLD registries and DNS providers

• Management/control interface is clunky Thursday, 7 November 13

Knot • Fairly new

• Developed and maintained by CZnic, Czech ccTLD registry • https://www.knot-dns.cz

• Authoritative-only server • •

Similar approach/design to NSD

•

Adding/removing zones, handling lots of zones

Very fast at answering queries

• Clumsy management interface • Some registries considering/evaluating it Thursday, 7 November 13

YADIFA •http://www.yadifa.eu • Yet Another DNS Implementation For All • Authoritative-only server from Eurid, .eu registry • XML-like configuration file, /etc/yadifad.conf • Not widely deployed yet • •


Only been in production for .eu for ~18 months Some registries considering/evaluating it

PowerDNS •https://www.powerdns.com •

•

Authoritative-only server, pdns

• • •

Can use a variety of back-end databases Add/remove/generate zones on-the-fly Good for handling lots of (near-identical) zones

Recursive-only server, pdns-recursor

• Linux preferred as the build environment •

Depends on boost C++ libraries

• Also offers a DNS hosting service Thursday, 7 November 13

Unbound •http://unbound.net • Resolving-only DNS server • Also does DNSSEC (Secure DNS) validation • Developed and maintained by NLnet Labs • •

Text-based configuration file: /etc/unbound/unbound.conf

• Now the default resolving server for FreeBSD systems


Microsoft Name Server • Perhaps only sensible for internal enterprise setups • Point and click GUI is impractical for bulk data • •

Configuration data held in Windows registry Seems to be aimed at departmental/LAN use

• •

Active Directory updated as devices enter/leave network Active Directory built on top of “vanilla” DNS

• Negligible deployment in non-trivial Internet settings • Unproven with large data sets Thursday, 7 November 13

Nominum’s DNS Servers authoritative-only server (ANS) and • Proprietary resolving only server (CNS) designed for huge data sets & carrier class • ANS performance (database back-ends, etc.)

• CNS is very fast control hooks for enterprise features like • Has malware/content filtering likely to be found in networks serving • Products millions of customers and end users: telcos, cable companies, global ISPs, huge corporates, etc.

•http://nominum.com Thursday, 7 November 13

UltraDNS • Sell a DNS service, not software • Proprietary software with a database back-end • Focus is managed DNS service •

Outsourcing, SLAs, reports, statistics, etc.

• Nodes placed at major internet exchanges across the world

•

Massive global anycast architecture

• Serving a number of TLDs: .info, .org, .no • https://www.ultradns.net Thursday, 7 November 13

ATLAS • Proprietary solution from Verisign • Used for the .com and .net zones • Database back-end • Not just for DNS • Designed for handling huge data sets • Always on technology • Authoritative-only server • Not yet serving other TLDs Thursday, 7 November 13

Dyn • DNS as a service • Offers DNS hosting and resolution services using global anycast infrastructure

• Web-based GUI for managing domain name content

• Aimed mainly at small businesses and end users • Geo-location load balancing & CDN options • Also provides secondary DNS service •http://dyn.com Thursday, 7 November 13

OpenDNS • Free global anycast resolver setup • Point stub resolvers at OpenDNS IP addresses • Also provides global anycast DNS hosting service • Not free • Can also do DNS content management: • Parental controls, malware/spam prevention, phishing and botnet defences, etc.

•http://www.opendns.com Thursday, 7 November 13

8.8.8.8 • Free resolver service from google • Resolution with or without DNSSEC validation • Also available over IPv6 • Protects end users from obvious DNS threats: • Cache pollution, domain rewriting, DoS attacks, etc. • Uses a global anycast network • Just point stub resolvers at 8.8.8.8 Thursday, 7 November 13

Anycasting

• Common technique for robust DNS service • Documented in RFC3258 • Clever routing trick • Announce the same route(prefix) out of multiple locations simultanteously

• Clients go to the location that’s topologically closest => shortest RTTs

• Routing protocols automatically fix things

whenever nodes add or leave the anycast cloud

• DDoS attacks get localised Thursday, 7 November 13

QUESTIONS? Thursday, 7 November 13