Internet Lab (iLab1) Domain Name Sytem Dominik Scholz - - PowerPoint PPT Presentation

Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Internet Lab (iLab1) Domain Name Sytem

Dominik Scholz ilab1@net.in.tum.de

Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Lab 5 – WiSe 2018

Outline

Meta Domain Name System Authoritative name server Resolver Security

1/32

Outline

Meta Domain Name System Authoritative name server Resolver Security

2/32

Oral attestations

Scope of the oral attestations:

• expert knowledge of the lecture content
• show us your individual understanding of the labs
• labs and lectures 1–5 (including crypto)
• you may choose the lab to start with
• prepare for oral attestation: you have to explain things
• duration 10 minutes
• 20% of grade
• room 03.05.051 (or 03.05.033)

3/32

Oral Attestations

• Make sure you can access lecture recordings NOW
• Make sure you confirmed your time slot!
• We assume you show up for your designated slot
• Attestation is required for passing the course

4/32

Outline

Meta Domain Name System Authoritative name server Resolver Security

5/32

The quest for memorable names

• IP addresses hard to remember for humans
• symbolic names mapped to addresses

address resolution

• 1. host files
• file with mappings
• copy between all machines
• /etc/hosts
• 2. protocol: Domain Name System
• by Paul Mockapetris in 1983
• wide deployment in 1988

6/32

Domain Name System

• application layer protocol on UDP

, TCP

• glibc call getaddrinfo(3)
• distributed name database
• deployed globally
• hierarchical structure
• extensible
• e.g. DNSSEC: security extensions inside the protocol itself

7/32

Distributed hierarchical name space

. net lwn edu tum cs mail ma ei

• rg

gnu debian Fully qualified domain name (FQDN) by label concatenation: mail.cs.tum.edu.

8/32

Distributed hierarchical name space

root zone (empty label) top level domain second level domain . net lwn edu tum cs mail ma ei

• rg

gnu debian Fully qualified domain name (FQDN) by label concatenation: mail.cs.tum.edu.

8/32

Name server

Name servers can fulfill different functions:

• 1. authoritative name servers
• perated by a site on the Internet
• 2. resolver
• asked to resolve names
• contacts authoritative name servers

Example

Knot and unbound

9/32

Outline

Meta Domain Name System Authoritative name server Resolver Security

10/32

Zone

• subtree of the global name space
• delegated by parent
• managed by one organization
• hosted on an authoritative name server

Example

tum.edu. delegated by edu., containing www.tum.edu. and mail.in.tum.edu.

11/32

Authoritative name server

• only knows about its own part of the name space
• responsible, “authoritative”, for its zone
• may serve multiple zones
• usually primary and secondary servers exist for a zone
• synchronized with zone transfer
• avoid disappearance of the zone in case of outage
• load balancing

12/32

Zones: example

. net lwn edu tum cs mail ma ei

• rg

gnu debian

13/32

Resource record

• zone contains resource records (RR)

example.net. 3600 IN A 198.51.100.5

• wner

TTL class type RDATA domain name where RR is found

14/32

Resource record

• zone contains resource records (RR)

example.net. 3600 IN A 198.51.100.5

• wner

TTL class type RDATA validity period in seconds when cached

14/32

Resource record

• zone contains resource records (RR)

example.net. 3600 IN A 198.51.100.5

• wner

TTL class type RDATA

• nly Internet is relevant for us

14/32

Resource record

• zone contains resource records (RR)

example.net. 3600 IN A 198.51.100.5

• wner

TTL class type RDATA record type, e.g. IPv4 address

14/32

Resource record

• zone contains resource records (RR)

example.net. 3600 IN A 198.51.100.5

• wner

TTL class type RDATA resource data: e.g. 32 bit IPv4 address

14/32

Resource records

• wner

TTL class type RDATA i.example.net. 3600 IN AAAA 2001:db8::1 like.example.net. 3600 IN AAAA 2001:db8:af23::eb2 dns.example.net. 3600 IN A 192.0.2.25 i.example.net. 3600 IN A 192.0.2.205

