an introduction to dns the domain name system · 2015-10-05 · dns in action • web browser on...

An Introduction to DNS The Domain Name System

Jim [email protected]

Thursday, 7 November 13

INTRODUCTION

• The DNS in action

• What does it do?

• How is it used?

• Components, roles & responsibilities

• Weaknesses/vulnerabilities


Objectives

• An understanding of how the DNS works

• What happens when a lookup is made

• The key components of DNS and how they interact

• Core concepts & jargon

• Fundamental building blocks

• Zone files and resource records

• Debunk common misconceptions


What is not covered

• How to configure and manage a DNS server

• Choosing DNS solutions

• hardware/software/services/tools/vendors

• DNS debugging and troubleshooting

• How to design a DNS solution for your environment

• ... or deploy it


THE DNS IN ACTION

This Section outlines shows what happens when a DNS lookup is made:

What actors are involved and what they doThe processes that take placeSome 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?


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

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

• What actually happens?


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

User clicks on a link to http://www.norid.no

wallace.rfc1035.com

gromit.rfc1035.com

Web browser on wallace queries 195.54.233.69 - its localname server, gromit.rfc1035.com - for the IP address of www.norid.no


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

A DNS Lookup - 1

User clicks on a link to http://www.norid.no

wallace.rfc1035.com

gromit.rfc1035.com

Web browser on wallace queries 195.54.233.69 - its localname server, gromit.rfc1035.com - for the IP address of www.norid.no


A DNS Lookup - 2

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net


A DNS Lookup - 3

wallace.rfc1035.com

gromit.rfc1035.com

The root server f tells gromit to query the .no name servers

This type of response is known as a referral

f.root-servers.net


A DNS Lookup - 3

wallace.rfc1035.com

gromit.rfc1035.com

The root server f tells gromit to query the .no name servers

This type of response is known as a referral

f.root-servers.netHere’s a list of the .no name servers. Ask one

of them.


A DNS Lookup - 4

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net

x.nic.no


A DNS Lookup - 5

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net

x.nic.no


A DNS Lookup - 5

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net

x.nic.no

Here’s a list of the norid.no name servers.

Ask one of them.


A DNS Lookup - 6

wallace.rfc1035.com

gromit.rfc1035.com

gromit now queries a .norid.no name server, server.nordu.net, for www.norid.no’s address

f.root-servers.net

x.nic.noserver.nordu.net


A DNS Lookup - 6

wallace.rfc1035.com

gromit.rfc1035.com

gromit now queries a .norid.no name server, server.nordu.net, for www.norid.no’s address

f.root-servers.net




A DNS Lookup - 7

wallace.rfc1035.com

gromit.rfc1035.com

server.nordu.net, returns www.norid.no’s IP address to gromit

f.root-servers.net



A DNS Lookup - 7

wallace.rfc1035.com

gromit.rfc1035.com

server.nordu.net, returns www.norid.no’s IP address to gromit

f.root-servers.net


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


A DNS Lookup - 8

wallace.rfc1035.com

gromit.rfc1035.com

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



A DNS Lookup - 8

wallace.rfc1035.com

gromit.rfc1035.com

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


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


After the Lookup - 1• wallace is not much wiser:

• it still knows where to send its DNS queries

• that hasn’t changed

• its web browser was told the IP address(es) for 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


Cacheing - 1

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net



Cacheing - 1

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net


What’s the IP address for cal.norid.no?


Cacheing - 2

wallace.rfc1035.com

gromit.rfc1035.com

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



Cacheing - 2

wallace.rfc1035.com

gromit.rfc1035.com

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


What’s the IP address of cal.norid.no?


Cacheing - 3

wallace.rfc1035.com

gromit.rfc1035.com

server.nordu.net answers the query from gromit

f.root-servers.net



Cacheing - 3

wallace.rfc1035.com

gromit.rfc1035.com

server.nordu.net answers the query from gromit

f.root-servers.net


Here’s the IP address of cal.norid.no


Cacheing - 4

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net



Cacheing - 4

wallace.rfc1035.com

gromit.rfc1035.com

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

f.root-servers.net


Here’s the IP address for cal.norid.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 anyThursday, 7 November 13

Even Further Lessons• There are no connections

• DNS traffic mostly uses UDP, not TCP

• Something makes a query and waits for an answer

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

• 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

• Sometimes gets configured by handThursday, 7 November 13

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

• Usually configured via DHCP

• There are two main types of DNS server:

• Ones which only answer queries

• Known as authoritative servers

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

• Known as resolving name servers

• Make priming queries to root servers at start-upThursday, 7 November 13

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 goalsWeaknesses


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

• Timely, accurate data

• => no centralised database

• No centralised control

