Presentation is loading. Please wait.

Presentation is loading. Please wait.

THE DOMAIN NAME SYSTEM. A DEEP DIVE. David Groves, August 2014.

Similar presentations

Presentation on theme: "THE DOMAIN NAME SYSTEM. A DEEP DIVE. David Groves, August 2014."— Presentation transcript:

1 THE DOMAIN NAME SYSTEM. A DEEP DIVE. David Groves, August 2014.

2 Preparation.  Intro and problem reporting.  Install Dig (if you don’t already have it).  Install Firefox.  And the “DNSSEC Validator” Addon.

3 Problem Reporting.  Please report  Errors.  Omissions.  Anything Unclear.  Any real life examples that don’t work anymore.  Reports to

4 Dig ONLY !  When debugging DNS, always use dig.  Don’t use nslookup. Don’t use nslookup  Don’t use host.  Just use dig (drill is acceptable too – but I talk about dig).  Windows: Install guide on next slide.  Mac OSX: Preinstalled since 10.7.  Linux: In “dnsutils” package on Debian/Ubuntu.

5 Installing Dig on Windows.  Get the bind distribution from  Unzip it somewhere (I like c:\bind\).  Add it to your path (next slide).

6 Adding bind to your path.  Press Windows + Break.  Select “Advanced System Settings” on the left.  Select “Environment Variables” at the bottom.  Select “Path” from the bottom set of variables.  Add “;c:\bind” to the far right of the path.

7 Introduction.

8 What is DNS anyway ?  Wikipedia says :-  The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most prominently, it translates easily memorized domain names to the numerical IP addresses needed for the purpose of locating computer services and devices worldwide. The Domain Name System is an essential component of the functionality of the Internet.

9 History: DNS is Old.  1983: Paul Mockapetris invents DNS at the UC Irvine.  1984: Students at UC Berkeley create the first version of BIND, still the most common DNS software.  1987: RFC1034 and RFC1035 codify DNS in a way you would recognise today.RFC1034RFC1035

10 Aside: Host Files.  Before DNS, a single “hosts” file was copied around the internet.  It contained the name of everything on the internet.  That made sense in 1983.  Modern computers check if a name is in it before using DNS.  Windows: %WINDIR%\system32\drivers\etc\hosts  OSX/Unix: /etc/hosts.  Host files are generally useful for debugging/development/hacks.

11 System and Protocol.  DNS is both the system …  Domain Name System.  And the protocol when using the system.  The DNS protocol.  Working out where to start is hard.  So lets start with the protocol.

12 The DNS Protocol.

13 Protocol Fundamentals.  OSI Layer 5 to 7 protocol.  Can use EITHER UDP:53 or TCP:53.  > 99.9% of DNS traffic is UDP.  But please don’t firewall TCP, it does matter !  Layer3 protocol independent.  It works exactly the same over IPv4 and IPv6.  IPv4 DNS transport can carry IPv6 details (and vice versa)

14 Packet Format.  Decoded (near) perfectly by Wireshark.  Which is good, as it isn’t readable by humans.  Documented in many RFC’s.  See for a list of DNS related RFC’s.  Most important are RFC1034, RFC1035, RFC2308, RFC6891.RFC1034RFC1035RFC2308 RFC6891

15 Packet Format.

16 Request / Response.  DNS is mostly a Request / Response protocol.  Questions are sent in Requests.  Answers are sent in Responses.  In English, questions might be :-  What is the IPv4 address of  How do I send mail to  What is the name of ?

17 Question Format  Question Name  The DNS name being looked for.  Question Type  What data is wanted (more later).  Question Class  Almost exclusively “IN”, or Internet Class.

18 Answer Format  Answer Name / Answer Type / Answer Class are just like question.  TTL: How long you can store this answer before asking again.  Response Length and the Response.  The response may have internal structure based on the Type.

19 Compression.  In Names only.  Is a pointer to a previous name (by position in the packet).  Avoids repeating names in DNS packets.

20 TCP vs UDP.  >99.9% of DNS traffic is UDP.  TCP is used in two main scenarios.  For unusually large DNS packets.  For DNS servers synchronising state between each other (more later).

