Embed Size (px)
Citation preview
THE DOMAIN NAME SYSTEM.A DEEP DIVE.
David Groves, August 2014.
Preparation. Intro and problem reporting. Install Dig (if you don’t already
have it). Install Firefox.
And the “DNSSEC Validator” Addon.
Problem Reporting. Please report
Errors. Omissions. Anything Unclear.
Any real life examples that don’t work anymore.
Reports to [email protected]
Dig ONLY ! When debugging DNS, always use dig.
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.
Installing Dig on Windows. Get the bind distribution from
http://www.isc.org/downloads/bind/ Unzip it somewhere (I like c:\bind\). Add it to your path (next slide).
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.
Introduction.
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.
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.
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.
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.
The DNS Protocol.
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)
Packet Format. Decoded (near) perfectly by Wireshark.
Which is good, as it isn’t readable by humans. Documented in many RFC’s. See http://www.statdns.com/rfc/ for a list of
DNS related RFC’s. Most important are RFC1034, RFC1035,
RFC2308, RFC6891.
Packet Format.
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 www.google.com. How do I send mail to [email protected]. What is the name of 8.8.8.8 ?
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.
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.
Compression. In Names only. Is a pointer to a previous name (by
position in the packet). Avoids repeating names in DNS
packets.
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).
Large Packets ? DNS Protocol Oddity.
With EDNS0 (RFC2671), DNS is one of the few sources of legitimate fragments on the internet.
Only really applies to answers > MTU. Fragments are generally only seen in
conjunction with DNSSEC (see later).
Fragments ?
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.
Common Packet Problems. RFC1035 defined limits on UDP DNS packet size.
UDP messages: 512 bytes or less. RFC6891 extends this and allows fragments. Lots of implementations ignore this.
Cisco ASA (< 8.2.2) block DNS UDP > 512bytes. Checkpoint default blocks fragments. Palo Alto PANOS (< 5.10) default blocks fragments.
People frequently think DNS is UDP only and engineer accordingly.
Stub Resolvers. What do clients do ?
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.
FIXME: DIAGRAM GOES HERE
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.
How stub resolvers learn recursive servers.
Static Configuration / Windows. In Adaptor Settings
Control Panel. Set per adaptor.
How stub resolvers learn recursive servers.
Static Configuration / Unix. In /etc/resolv.conf
Dynamic Learning of Nameservers (IPv4).
Learned via DHCPv4. RFC2132. Option Code 6 specifies a list of
IPv4 addresses that are DNS servers. 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.
Dynamic Learning of Nameservers (IPv6).
DHCPv6. RFC3646. List of IPv6 nameservers similar to DHCPv4. 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.
RDNSS (Recursive DNS server) option. DNSSL (DNS Search List) option. Included in the Router Advertisement packets.
What Search Paths Do. Let you abbreviate names. For example, with /etc/resolv.conf containing
search aaa.com bbb.com ccc.com If you try and resolve www then you try these
names in order. www.aaa.com. www.bbb.com. www.ccc.com. www.
Tips with the Windows Stub Resolver.
View the cache. Delete the cache.
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
Recursive Lookups.
What do recursive DNS servers do ?
What questions are they asked ?
How do they find the answers ?
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)
What recursive servers know. Only hardcoded data is the root hints file. Can download a current copy from
http://www.internic.net/domain/named.root; 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 198.41.0.4A.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 192.228.79.201B.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 192.33.4.12C.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 193.0.14.129K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7FD::1;; OPERATED BY ICANN;. 3600000 NS L.ROOT-SERVERS.NET.L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42;; OPERATED BY WIDE;. 3600000 NS M.ROOT-SERVERS.NET.M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33M.ROOT-SERVERS.NET. 3600000 AAAA 2001:DC3::35; End of File
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 http://www.internic.net/domain/root.zone
DNS: Like turtles all the way down.
Resolving a real name manually.
Do this yourselves. > dig @192.5.60.30 www.google.com
Resolving a real name manually.
You asked about a root server the IPv4 address of www.google.com
It said: I don’t know, but these guys know about .com, go ask them
It also said: Have a hint, these are the IP addresses of those guys.
Resolving a real name manually
Pick one of the servers. Use dig to ask it about www.google.com
I don’t know, but these guys know about .google.com, go ask them
Have a hint, these are the IP addresses of those guys.
Resolving a real name manually
Pick one of the servers. Use dig to ask it about www.google.com
Heh, I know the answer to that !.
www.google.com has these IPv4 addresses
Beyond Name -> IPv4 Address.
DNS stores more than just IPv4 Addresses.
Common DNS Record Types. Reverse DNS.
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 ?
Common Record Types.Record Type
What it stores.
A An IPv4 address.
AAAA An IPv6 address.
NS The name of a server responsible for this domain name.
MX A list of names of servers to send SMTP mail to for this domain.
CNAME An “Alias” record. An indication this isn’t the Canonical Name and you should look at another name for the data you seek.
TXT A string of ASCII text.
PTR Used for address to name resolution (reverse DNS – more later).
SOA Used to carry data about a zone itself (covered later in Authoritative sever operations).Full list at
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
The A Record.
Most commonly looked up DNS type. Is just an IPv4 address.
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.
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 fibrecat.org is an example. The
nameservers for it are ns0.fibrecat.org. and ns1.fibrecat.org.
DIAGRAM.
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
[email protected], you need the MX records for google.com
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.
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 :- Lookup the A and AAAA record of the domain name. Attempt SMTP connections to those addresses.
The CNAME Record. Says another name is the canonical name for the
name with the CNAME record. Example :-;; ANSWER SECTION:
www.bbc.co.uk. 300 IN CNAME www.bbc.net.uk.
www.bbc.co.uk is really www.bbc.net.uk
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.
CNAME Rules RFC1034 says :-
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.
CNAME Chains.
RFC advises against CNAME chains. But CNAME chains are often useful. An example is sites that use Akamai
CDN. Try “dig www.sky.com”.
CNAME Chains.;; ANSWER SECTION:
www.sky.com. 86400 IN CNAME www.sky.com.edgesuite.net.
www.sky.com.edgesuite.net. 21600 IN CNAME a1065.b.akamai.net.
a1065.b.akamai.net. 20 IN A 88.221.134.235
a1065.b.akamai.net. 20 IN A 88.221.134.178
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.
CNAME as Gateway to CDN’s. CNAME’s are used to direct users to CDN’s.
Sky operate DNS for sky.com But Sky want Akamai to direct users for www.sky.com.
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).
Zone Apex. That worked ! The URI changed to www.sky.com Look at the DNS for sky.com.;; ANSWER SECTION:
sky.com. 86400 IN A 90.216.128.5
What really happened ?
Zone Apex. Nothing to do with DNS. No rules broken. The webserver at 90.216.128.5 did an
HTTP level redirect.Remote Address:90.216.128.5:80
Request URL:http://sky.com/
Response Code: 302 Found.
Location: http://www.sky.com/
CNAME: Rule breaking. Some people do break the rules though.
Amazon Route53: Aliases Cloudflare: Zone Flattening Unused Internet Drafts: Sury + cz.nic
No DNS only solution, either standards based or defacto.
TXT Records Just contain ASCII text. Can be used as a very limited, very
cacheable, data distribution method. Try “dig TXT version.avg.com”.
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”.
Using dig to get reverse DNS. Dig uses the –x flag to give it addresses. Try :-
dig –x 85.236.110.149 or dig –x 2001:4db0:10:7:20c:29ff:fe6a:a65f
What are these giant names ? The IPv4 one was a bit odd.;; ANSWER SECTION:149.110.236.85.in-addr.arpa. 300 IN PTR zorro.fibrecat.org.
The IPv6 one was a monster.;; ANSWER SECTION:
f.5.6.a.a.6.e.f.f.f.9.2.c.0.2.0.7.0.0.0.0.1.0.0.0.b.d.4.1.0.0.2.ip6.arpa. 300 IN PTR zorro.fibrecat.org.
Any why are these backwards ?
The domains they are in. The top of the IPv4 address space
reverse tree starts at “in-addr.arpa”. The top of the IPv6 address space
reverse tree starts at “ip6.arpa”.
Why backwards ? IP addressing and DNS are both hierarchical. DNS has most significant part on the right.
www.google.com (com is more significant than google). IP addressing has the most significant part on the
left. 1.2.3.4 (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.
DIAGRAM.
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.
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. Similar methods can be used with IPv6.
Authoritative Servers. How to run a domain name.
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).
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.
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).
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).
SOA Records Somewhat magical voodoo. Lots of numbers. ;; ANSWER SECTION: google.com. 86400 IN SOA ns1.google.com.
dns-admin.google.com. 2014021800 7200 1800 1209600 300
SOA Records
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.
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).
SOA Records – Retry Time. If zone transfers fail, slaves wait this long
before trying again.
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.
SOA Records – Negative TTL. Individual records have individual TTL’s. This is the TTL of “Non Existent Record”. For example :-
You lookup iushhdiasdhasdhasd.google.com You get NXDOMAIN error (this name doesn’t exist). You can cache that non-existance for 300
seconds.
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.
Incremental Zone Transfers. Defined in RFC1995. Type “IXFR”. 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).
Notify. Defined in RFC1996. Sent by master to slaves when the zone
has changed. Slaves will then initiate zone transfers or
incremental zone transfers.
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.
DNS for Load Balancing. Anycast. Round Robin. Geographic Responses. Edns-client-subnet.
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.
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 8.8.8.8 is anycasted.
Anycast: Authoritative Servers. Many authoritative are anycasted. Examples are
Most of the root zone servers. RIPE’s locations @ http://k.root-servers.org/ Miami, Reykjavik, London (LINX), Helsinki, Poznan
(Poland), Budapest, Athens, Novosibirsk (Russia), Delhi, Tokyo and Brisbane.
The .com, .org and .net servers.
Round Robin. Earlier we say multiple
responses for www.google.com.
Clients connect to the first result.
DNS servers should give out answers in a rotating or random order.
Achieves crude load balancing.
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 clients WILL try and connect to all returned results.
Still want to remove down servers to improve performance.
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.
Geographic Response – Demo.
UK
Base
d H
ost
Usi
ng
Public
DN
S
UK
Base
d D
SL
Host
on
Sky
Bro
adban
d
US (
Texas)
Base
d
Host
Usi
ng
Public
DN
S
DNS-Client-Subnet. 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.
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 192.0.2.55 and server has mask 24
configured, will add 192.0.2.0/24 to EDNS0-CS header.
When request gets to authoritative server, it knows the (approximate) client IP address.
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.
DNS Security. Basics. Source Port Randomisation. Amplification Attacks. Dynamic DNS + TSIG. DNSSEC.
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.
Source Port Randomisation.
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.
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.
Amplification Attacks
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 ripe.net
Check message response size.
Defenses. BCP38 stops your users launching these attacks. Rate limiting ANY responses helps you not be an
amplifier in these attacks. (see 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.
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. RFC2845: TSIG Extensions to provide cryptographic based
authentication while doing so.
Dynamic DNS Operations. UPDATE messages contain.
Name: What name is this update associated with (eg: www.foo.com)
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.
Doing Dynamic Updates. BIND has the “nsupdate” command. Most programming languages have a
library. Perl: Net::DNS::Update Python: dnspython C: ldns Cisco IOS
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.
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.
No longer particularly secure. RFC4635: Adds new, more secure methods.
REQUIRED: HMAC-SHA1, HMAC-SHA256 OPTIONAL: GSS-TSIG, HMAC-SHA224, HMAC-SHA384, HMAC-
SHA512.
Server repeats and checks signatures match.
TSIG and Zone Transfers. Zone Transfers.
RFC5936: Allows signing of AXFR requests. Can sign response also. Allows for verification of
uncorrupted and untampered response. TCP should ensure not corrupted, but not untampered.
DNSSEC (DNS Security Extensions).
Stopping people lying to you.
Overview only. If you want the crypto maths,
sorry !
Timelines. First RFC on DNSSEC in 1995 – but they
are full of holes. 2005: Actually usable RFC’s (4033, 4034,
4035) are published. 2010: The Root Zone is first signed.
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.
Detecting when people are lying to you.
DNSSEC lets you spot liars. Relies on chain of trust. Chain starts at the root.
DNSSEC in Stub Resolvers.
Windows: See here. Windows Server 2012 only. OSX/Linux: Run nscd, unbound or bind locally.
Set /etc/resolv.conf to use 127.0.0.1or ::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.
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.
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.
The Root Trust Anchor.
Can be downloaded from IANA Getting a trusted copy without using DNS
is of course tricky. Generated in a complex ceremony (more
later).
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.
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.
Full DNSSEC lookup validation.
Graph generated by http://dnsviz.net/d/www.fibrecat.org/dnssec/
Shows chain of trust resolving www.fibrecat.org
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 www.fibrecat.org.
A | cat –n
Verify from the root down to the name. $ dig +sigchase +topdown +trusted-key=./root.keys
www.eurid.eu. A | cat -n
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. NSEC5: No known attacks at present time.
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.
Generating the Trust Anchor.
International Languages in DNS.
History. Current Practice.
History
When DNS was invented, the entire internet used English.
In 2010, it was
International Domain Names
Use Firefox. Since this link works :-
http://中国互联网络信息中心.中国/
You know IDN (International Domain Names) must be a thing. This site is the Chinese Internet Network
Information Centre.
International Domain Names
But DNS only does ASCII. What is going on ? RFC3492 & RFC5891: Defines punycode.
A way to map Unicode into ASCII. Not particularly space efficient.
For example, http://中国互联网络信息中心.中国/ is http://xn--fiqa61au8b7zsevnm8ak20mc4a87e.xn--fiqs8s/
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.
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.
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.
TXT for SPF Records.
SPF (Sender Policy Framework). Used to reduce mail forgery and spam. Became its own record type in RFC4408. Went back to just TXT for SPF in RFC7208.
Records look like :- fibrecat.org TXT "v=spf1 ip4:85.236.110.149 ip6:2001:41d0:1:e23f::1 -all"
Lists permitted senders for that domain.
TXT for SPF Records.
As well as IPv4 and IPv6 addresses. include:_netblocks.google.com
Lookup the TXT record for _netblocks.google.com. 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.
ENUM: Phone Number Mappings.
Backwards tree, like reverse DNS. Example name.
+44 113 496000 would be 0.0.0.6.9.4.3.1.1.4.4.e164.arpa.
Contains NAPTR records. Used to refer to SIP or other delivery methods. See RFC2916 or Wikipedia for more details.
SRV: Service Discovery.
Answers “what IP addresses provide X service at this domain” question.
Support load balancing and server failover. Records look like
_autodiscover._tcp.jax.com. 7200 IN SRV 10 0 443 owa.jax.com.
The autodiscover TCP service can be found on port 443 of owa.jax.com.
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).
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.
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: https://code.google.com/p/chromium/issues/detail?id=22423
Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=14328
HTTP2.0 may help by mandating this.
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.
If you trust DNSSEC, you no longer need a certificate authority to validate certificates.
DANE: Actual Record Content.
Cert Usage: For mapping to end certs, or intermediate certs. See RFC6698 section 2.1.1.
Selector: Match against full cert of just public key ?. Type: Exactly match or SHA256/512 hash of content ?
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 https://www.had-pilot.com/dane/danelaw.html https://fibrecat.org/ should test out fine.
SSHFP: New Data Types. Adds data for SSH fingerprints to DNS. When you log into a SSH server for the
first time, you get.
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.
SSHFP: New Data Types. Algorithm.
1=RSA 2=DSA
Type. 1=SHA1 2=SHA256