15/32

Resource records

• wner

type RDATA i.example.net. AAAA 2001:db8::1 like.example.net. AAAA 2001:db8:af23::eb2 dns.example.net. A 192.0.2.25 i.example.net. A 192.0.2.205 i.example.net. AAAA 2001:db8::2

• RRset for i.example.net. type AAAA with more than one record!
• note: TTL and class usually omitted

15/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ]

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ] ; RRset with two records: NS example.net. NS ns1 ; primary authoritative NS example.net. NS ns2.registrar.example. ; secondary

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ] ; RRset with two records: NS example.net. NS ns1 ; primary authoritative NS example.net. NS ns2.registrar.example. ; secondary ns1 A 198.51.100.1

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ] ; RRset with two records: NS example.net. NS ns1 ; primary authoritative NS example.net. NS ns2.registrar.example. ; secondary ns1 A 198.51.100.1 example.net. MX 10 mail ; priority to order multiple MX RRs

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ] ; RRset with two records: NS example.net. NS ns1 ; primary authoritative NS example.net. NS ns2.registrar.example. ; secondary ns1 A 198.51.100.1 example.net. MX 10 mail ; priority to order multiple MX RRs mail AAAA 2001:db8::1 A 198.51.100.2

16/32

Zone file and record types

$ORIGIN example.net. ; everything will be relative to this $TTL 1h ; default TTL could be overwritten later example.net. IN SOA ns1 hostmaster [. . . ] ; RRset with two records: NS example.net. NS ns1 ; primary authoritative NS example.net. NS ns2.registrar.example. ; secondary ns1 A 198.51.100.1 example.net. MX 10 mail ; priority to order multiple MX RRs mail AAAA 2001:db8::1 A 198.51.100.2 webmail CNAME mail ; alias for a canonical name

16/32

Delegation

sub.example.net. NS ns.sub.example.net. ns.sub.example.net. A 198.51.100.3

• make ns.sub.example.net. responsible for the sub.example.net. zone
• glue record to make the new name server findable
• possible misconfigurations

1. missing glue records 2. delegation loops 17/32

Outline

Meta Domain Name System Authoritative name server Resolver Security

18/32

Resolving name server tasks

• query: owner, class, type
• resolve a query from the root downwards
• cache responses based on TTL
• changes might only be visible after days

Allow access only from your network, never open for everybody

19/32

DNS packet layout

IP UDP DNS header query answer authoritative additional ID, flags, number of RRs records

header

c,s QR query or response s AA authoritative answer s TC truncation (TCP as fallback) c RD recursion desired s RA recursion available s 4 bit response code: no error, name error, server failure, refused

• number of resource records in each section

20/32

DNS packet layout

IP UDP DNS header query answer authoritative additional ID, flags, number of RRs records

record sections

• query: only one record with owner, type, class
• answer: answer RRs
• authoritative section: name server delegation
• additional section: glue records, EDNS pseudo record

packet size limited to 512 octets

20/32

Lookup

stub forwarder recursor in.tum.de. IP?

• recursive queries

21/32

Lookup

stub forwarder recursor in.tum.de. k.root-servers.net. 2001:7fd::1 in.tum.de. A

• de. NS a.nic.de.

a.nic.de. A 194.0.0.53

• recursive queries
• iterative queries
• glue

21/32

Lookup

stub forwarder recursor in.tum.de. k.root-servers.net. a.nic.de. in.tum.de. A tum.de. NS dns1.lrz.de. dns1.lrz.de A 129.187.19.183

• recursive queries
• iterative queries
• glue

21/32

Lookup

stub forwarder recursor in.tum.de. k.root-servers.net. a.nic.de. dns1.lrz.de. in.tum.de. A in.tum.de. A 131.159.0.35

• recursive queries
• iterative queries
• glue

21/32

Lookup