• Local info managed & updated locally

• Robustness & Flexibility

• Common, hierarchical name space

• Network of name servers would know how to traverse it


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

• Simplicity was key, sort of

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

• 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

• The name space could be extended arbitrarily

• Delegation of authority could be done anywhere

• No limitations on character sets

• Only limit is the length of a domain name

• Design aimed to prevent single points of failure


Hierarchical Name Space• Obvious choice:

• A tree structure which grows from a root

• Other examples:

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

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

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

• ~200 two-letter ISO-3166 country codes added later

• .no, .us, .se, .fi, etc.Thursday, 7 November 13

The DNS Name Space

tel

jim google

no

root

noridgoogle

com

facebook

wwwmaps wwwwww wwwmaps epp


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.Thursday, 7 November 13

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


DNS CONCEPTS

Key DNS concepts are explained in this Section:

A definition of the Domain Name SystemComponents: hardware/software/protocolThe Name SpaceFundamental principles


What is DNS?• Domain Name System

• It's a protocol & ubiquitous, global lookup service

• DNS is NOT a directory

• Lookups keyed on domain name and type

• Mostly maps names to addresses and vice versa

• 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 DNSThursday, 7 November 13

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


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


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


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

• Zones are assembled from resource records

• Fundamental building blocks

• 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

tel

jim google

no

root

noridgoogle

com

facebook


The DNS Protocol

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

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

• Designed to be simple and fast

• “Atomic” query/response, mostly datagram based

• Specifications controlled by IETF

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


DNS Requests & ResponsesDNS packets consist of:



A Header Section



A Header SectionA Question Section



A Header SectionA Question SectionAn Answer Section




An Authority Section




An Authority SectionAn Additional Section




An Authority SectionAn Additional Section

Answer, Authority and Additional Sections empty in requests (obviously)Answer, Authority and Additional Sections can be empty in responses

Responses include Header and Question Section of the original request


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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+



Query ID (16 bits)



Query ID (16 bits)

Query Response



DNS Opcode

Query ID (16 bits)

Query Response



DNS Opcode

Status bits

Query ID (16 bits)

Query Response



DNS Opcode

Status bits

ResponseCode

Query ID (16 bits)

Query Response



DNS Opcode

Status bits

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

ResponseCode

Query ID (16 bits)

Query Response


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 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Record Type

Record Type



DomainName

Record Type

Record Type



DomainName

Record Type

Record Type

Record Type



DomainName

Record Type

Usually IN(Internet)

Record Type

Record Type



DomainName

Record Type


32-bit Time to live (in seconds)

Record Type

Record Type



DomainName

Record Type



Length of resource record’s

RDATA

Record Type

Record Type



DomainName

Record Type



Length of resource record’s

RDATA

Record Type

Record Type

Resource Record’s RDATA


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

• Full service resolver makes iterative queries to get the answer

• This process is known as resolving

• Also caches answers from the servers it queriedThursday, 7 November 13

Basic Jargon - 3

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

• Might also be a zone

• Every domain includes any descendent nodes (subdomains)

• DNS data is organised into zones

• Typically administered as ASCII text files

• Zones contain resource records


Basic Jargon - 4• Zones and domains

• These are different, though many people confuse them

• Root domain consists of everything in the DNS

• Composed of many subdomains (nodes)

• 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

• A domain is comparable to everything under that directory: ie all files and subdirectories


Basic Jargon - 5• 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


Basic Jargon - 6• 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 RECORDSResource records are the fundamental building blocks of the DNS. The most commonly used ones are explained in this Section

DNS metadataName to address mappingAddress to name mappingAliasingMail deliveryService location


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







TYPE - resource record typeRDATA - data for this owner-name/type tuple


The A Record• Represents an IPv4 address:

• 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.1

• 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 syntaxThursday, 7 November 13

The AAAA Record• Represents an IPv6 address:

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

• Use multiple AAAA records for a multi-homed host:

• example.net. 600 IN AAAA 2001:500:2f::f

• example.net. 600 IN AAAA 2001:500:2f::53

• 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 syntaxThursday, 7 November 13

The MX Record• For mail delivery• norid.no. 3600 IN MX 10 dike-ac.uninett.no.

norid.no. 3600 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

• Use sparingly

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


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


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



_Service - Name of network service



_Service - Name of network service_Proto - Transport protocol (ie UDP or TCP)




Name - Domain name this RR refers to




Name - Domain name this RR refers toPriority - Priority field (0 is highest priority)




Name - Domain name this RR refers toPriority - Priority field (0 is highest priority)Weight - Server Selection (weighting factor)





Port - Port Number





Port - Port NumberTarget - Domain name for server


The SRV Record - 3