21 Large Packets ?  DNS Protocol Oddity.  With EDNS0 (RFC2671), DNS is one of the few sources of legitimate fragments on the internet.RFC2671  Only really applies to answers > MTU.  Fragments are generally only seen in conjunction with DNSSEC (see later).

22 Fragments ?

23 Large Packets ?  Remember: DNS packet header says how many questions and answers are in the packet.  So incomplete packets can be detected.  If the packet is incomplete, the DNS software will try again using TCP.

24 Common Packet Problems.  RFC1035 defined limits on UDP DNS packet size. RFC1035  UDP messages: 512 bytes or less.  RFC6891 extends this and allows fragments. RFC6891  Lots of implementations ignore this.  Cisco ASA ( 512bytes.  Checkpoint default blocks fragments.  Palo Alto PANOS (< 5.10) default blocks fragments.  People frequently think DNS is UDP only and engineer accordingly.

25 Stub Resolvers.  What do clients do ?

26 Three Types of DNS software.  Stub resolvers.  Embedded into modern operating systems.  Know how to talk to recursive servers.  Recursive servers.  Can answer any question asked of them by talking to authoritative servers.  Authoritative Servers.  Have the answer for particular domain names.


28 Stub Resolvers.  Stub Resolvers are limited DNS software stacks.  They ship with all modern operating systems.  They talk to a limited list of configured list of recursive servers.  They use those recursive servers to resolve all names.  Some cache answers they learn.

29 How stub resolvers learn recursive servers.  Static Configuration / Windows.  In Adaptor Settings Control Panel.  Set per adaptor.

30 How stub resolvers learn recursive servers.  Static Configuration / Unix.  In /etc/resolv.conf

31 Dynamic Learning of Nameservers (IPv4).  Learned via DHCPv4.  RFC2132. Option Code 6 specifies a list of IPv4 addresses that are DNS servers. RFC2132  DANGER: Option 5 is “Name Servers”. These are NOT DNS servers, they are for a prehistoric protocol.  RFC3397. Can also provide Code119. A list of domain search paths. RFC3397

32 Dynamic Learning of Nameservers (IPv6).  DHCPv6.  RFC3646. List of IPv6 nameservers similar to DHCPv4. RFC3646  Also supports defining a set of domains as a search path.  Can use stateful or stateless DHCP to learn DNS data.  *NEW*: SLAAC Learned DNS.  RFC6106. RFC6106 RDNSS (Recursive DNS server) option. DNSSL (DNS Search List) option. Included in the Router Advertisement packets.

33 What Search Paths Do.  Let you abbreviate names.  For example, with /etc/resolv.conf containing  search  If you try and resolve www then you try these names in order.     www.

34 Tips with the Windows Stub Resolver.  View the cache.  Delete the cache.

35 Tips with the Linux Stub Resolver.  Does not cache by default.  Sometimes small daemons are run which do.  Common daemons that do this include  nscd  dnsmasq

36 Recursive Lookups.  What do recursive DNS servers do ?  What questions are they asked ?  How do they find the answers ?

37 But First: Security.  You MUST NOT just let anyone use your recursive server.  Until a few years ago, this wasn’t such a big deal.  Only let people you trust, or can at least identify use your server.  Otherwise you open yourself to :-  Bad guys using your server to amplify DDoS attacks (more later)

38 What recursive servers know.  Only hardcoded data is the root hints file.  Can download a current copy from ; last update: June 2, 2014 ; related version of root zone: 2014060201 ; ; formerly NS.INTERNIC.NET ;. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30 ; ; FORMERLY NS1.ISI.EDU ;. 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::B ; ; FORMERLY C.PSI.NET ;. 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::C ; ; OPERATED BY RIPE NCC ;. 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7FD::1 ; ; OPERATED BY ICANN ;. 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42 ; ; OPERATED BY WIDE ;. 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A M.ROOT-SERVERS.NET. 3600000 AAAA 2001:DC3::35 ; End of File

39 So what DO the root servers know ?  The know the authoritative namesevers for com, org, uk, de and so on.  You can download all the DNS data they know from

40 DNS: Like turtles all the way down.

41 Resolving a real name manually.  Do this yourselves.  > dig @

42 Resolving a real name manually.  You asked about a root server the IPv4 address of  It said: I don’t know, but these guys know, go ask them  It also said: Have a hint, these are the IP addresses of those guys.

43 Resolving a real name manually  Pick one of the servers. Use dig to ask it about  I don’t know, but these guys know, go ask them  Have a hint, these are the IP addresses of those guys.

44 Resolving a real name manually  Pick one of the servers. Use dig to ask it about  Heh, I know the answer to that !.  has these IPv4 addresses

45 Beyond Name -> IPv4 Address.  DNS stores more than just IPv4 Addresses.  Common DNS Record Types.  Reverse DNS.

46 DNS Record Types.  DNS can store many types of data other than just IPv4 addresses.  DNS calls IPv4 records attached to a name “A” records, for address.  You have already seen two other types of records !  What are they ?

47 Common Record Types. Record TypeWhat it stores. AAn IPv4 address. AAAAAn IPv6 address. NSThe name of a server responsible for this domain name. MXA list of names of servers to send SMTP mail to for this domain. CNAMEAn “Alias” record. An indication this isn’t the Canonical Name and you should look at another name for the data you seek. TXTA string of ASCII text. PTRUsed for address to name resolution (reverse DNS – more later). SOAUsed to carry data about a zone itself (covered later in Authoritative sever operations). Full list at

48 The A Record.  Most commonly looked up DNS type.  Is just an IPv4 address.

49 The AAAA Record.  4 times bigger than an A record.  This is why it is an AAAA or “Quad A” record.  Is just an IPv6 address.

50 The NS Record.  Tells you what the names of the DNS servers which are authoritative for a particular DNS zone.  You still need to turn that name into an IP address to talk to it.  Sometimes you will also get required hints or glue.  My own domain is an example. The nameservers for it are and


52 The MX Record.  More than just a name.  The MX record has a priority field.  REMEMBER: Some DNS types have internal structure.  Used to find the SMTP servers to deliver mail to.  If you are a program trying to send mail to, you need the MX records for

53 The MX Record.  5 MX records.  Each with a priority field (10, 20, 30 …).  Mail senders start at the LOWEST priority server.  If sending mail to it fails, they try the next, and so on.

54 Direct to A record mail delivery.  Domains that expect mail SHOULD have MX records.  However, if the domain has no MX records at all, then :-  RFC5321 says :- RFC5321  Lookup the A and AAAA record of the domain name.  Attempt SMTP connections to those addresses.

55 The CNAME Record.  Says another name is the canonical name for the name with the CNAME record.  Example :- ;; ANSWER SECTION: 300 IN CNAME  is really

56 The CNAME Record.  Nothing ever ASKS for a CNAME record  Except debugging obviously.  Things follow CNAME’s when asking for other record types.  This means CNAME’s don’t play well when sharing a name with other record types.

57 CNAME Rules  RFC1034 says :- RFC1034  Domain names which point at another name should always point at the primary name and not the alias.  Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.

58 CNAME Chains.  RFC advises against CNAME chains.  But CNAME chains are often useful.  An example is sites that use Akamai CDN.  Try “ dig ”.

59 CNAME Chains. ;; ANSWER SECTION: 86400 IN CNAME 21600 IN CNAME 20 IN A 20 IN A

60 CNAME: Does not play well with others.  RFC1034 says :-  If a CNAME is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

61 CNAME as Gateway to CDN’s.  CNAME’s are used to direct users to CDN’s.  Sky operate DNS for  But Sky want Akamai to direct users for  If CNAME’s don’t play well with other record types.  They cannot be at the “Apex” of a zone.  Because the Apex of a zone MUST also have NS records and SOA records (more later on SOA).


63 Zone Apex.  That worked !  The URI changed to  Look at the DNS for ;; ANSWER SECTION: 86400 IN A  What really happened ?

64 Zone Apex.  Nothing to do with DNS. No rules broken.  The webserver at did an HTTP level redirect. Remote Address: Request URL: Response Code: 302 Found. Location:

65 CNAME: Rule breaking.  Some people do break the rules though.  Amazon Route53: AliasesAliases  Cloudflare: Zone FlatteningZone Flattening  Unused Internet Drafts: Sury + cz.nicSury + cz.nic  No DNS only solution, either standards based or defacto.

66 TXT Records  Just contain ASCII text.  Can be used as a very limited, very cacheable, data distribution method.  Try “ dig TXT ”.

67 PTR Records.  So far, we have all been about name -> data.  This is about data (IPv4 or IPv6 addresses) to names.  Hence the term “reverse DNS”.

68 Using dig to get reverse DNS.  Dig uses the –x flag to give it addresses.  Try :-  dig –x or  dig –x 2001:4db0:10:7:20c:29ff:fe6a:a65f

69 What are these giant names ?  The IPv4 one was a bit odd. ;; ANSWER SECTION: 300 IN PTR  The IPv6 one was a monster. ;; ANSWER SECTION: 300 IN PTR  Any why are these backwards ?

70 The domains they are in.  The top of the IPv4 address space reverse tree starts at “”.  The top of the IPv6 address space reverse tree starts at “”.

71 Why backwards ?  IP addressing and DNS are both hierarchical.  DNS has most significant part on the right.  (com is more significant than google).  IP addressing has the most significant part on the left.  (1 is more significant than 2).  So DNS reverses the order to match IP addressing.  You want a server that knows about addresses STARTING with 1, not ENDING with 1.


73 Why does reverse DNS matter.  Mostly for human benefit.  People prefer names to numbers.  Some systems care, mostly mail.  Some systems display the name, like IRC.  You could put any name in reverse DNS you control, you need a matching forward (A or AAAA) if you want these kind of systems to believe you.

74 Delegating More Specific Reverses.  Could only delegate on /8, /16 or /24 in IPv4.  Can only delegate every 4 bits in IPv6.  RFC2317 has options for IPv4. RFC2317  Similar methods can be used with IPv6.

75 Authoritative Servers.  How to run a domain name.

76 Minimum Requirements for a Domain.  Delegation.  Your parent domain must have NS records for you.  Those NS records must resolve to the IPv4 and/or IPv6 addresses of your name servers.  If the name of the NS is in your domain, the parent must provide Glue in addition to NS records. Glue is non-authoritative A / AAAA records for your name servers. Your nameservers must have matching data (which is authoritative).

77 Server  You must software that speaks the DNS protocol.  It must listen on UDP:53 and TCP:53 on the addresses of the NS servers.  If you have multiple DNS servers, they must all have the same zone data.

78 Minimum Data in Zones.  What your server needs to answer.  MUST: Have an SOA record for the zone (see next slide).  MUST: Have NS records matching your parent.  MUST: Have A/AAAA matching glue if you are using it.  OPTIONAL: MX records (if you want mail).

79 SOA and DNS Replication  SOA records have two main purposes.  To aid in syncing multiple nameservers for the same domain.  To provide negative TTL data (more later).  Two types of name server.  Master: Edit zone data here (old name: Primary).  Slave: Syncs from master server (old name: Secondary).

80 SOA Records  Somewhat magical voodoo.  Lots of numbers.  ;; ANSWER SECTION:  86400 IN SOA 2014021800 7200 1800 1209600 300

81 SOA Records

82 SOA Records – Zone Serial  32bit number.  Higher is more recent.  Slaves can “phone home” to see if they need to update.  Commonly written in YYYYMMDDxx format, but this isn’t a requirement.  Never used by normal DNS clients.

83 SOA Records – Refresh Time.  Frequency slaves fetch SOA from masters.  Slaves do this to get serial.  Compare serial with local copy to see if they have the most recent zone or not.  If they don’t, they will initiate a zone transfer (see later).  Notifies mean this should only be for assurance purposes (see later).

84 SOA Records – Retry Time.  If zone transfers fail, slaves wait this long before trying again.

85 SOA Records – Expiry Time.  If a slave has no contact with a master for this time, stop answering queries for this zone.  Contact is an SOA check or a successful zone transfer.

86 SOA Records – Negative TTL.  Individual records have individual TTL’s.  This is the TTL of “Non Existent Record”.  For example :-  You lookup  You get NXDOMAIN error (this name doesn’t exist).  You can cache that non-existance for 300 seconds.


88 Zone Transfers.  Only used between masters/slaves.  Allowing from anywhere else can be an information leak (people can get entire zone data).  Can be secured by configuring allowed addresses.  Can be secured with TSIG (see security section).  Question type for a zone transfer is “AXFR”.  RFC5936: Zone transfers are always TCP. RFC5936

89 Incremental Zone Transfers.  Defined in RFC1995. Type “IXFR”.RFC1995  Allows slave to ask for differences between two serial numbers.  Designed to reduce sync traffic.  Only really useful for very large zones.  Masters need to keep additional state (changelog).

90 Notify.  Defined in RFC1996.RFC1996  Sent by master to slaves when the zone has changed.  Slaves will then initiate zone transfers or incremental zone transfers.

91 Problems with Zone Transfers.  Uses the DNS protocol to sync data.  Comments would be lost.  Programmatic generated names would be expanded before transferring.  Therefore other methods are sometimes used.  Rsync for flat text zonefiles.  Database backed DNS.

92 DNS for Load Balancing.  Anycast.  Round Robin.  Geographic Responses.  Edns-client-subnet.

93 Anycast  IP Anycast has multiple uses.  DNS is the classic use case.  All links have equal metrics.  Client1 will use top server.  Client3 will use the bottom server.  Client2 may be ECMP’d across both.

94 Anycast: Recursive Servers.  ISP’s or Large Organisations.  All clients get same DNS server addresses worldwide.  Use Anycast for Recursive servers.  Local user talk to local servers.  Lower latency improves customer experience.  Google is anycasted.

95 Anycast: Authoritative Servers.  Many authoritative are anycasted.  Examples are  Most of the root zone servers. RIPE’s locations @ Miami, Reykjavik, London (LINX), Helsinki, Poznan (Poland), Budapest, Athens, Novosibirsk (Russia), Delhi, Tokyo and Brisbane. ,.org servers.

96 Round Robin.  Earlier we say multiple responses for  Clients connect to the first result.  DNS servers should give out answers in a rotating or random order.  Achieves crude load balancing.

97 Round Robin  Need mechanism to dynamically remove responses if servers cannot serve content.  Either server is down / unreachable.  Or server is overloaded.  TTL’s need to be low.  RFC6555 : Happy Eyeballs makes Round Robin better. RFC6555  RFC6555 clients WILL try and connect to all returned results.  Still want to remove down servers to improve performance.

98 Geographic Response.  No rule says you need to give the same response to everyone.  Can use source IP address of inbound DNS packet as a factor.  This IS NOT the end users address, just the address of the recursive DNS server they are using.  Akamai do this.

99 Geographic Response – Demo. UK Based Host Using Google Public DNS UK Based DSL Host on Sky Broadband US (Texas) Based Host Using Google Public DNS

100 DNS-Client-Subnet.  Internet Draft. Internet Draft  Authors from Google, Verisign and Neustar.  Expired, but has widestream real world support.  Adds data to DNS requests to identify end user IP address.  Has minor privacy concerns  Minor: Because you generally connect to the things you lookup DNS for, so the operator would learn your IP address anyway.

101 DNS-Client-Subnet.  Uses new EDNS0 OPT Header.  Recursive server gets question from end client.  Adds header, including source IP address from client.  Rounded to a configurable netmask.  If request comes from and server has mask 24 configured, will add to EDNS0-CS header.  When request gets to authoritative server, it knows the (approximate) client IP address.

102 DNS-Client-Subnet: Caching.  Introduces new caching requirements.  Caching servers that use EDNS-CS.  When adding to the cache, add the prefix too.  Only give the cached answer to clients from the same prefix.

103 DNS Security.  Basics.  Source Port Randomisation.  Amplification Attacks.  Dynamic DNS + TSIG.  DNSSEC.

104 DNS Security Basics: Recap.  Remember the packet basics.  Don’t over firewall.  DNS uses TCP and UDP.  DNS has legitimate use for fragments.  Limit who can use recursive servers.  Remember: The entire internet needs to use authoritative servers.  Zone Transfers.  Only allow trusted sources to perform zone transfers.

105 Source Port Randomisation.

106 What the attacker needs to guess.  When a real question got sent.  Timing window: Must beat real answer.  What the source port of the question was.  16 bit value, so 1/65536 if just a random guess.  What the DNSID was (in the packet).  16 bit value, so 1/65536 if just a random guess.

107 If they are trying to guess.  Attacker only needs 1 packet to be correct.  Can send MANY packets.  To get BOTH guesses correct is  (1/65,536) * (1/65,536) = (1/4,294,967,296).  Modern implementations randomise source ports.  Be careful your firewall doesn’t “unrandomise” them.

108 Amplification Attacks

109 Amplification Attacks (ANY).  These attacks often use ANY requests.  ANY isn’t a record type, but a special request.  It asks for all record types associated with a name.  Mostly used for debugging purposes.  Can be very large for “fully featured” domains.  Try: dig ANY  Check message response size.

110 Defenses.  BCP38 stops your users launching these attacks. BCP38  Rate limiting ANY responses helps you not be an amplifier in these attacks. (see Paul Vixie’s Tech Note).Paul Vixie’s Tech Note  Little you can do as a victim.  Just normal defences from volumetric DDoS.  These techniques just make the volumes easier to generate.

111 Dynamic DNS.  DANGER: dyndns doesn’t (normally) do Dynamic DNS.  Methods of updating DNS.  Traditional: Update text configuration files on master servers.  Database: Some DNS software can use databases.  Dynamic.  RFC2136: Extensions to the DNS protocol to allow zone data to be changed. RFC2136  RFC2845: TSIG Extensions to provide cryptographic based authentication while doing so. RFC2845

112 Dynamic DNS Operations.  UPDATE messages contain.  Name: What name is this update associated with (eg:  Prerequisite: Only perform this operation if :- A set of records already exist. And a different set of records do no exist.  Update: Updates can ADD and DELETE. If you want to modify. DELETE then RE ADD.

113 Doing Dynamic Updates.  BIND has the “nsupdate” command.  Most programming languages have a library.  Perl: Net::DNS::UpdateNet::DNS::Update  Python: dnspythondnspython  C: ldnsldns  Cisco IOS Cisco IOS

114 Securing Dynamic Updates.  Clients normally want to update when they get a new IP address.  Windows: Automatically does DDNS with AD when getting a DHCP lease on a corporate network.  OSX/Linux: Can be configured to do DDNS.  How do you know the client is who it says it is when it sends an UPDATE message ?.  Client and Server both have a shared secret key.

115 Securing Dynamic Updates.  Client forms UPDATE message and adds signature.  Using a hash function on the message and the secret key.  RFC2845: Defines HMAC-MD5 as the hash function. RFC2845 No longer particularly secure.  RFC4635: Adds new, more secure methods. RFC4635 REQUIRED: HMAC-SHA1, HMAC-SHA256 OPTIONAL: GSS-TSIG, HMAC-SHA224, HMAC-SHA384, HMAC- SHA512.  Server repeats and checks signatures match.

116 TSIG and Zone Transfers.  Zone Transfers.  RFC5936: Allows signing of AXFR requests. RFC5936  Can sign response also. Allows for verification of uncorrupted and untampered response. TCP should ensure not corrupted, but not untampered.

117 DNSSEC (DNS Security Extensions).  Stopping people lying to you.  Overview only.  If you want the crypto maths, sorry !

118 Timelines.  First RFC on DNSSEC in 1995 – but they are full of holes.  2005: Actually usable RFC’s (4033, 4034, 4035) are published.403340344035  2010: The Root Zone is first signed.

119 People can lie to you.  Lying DNS servers are very common.  Captive Portals (sign in to free wifi !).  Internet Censorship.  Some transparent caches.  BAD GUYS !  You might not mind some of the others, but you really don’t like the bad guys.

120 Detecting when people are lying to you.  DNSSEC lets you spot liars.  Relies on chain of trust.  Chain starts at the root.

121 DNSSEC in Stub Resolvers.  Windows: See here. Windows Server 2012 only.See here  OSX/Linux: Run nscd, unbound or bind locally.  Set /etc/resolv.conf to use ::1 as server.  DNSSEC still useful even if you cannot put it in stub resolver.  As long as you trust the network between you and your recursive resolver.

122 Cryptographic Operations.  Two types of keys.  Key Signing Keys: Used to verify Zone Signing Keys. Root KSK is valid for 5 years. This means the trust anchor only changes every 5 years.  Zone Signing Keys: Used to sign the records in zones. Root ZSK is valid for 90 days. Rolls over to prevent brute force attacks.

123 Following the Chain of Trust.  Remember: This ?  Remember: Recursive nameservers needed a root hints file.  DNSSEC enabled recursive servers also need the root trust-anchor.

124 The Root Trust Anchor.  Can be downloaded from IANAIANA  Getting a trusted copy without using DNS is of course tricky.  Generated in a complex ceremony (more later).

125 Following the Chain Of Trust  DNSSEC trust isn’t that different from normal DNS.  You follow NS records to get to an authoritative server.  At the same time, you follow cryptographic signatures to ensure you haven’t been lied to.

126 The Three Main DNSSEC Keys.  Three main record types.  DS (Delegation Signer): Published in parent zone. Used to verify DNSKEY in the actual zone.  DNSKEY: Key used to verify RRSIG’s of names in the current zone. For the root, verify the DNSKEY with the Root Trust Anchor.  RRSIG: Attached to individual names. Used to verify the responses.

127 Full DNSSEC lookup validation.  Graph generated by  Shows chain of trust resolving


129 Asking dig to do full DNSSEC trace.  Get a copy of the root keys from the root nameservers.  $ dig. DNSKEY | grep -Ev '^($|;)' > root.keys  Verify root KSK against IANA published anchor with :-  $ dig. DNSKEY +noall +answer | dnssec-dsfromkey -2 -f -.  Verify from the name back to the root.  $ dig +sigchase +trusted-key=./root.keys A | cat –n  Verify from the root down to the name.  $ dig +sigchase +topdown +trusted-key=./root.keys A | cat -n

130 Proof of Non Existence.  Prove servers aren’t lying when they say a name does not exist.  Performed by NSEC, NSEC3 or NSEC5 records.  In authority section of NXDOMAIN errors.  NSEC: Trivial to enumerate an entire domain.  NSEC3: Known attacks can enumerate domains.Known attacks  NSEC5: No known attacks at present time.

131 Key Rollover Operations.  Need to generate new ZSK and RRSIG’s every X days (configurable, most people use 90days).  This cannot fail or validation will fail.  Failing validation is worse than no validation.  KSK’s need rollovers too, but on longer timescales.

132 Generating the Trust Anchor.

133 International Languages in DNS.  History.  Current Practice.

134 History  When DNS was invented, the entire internet used English.  In 2010, it was 

135 International Domain Names  Use Firefox.  Since this link works :-  http:// 中国互联网络信息中心. 中国 / http:// 中国互联网络信息中心. 中国 /  You know IDN (International Domain Names) must be a thing.  This site is the Chinese Internet Network Information Centre.

136 International Domain Names  But DNS only does ASCII. What is going on ?  RFC3492 & RFC5891: Defines punycode. RFC3492RFC5891  A way to map Unicode into ASCII.  Not particularly space efficient.  For example, http:// 中国互联网络信息中心. 中国 / is http://xn--fiqa61au8b7zsevnm8ak20mc4a87e.xn--fiqs8s/http:// 中国互联网络信息中心. 中国 /

137 SECURITY  Bad Guys abuse this.  Homographs.  Characters from different languages that look the same.  Wikipedia has the e and a replaced with Cyrillic characters that look the same.  Browsers have some line of defence.  Non-Browser apps (eg: email) are still vulnerable.

138 SECURITY: Browser Risk Mitigations.  Internet Explorer 7+  Only display IDN in URI bar if all characters are from the same language. Otherwise display Punycode.  Firefox 2+ / Opera 9.10+  Only display IDN for per-TLD (Top Level Domain) on a whitelist.  TLD’s must have a policy against homograph spoofing.  Google Chrome  Only displays IDN if ALL characters belong to a single one of the users preferred languages.

139 Other Use of DNS  Widely Deployed.  SPF: Anti spam.  Future Looking.  ENUM: Phone numbers to IP addresses.  SRV Records: Service Discovery.  DANE/SSHFP: Security data in DNS.

140 TXT for SPF Records.  SPF (Sender Policy Framework). Used to reduce mail forgery and spam.  Became its own record type in RFC4408.RFC4408  Went back to just TXT for SPF in RFC7208.RFC7208  Records look like :-  TXT "v=spf1 ip4: ip6:2001:41d0:1:e23f::1 -all"  Lists permitted senders for that domain.

141 TXT for SPF Records.  As well as IPv4 and IPv6 addresses.  Lookup the TXT record for Replace this include statement with that result.  SPF can be strict or loose.  Most policies end in “-all” or “~all”.  - is hard fail. In this context, it matches everything and says fail.  ~ is a soft fail. Anti-spam can use it as a hint, but it alone wont result in mail failure.

142 ENUM: Phone Number Mappings.  Backwards tree, like reverse DNS.  Example name.  +44 113 496000 would be   Contains NAPTR records.  Used to refer to SIP or other delivery methods.  See RFC2916 or Wikipedia for more details.RFC2916Wikipedia

143 SRV: Service Discovery.  Answers “what IP addresses provide X service at this domain” question.  Support load balancing and server failover.  Records look like  7200 IN SRV 10 0 443  The autodiscover TCP service can be found on port 443 of

144 SRV: Service Discovery.  Priority: Connect to lowest numbered servers first.  Weight: If multiple equal priorities, select randomly, weighted by the numbers here.  Port: The TCP or UDP port the service runs on (or 0 if using a portless protocol).

145 SRV for HTTP  Would be wonderful if SRV for HTTP/HTTPS was widely supported.  Would make load balancing websites much easier.  Would solve the CNAME at Zone Apex problem.  Very unlikely to happen.

146 SRV for HTTP  Chicken and Egg problem.  Browsers would have to try SRV record.  Early days, mostly would get NXDOMAIN.  Then they would try A/AAAA like they do now.  No browser makers want to add this extra latency. Chrome: Mozilla:  HTTP2.0 may help by mandating this.

147 DANE: Publish Security Data in DNS.  Assuming you have and trust DNSSEC.  You can use DNS to publish security information.  RFC6698: Allows x.509 (ie. SSL) certificate verification data to be stored in DNS. RFC6698  If you trust DNSSEC, you no longer need a certificate authority to validate certificates.

148 DANE: Actual Record Content.  Cert Usage: For mapping to end certs, or intermediate certs. See RFC6698 section 2.1.1.RFC6698 section 2.1.1  Selector: Match against full cert of just public key ?.  Type: Exactly match or SHA256/512 hash of content ?

149 DANE: For HTTPS.  TLSA Records.  Transport Level Security Association.  Allows verification of TLS records via DNS. In theory removes the need for certificate authorities.  Only useful with DNSSEC. You need to trust DNS to trust DANE.  Minimal Current Support  Test tool at  should test out fine.

150 SSHFP: New Data Types.  Adds data for SSH fingerprints to DNS.  When you log into a SSH server for the first time, you get.

151 SSHFP: New Data Types.  Without SSHFP: Use offline verification.  Phone someone or something like that !  Confirm the fingerprint really is the server you expect.  SSHFP puts this confirmation in DNS.  If you trust DNS, you can verify the fingerprints.  DNSSEC lets you trust DNS.

152 SSHFP: New Data Types.  Algorithm.  1=RSA  2=DSA  Type.  1=SHA1  2=SHA256

Download ppt "THE DOMAIN NAME SYSTEM. A DEEP DIVE. David Groves, August 2014."

Similar presentations

Ads by Google