stub forwarder recursor in.tum.de. k.root-servers.net. a.nic.de. dns1.lrz.de.

• recursive queries
• iterative queries
• glue

21/32

Lookup

stub forwarder recursor in.tum.de. k.root-servers.net. a.nic.de. dns1.lrz.de. 131.159.0.35

• recursive queries
• iterative queries
• glue

21/32

Reverse lookup

IPv4

• PTR record type
• special domain in-addr.arpa.
• 198.51.100.5 → 5.100.51.198.in-addr.arpa.
• small subnets require lots of CNAMEs

IPv6

• ip6.arpa.
• can be delegated per nibble
• 2001:db8::1 is:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

22/32

Outline

Meta Domain Name System Authoritative name server Resolver Security

23/32

Common attacks using DNS

Cache poisoning

• send many packets with fake responses to a resolver
• spoofed source IP: address of an authoritative name server
• try to answer a query before the legitimate server does

Counter: randomize as much as possible: source port, query id

Distributed denial of service

• send queries with spoofed source address to open resolvers
• spoofed source address is attack target
• queries with high amplification factor

Counter: no open resolvers, ingress filtering (BCP 38)

24/32

Security extensions in DNS: DNSSEC

• data origin authentication
• data integrity
• no confidentiality
• inside the protocol, no *S layer
• no flag day

Basic idea

• signatures with public key cryptography
• zone owner signs RRsets offline using private key
• full resolvers verify signatures using public key

How do we know that the signing key really belongs to the zone owner?

25/32

Changes

New RR types

• RRSIG: signature over RRset
• signature validity introduces absolute time into DNS
• DS (delegation signer): hash of public key
• DNSKEY: public key
• NSEC, NSEC3: for nonexisting domains

26/32

Changes (cont’d)

header bits

c CD checking disabled: request delivery of DNSSEC records s AD answer authenticated: DNSSEC successfully verified

EDNS extension

• uses pseudo record
• larger UDP payload size

c DO bit: DNSSEC OK: include RRSIGs, DS

27/32

Zone signing

child zone RRset RRset private key public key signed child zone RRset RRset parent zone Note: root key comes with resolver software

28/32

Zone signing

child zone RRset RRset private key public key signed child zone RRset RRset RRSIG RRSIG parent zone Note: root key comes with resolver software

28/32

Zone signing

child zone RRset RRset private key public key signed child zone RRset RRset DNSKEY RRSIG RRSIG RRSIG parent zone Note: root key comes with resolver software

28/32

Zone signing

child zone RRset RRset private key public key signed child zone RRset RRset DNSKEY RRSIG RRSIG RRSIG parent zone DS RRSIG Note: root key comes with resolver software

28/32

Deal with nonexisting domains

NSEC

sign the hole between two domains: alice.example.net. NSEC charlie.example.net. A RRSIG NSEC

• + RRSIG
• no domains between alice and charlie
• alice only has A, RRSIG and NSEC records
• zone walking

NSEC3

• hash all domains
• order by hash value
• 0him. . . lfhr.example.net.

NSEC3

• 0lver. . . oj3l A RRSIG

29/32

Operational considerations

• offline signing
• small key sizes recommended for speed
• many parameter choices
• limited key lifetime, frequent rollover required
• best practice: key signing key, zone signing key

⇒ operational complexity

Example

Software like OpenDNSSEC or Knot automates a lot of this.

30/32

Security gaps

• TLD/root key operators cannot realistically be removed or replaced!
• last mile
• confidentiality
• actual connection content
• DDoS

31/32

Alternative approaches to securing DNS

Add transport security

• DNS over TLS
• DNS over HTTPS

These are not generally available at ISPs, have to hand pick resolver upending the trust model.

Oblivious DNS

• introduce new special TLD odns.
• send encrypted query via resolver to the odns. NS
• encrypting the query hides query from resolver
• using a resolver hides client identity from NS
• authoritative NS decrypts query and resolves it

32/32