_kpasswd._udp.norid.no. IN SRV 0 0 464 kerberos5.norid.no._kpasswd._udp.norid.no. IN SRV 100 0 761 kerberos4.norid.no.

Example:

Find the kpasswd service for norid.no at kerberos5.norid.no and kerberos4.norid.no

Use UDPPrefer 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

• IPv4 addresses in in-addr.arpa domain

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

• Example:• 3.2.1.10.in-addr.arpa. IN PTR host1.example.com.

• IPv6 addresses in ip6.arpa domain

• Hostname for 2001:700:0:4513::130:37 means a lookup for 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.


The SOA Record - 1

• Start Of Authority

• Found at the start (apex) of a new zone

• Fundamental DNS metadata

• Fairly complicated


The SOA Record - 2

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


The SOA Record - 2


MNAME - master server


The SOA Record - 3



The SOA Record - 3


RNAME - admin contact


The SOA Record - 4



The SOA Record - 4


SERIAL - zone version number


The SOA Record - 5



The SOA Record - 5


REFRESH - serial number check

interval


The SOA Record - 6



The SOA Record - 6


RETRY - retry interval for

failed refreshes


The SOA Record - 7



The SOA Record - 7


EXPIRE - zone expiration interval


The SOA Record - 8



The SOA Record - 8


TTL - negative cache interval


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

• Should be correct if using dynamic update

• Some just use a random string (in hostname syntax)

• RNAME - “email address” for zone administrator

• Replace first dot with @ sign:

• 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

• YYYYMMDDVV or seconds since UNIX epoch are common conventions

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

• REFRESH

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

• 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)Thursday, 7 November 13

The NS Record - 1• Fundamental DNS metadata:

• Key to creating a delegation

• Found in both the parent and child zones

• NS record set in both zones should be the same

• 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.

• How can a name server resolve this?

• Simple: the parent adds an A or AAAA record for ns1.example.no.

• This is known as glue or a glue record

• 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 DelegationIn 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 zoneexample.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 .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 zoneexample.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 .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

These shouldmatch!


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 WORKSThis Section outlines how the DNS works and explains:

Master and Slave ServersZone transfers & NOTIFYsEDNS0Dynamic UpdatesSingle Points of FailuresPopular 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


• Clients can tell servers they accept jumbograms

• An EDNS header bit signals DNSSEC readiness:

• DO - DNSSEC OK


Dynamic Update


• 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


Single Points of Failure• Avoid:

• All servers running the same software (DNS & OS)

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

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

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

• Single physical paths for data cables, power, fibre, ducts

• Common system/network admin procedures

• Trade-offs & cost/benefit analyses have to be madeThursday, 7 November 13

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


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 bytesWRONG!


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.

• Their DNS lookups will time out or fail

• May cause operational problems elsewhere

• 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”

•VERY WRONG!

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

• Send email, visit web site, etc.

• Their DNS lookups will time out or fail

• May cause operational problems elsewhere

• 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

WRONG!


NAMING

The protocol standards for names are explained in this section:

Differences between domain names and hostnamesHow 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 & -

• 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...

• How to deal with non US-ASCII characters?

• Awkward for many European languages/scripts

• Far bigger problem for scripts like Chinese, Arabic, etc.

• Solution: Internationalised Domain Names

• Horrifically complicated because languages are even more complicated

• Social, cultural and sovereignty issues

• Defined in a raft of RFCs 5890-5895Thursday, 7 November 13

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


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 packetsCache poisioningThe problems DNSSEC solves and does not solve


Remember this?

wallace.rfc1035.com

gromit.rfc1035.com

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



• 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

What’s Wrong With That?


So where are the vulnerabilities?

wallace.rfc1035.com

gromit.rfc1035.com f.root-servers.net




wallace.rfc1035.com



Here!



wallace.rfc1035.com



Here!

Here!



wallace.rfc1035.com



Here!Here!

Here!



wallace.rfc1035.com



Here!

Here!

Here!

Here!



wallace.rfc1035.com



Here!

Here!

Here!

Here!

Here!Here!

Here!Here!


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

• Inject bogus data into caches

• Cache poisoning attacks


Attacking the DNS - 2• Take control of the name server(s) for some zone

• Make it answer with false data

• Compromise the registry

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

• Several prominent examples recently:

• 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)


• A regular DNS client really can’t be sure of anything:

• Did a lookup for www.norid.no really get answered by the norid.no name servers?

• Did it get what a real norid.no name server actually sent?

• Is the name server that answered telling the truth, the whole truth and nothing but the truth?

What Does This Mean?


• Did the DNS provide the actual address of Norid's web/mail/whatever server?

• Is my web browser talking to the One True norid.no web site?

