DNSSec

How to protect the integrity of DNS

DNS (Domain Name System)

• Is a directory lookup service that provides a mapping between the name of a host on the Internet and its numeric IP address
• Is essential (but not necessary) to the functioning of the Internet
• Is used by Mail User Agents (MUAs) and Mail Transfer Agents (MTAs) to find the address of the next hop server for mail delivery
• Consists of four elements:
  1. Domain Name Space: DNS uses a tree-structured name space to identify resources on the Internet
  2. DNS Database: Conceptually, each node and leaf in the name space tree structure names a set of information that is contained in resource record (RR). The collection of all RRs is organized into a distributed database.
  3. Name Servers: server programs holding information about a portion of the domain name tree structure and the associated RRs.
  4. Resolvers: programs that extract information from name servers in response to client requests. A typical client request is for an IP address corresponding to a given domain name.

DNS Database

• DNS is based on a hierarchical database containing resource records (RRs) that include the name, IP address, and other information about hosts
• Key features of the database:
  • Variable-depth hierarchy for names:
    • DNS allows essentially unlimited levels and uses the period (.) as the level delimiter in printed names
  • Distributed database:
    • The database resides in DNS servers scattered throughout the Internet
  • Distribution controlled by the database:
    • The DNS database is divided into thousands of separately managed zones, which are managed by separate administrators

Resource Record (RR) Types

Type	Description
A	A host address. This RR type maps the name of a system to its IPv4 address. Some systems (e.g.. routers) have multiple addresses, and there is a separate RR for each.
AAAA	Similar to A type, but for IPv6 addresses.
CNAME	Canonical name. Specifies an alias name for a host and maps this to the canonical (true) name.
HINFO	Host information. Designates the processor and operating system used by the host.
MINFO	Mailbox or mail list information. Maps a mailbox or mail list name to a host name.
MX	Mail exchange. Identifies the system(s) via which mail to the queried domain name should be relayed.
NS	Authoritative Name Server for this domain.
PTR	Domain name pointer. Points to another part of the domain name space.
SOA	Start of a zone of authority (which part of naming hierarchy is implemented). Includes parameters related to this zone.
SRV	For a given service provides name of server or servers in domain that provide that service.
TXT	Arbitrary text. Provides a way to add text comments to the database.
WKS	Well-known services. May list the application services available at this host.

DNS Name Resolution

Source: https://spinlab.wpi.edu/courses/ece2305_2014/dns2.pdf

Kaminsky Attack

Source: http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

DNS Resolution via Recursive Nameserver

This is the normal Flow:

DNS Request and Response

• DNS only accepts responses to pending queries; unexpected responses are simply ignored.
• Only Query ID & UDP Port need to match for the response to be considered valid!

Request

Response

Simple DNS Cache Poisoning

Cache poisoning is where the bad guy manages to inject bogus data into a recursive nameserver’s cache, causing it to give out that bad information to unsuspecting local clients.

An Attacker just sends ALL QIDs (src port is fixed)

Guessing Query ID and UDP Source Port

1. Bad guy asks the victim nameserver to look up a name in a zone for a nameserver he controls (perhaps test.badguy.com).
   • He might query the server directly, if it permits recursion from his location, or he might convince a user to lookup a name — perhaps by including the test hostname on a web page.
2. Victim nameserver receives the request and makes the usual rounds to resolve the name starting at the root servers. Here, we’ve put the root and GTLD servers in the same category to separate them from the bad guy’s nameserver.
3. Eventually, the victim nameserver will be directed to the bad guy’s nameserver: after all, it’s authoritative for badguy.com.
4. Bad guy monitors this lookup of test.badguy.com by sniffing the IP traffic going to his own machine, or perhaps even with a custom modification to the nameserver software, and from this discovers the source port and Query ID used.

Dan Kaminsky DNS Vulnerability

Previously our intention was to poison the final answer, the A record with the IP address, but what Dan discovered is that we can go up one level and hijack the authority records instead.

• Step 1 — bad guy client requests a random name within the target domain (www12345678.bankofsteve.com), something unlikely to be in cache even if other lookups for this domain have been done recently.
• Step 2a — As before, the bad guy sends a stream of forged packets to the victim, but instead of A records as part of an Answer, it instead delegates to another nameserver via Authority records. “I don’t know the answer, but you can ask over there”.
  • The authority data may well contain the “real” bankofsteve.com nameserver hostnames, but the glue points those nameservers at badguy IPs. This is the crucial poisoning, because a Query ID match means that the victim believes that badguy’s nameservers are authoritative for bankofsteve.com.
  • The bad guy now owns the entire zone.