• Can I be sure my email is going to the norid.no mail server?

• Feel free to replace norid.no with your favourite domain name….

• amazon.no, ebay.com, google.no

OK, What Does This Really Mean?


Don’t Panic!

• DNS is only now emerging as a target for attackers

• Plenty of easier victims elsewhere

• DNS problems have been known about for a long time

• IETF started working on this in the late 1990s

• The solution is now being deployed, Secure DNS

• Sometimes called DNSSEC: DNS Security Extensions


• Data integrity

• Verify what was received was exactly what the name server sent

• Non-repudiation

• Authenticate who/what signed the data

• Name server authenticity (in theory anyway)

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

• Should be a chain of trust to the root

What Secure DNS Proves


• Prevent/thwart denial-of-service attacks

• Stop name server compromises

• Buffer overflows

• Environment variable leakages

• Provide confidentiality of DNS data

• The DNS is public after all...

What DNSSEC Can’t Do


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


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 :-)


DNS ADMINISTRATION

The basics of DNS administration are described in this Section:

How to set up a simple zone fileConfiguring a DNS server to be master or slaveUseful DNS tools


A Simple Zone Fileexample.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. IN NS ns0.example.com.example.com. IN NS ns1.example.com.

ns0.example.com. IN A 10.9.8.7ns1.example.com. IN A 10.1.2.3example.com. IN A 172.16.1.1mail.example.com. IN A 172.16.1.1

example.com. IN MX 10 mail.example.com.www.example.com. IN CNAME example.com.


Outline Master Server Setup

zone "rfc1035.com" { type master; file "/var/named/masters/rfc1035.com";};

A BIND name server’s config file would contain something like this:

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


Outline Slave Server Setup

zone "rfc1035.com" { type slave; file "/var/named/slaves/rfc1035.com"; masters { 10.9.8.7; };};

A BIND name server’s config file would contain something like this:

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


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) developmentGovernance/oversightTop-level domainsConventional DNS business model & roles


IETF• Internet Engineering Task Force

• Develops & maintains most Internet protocol standards

• Publishes standards documents (RFCs)

• Based on “Rough consensus and running code” - allegedly

• Organised into Working Groups

• Most work done on mailing lists

• IETF meets 3 time a year

• Effectively just one WG for DNS now

• dnsop - DNS operationsThursday, 7 November 13

ICANN

• Internet Corporation for Assigned Names & Numbers

• US non-profit company

• https://www.icann.org

• Multi-stakeholder governance and policy-making, mostly on domain names

• Well over 200 full-time staff

• 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

• Usual model

• ICANN has a contract with a registry

• 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 elsewhereThursday, 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 modelThursday, 7 November 13

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!

• Maintains a register (database) of domain names

• Publishes these in DNS and whois

• Operates DNS and whois servers for the public

• Provides some way for names to be registered

• Usually done via EPP, Extensible Provisioning Protocol

• 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


Registry Zone DB

RegistrantsRegistrants

End user requests add/modify/delete

Registrar submits add/modify/delete to registry

Registrar RegistrarRegistrar

Mastername server

updated

Registry updateszone

Slavename servers

updated

Conventional DNS Model


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 popularThursday, 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

• Text-based config file: /etc/named.conf

• Loads all zone data into memory from files

• Hooks for database or LDAP back-ends

• Contributed but unsupported code available for these

• All-new rewrite (BIND10) just releasedThursday, 7 November 13

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

• Text-based configuration file - /etc/nsd/nsd.conf

• Used by some TLD registries and DNS providers

• Management/control interface is clunky

• Awkward at handling huge numbers of zonesThursday, 7 November 13

Knot• Fairly new

• Developed and maintained by CZnic, Czech ccTLD registry

• https://www.knot-dns.cz


• Similar approach/design to NSD

• Very fast at answering queries

• Clumsy management interface

• Adding/removing zones, handling lots of zones

• Some registries considering/evaluating itThursday, 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


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 setsThursday, 7 November 13

Nominum’s DNS Servers• Proprietary authoritative-only server (ANS) and

resolving only server (CNS)

• ANS designed for huge data sets & carrier class performance (database back-ends, etc.)

• CNS is very fast

• Has control hooks for enterprise features like malware/content filtering

• Products likely to be found in networks serving millions of customers and end users: telcos, cable companies, global ISPs, huge corporates, etc.

•http://nominum.comThursday, 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.netThursday, 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


• Not yet serving other TLDsThursday, 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.comThursday, 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


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


Anycasting• Common technique for robust DNS service


• 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 localisedThursday, 7 November 13

QUESTIONS?


an introduction to dns the domain name system · 2015-10-05 · dns in action • web browser on...

Documents