• Curiously, the rest of the steps don’t matter: the point of this process was to fake out the victim into thinking that badguy runs the domain in question, and that would have been successful in this step.
  • Once one of the victim’s queries has been poisoned — it could be any in the chain — all the rest are directed to badguy’s servers.

What’s the Fix?

Today Query IDs & Source Ports are randomized

DNS Security Resource Records

DNS Security Extensions (DNSSEC)

• Provides end-to-end protection through the use of digital signatures that are created by responding zone administrators and verified by a recipient’s resolver software
• Avoids the need to trust intermediate name servers and resolvers that cache or route the DNS records originating from the responding zone administrator before they reach the source of the query
• Consists of a set of new resource record types and modifications to the existing DNS protocol
• Defined in:
  • RFC 4033, DNS Security Introduction and Requirements
  • RFC 4034, Resource Records for the DNS Security Extensions
  • RFC 4035, Protocol Modifications for the DNS Security Extensions

RRsets

• Group all the records with the same type and the same name into a resource record set (RRset)
• The full RRset gets digitally signed and not the individual DNS records

Zone Signing Keys (ZSK)

• Each zone in DNSSEC has a zone-signing key pair (ZSK)
  • The private key digitally signs each RRset in the zone
  • The public key portion verifies the signature
• A zone operator creates digital signatures for each RRset using the private ZSK
  • The RRSIG is stored in the name server as a RRSIG record
• The zone operator also needs to make their public ZSK available by adding it to the name server in a DNSKEY record.
• When a DNSSEC resolver requests a particular record type (e.g., AAAA), the name server also returns the corresponding RRSIG and DNSKEY records
• The resolver can validate the response with the RRset, RRSIG, and public ZSK

Key Singing Keys (KSK)

• In addition to a zone-signing key, DNSSEC name servers also have a key-signing key (KSK)
• The KSK validates the DNSKEY records in exactly the same way as our ZSK secured our RRsets
• The name server publishes the public KSK in another DNSKEY record

Delegation Signer Records

• DNSSEC introduces a delegation signer (DS) record to allow the transfer of trust from a parent zone to a child zone
• A zone operator hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record

• Every time a resolver is referred to a child zone, the parent zone also provides a DS record
• This DS record is how resolvers know that the child zone is DNSSEC-enabled
• To check the validity of the child zone’s public KSK, the resolver hashes it and compares it to the DS record from the parent
• If they match, the resolver can assume that the public KSK hasn’t been tampered with, which means it can trust all of the records in the child zone

This is how a chain of trust is established in DNSSEC:

Denial of Existence

• If you ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer.
• This is a problem if you want to authenticate the response, since there’s no message to sign.
• DNSSEC fixes this by adding the NSEC (Next Owner Name) and NSEC3 (Next Owner Name in Hashed Order) record types.
  • They both allow for an authenticated denial of existence.
  • NSEC works by returning the “next secure” record
    • Allows enumeration of complete zone data!
  • NSEC3 uses hashed names
    • Does not allow straight enumeration of zone data!
    • Dictionary attacks are possible but expensive
• Example:
  • Consider a name server that defines AAAA records for api, blog, and www.
  • If you request a record for store, it would return an NSEC record containing www.
  • This effectively tells you that store doesn’t exist.

DANE (DNS-Based Authentication of Named Entities)

• DANE is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using DNSSEC
• It is proposed in RFC 6698 as a means to authenticate TLS client and server entities without a certificate authority (CA)
• The purpose of DANE is to replace reliance on the security of the CA system with reliance on the security provided by DNSSEC
• DANE defines a new DNS record type, TLSA, that can be used for a secure method of authenticating SSL/TLS certificates

Verifying Server and CA Certificates

Getting CA Certificate or Public Key

Verifying Self-Signed Server Certificates

Verifying Raw RSA Keys

Get Server Certificate or Public Key

DNS Root Signing

Root Zone Signing Process

Root Zone Signing Key Signing Process

---

Relevant Note(s):