DNS Security

Download Report

Transcript DNS Security

DNS Security
A.Lioy, F.Maino, M. Marian, D.Mazzocchi
Computer and Network Security Group
Politecnico di Torino (Italy)
presented by: Marius Marian
What is DNS?

A replicated, hierarchical, distributed system
that provides:




name <=> IP address translation
mail handling information
DNS can use either UDP or TCP protocols
DNS major components:



the domain name space described by the
resource records (RR) (e.g., SOA, NS, A, MX, ...)
name servers
resolvers
Why is DNS security important?


Used extensively by INTERNET applications!
DNS security problems:




name servers can be easily spoofed and are
vulnerable to many types of attacks (DoS, buffer
overrun, replay, a.s.o.)
resolvers can be lead into trusting false information
security measures (e.g., ACLs) and mechanisms
(e.g., credibility) make spoofing more difficult but
not impossible!
June 1997, Eugene Kashpureff (Alternic
founder) redirected the internic.net domain to
alternic.net by caching bogus information on
the Internic name server
DNS cache poisoning attack
broker.com
evil.com
2. anyhost.evil.com?
1. anyhost.evil.com?
ns.evil.com
ns.broker.com
5. anyhost.evil.com=A.B.C.E
cache
9.www.bank.com=
A.B.C.D
3. Store query ID
4. anyhost.evil.com=A.B.C.E
Attacker host
A.B.C.D
6. www.bank.com?
8. www.bank.com=A.B.C.D
flooding false responses to name server
10.www.bank.com?
any.broker.com
11.wrong response
12. wrong connection to the attacker’s host from cache
bank.com
ns.bank.com
7. www.bank.com
DNSSEC definition

DNS security extensions (RFC 2535 - 2537):





SIG - stores digital signatures (asymmetric keys)
KEY- stores public keys
NXT- authenticates the non-existence of names or
types of RRs in a domain
DNSSEC deals with RR sets (same label, type
and class, different data), not singular RRs!
DNSSEC intends to provide:



data origin authentication and data integrity
key distribution
on a smaller scale - transaction and request
authentication
DNSSEC characteristics (1)

KEY RR specifies




the type of key (zone, host, user),
the protocol (DNSSEC, IPSEC, TLS, etc.),
the algorithm (RSA/MD5, DSA, etc.),
SIG RR specifies




the RR type covered (SOA, A, NS, MX, etc.),
the algorithm (RSA/MD5, DSA, etc.),
the inception & expiration times,
the signer key footprint
DNSSEC characteristics (2)

NXT RR specifies






the next name in the zone
all the RR types covered by the current name
The private key is kept off-line and is used to
sign the RR sets of the zone file
The public key is published in the KEY RR
The public key of a zone is signed by the
parent zone private key
The parent zone signature on the zone’s
public key is added to the zone file
DNS and DNSSEC zone files
foo.com.
foo.com.
a.foo.com.
d.foo.com.
SOA
NS
A
A
…
…
…
...
foo.com. SOA
foo.com. SIG
foo.com. SIG
foo.com. NS
foo.com. SIG
foo.com. KEY
foo.com. SIG
foo.com. NXT
NS KEY SIG
foo.com. SIG
a.foo.com. A
a.foo.com. SIG
a.foo.com. NXT
a.foo.com. SIG
d.foo.com. A
d.foo.com. SIG
d.foo.com. NXT
d.foo.com. SIG
…
SOA
…
AXFR …
…
NS
…
…
KEY
…
a.foo.com. SOA AXFR
…
…
A
…
d.foo.com. A SIG
NXT
…
…
A
…
foo.com. A SIG
NXT
…
NXT
DNSSEC chain of trust
The public key of root domain
is pre - trusted by all the name
servers!
.
Root name server of the
DNS tree
com.
name server
it.
host.foo.com. ?
polito.it.
Local name server
foo.com.
name server
It receives the RRs: A, SIG, KEY
host.foo.com.
131.195.21.25
DNS transaction security


Transaction Signature (TSIG) is another
security extension using shared secret keys still an Internet draft!
A better solution - to have communication
security between name servers and resolvers





TSIG authenticates DNS queries and responses
TKEY is a meta RR containing the secret key
TSIG, TKEY - not stored in the zone files/cache
PROBLEM: storage of the shared secret!
HMAC/MD5 provides authentication and
integrity checking for transactions
DNS as a public key infrastructure





DNS with these security extensions can
become the first implementation of a PKI
world wide available
DNSSEC “chain of trust” is a model of
certification
For storing certificates a new RR is added to
DNS - the CERT RR defined in RFC 2538
CERT can store PGP, X.509, SPKI certificates
RFC 2538 recommends that the size of
certificates should be reduced at maximum if possible, no extensions at all!
Remarks on DNSSEC







In the DNS, cryptography is used for authentication/ integrity, not for confidentiality
Attention must be paid to key generation, key
storage and key lifetime - (RFC 2541)
Special care for root and TLD’s pair of keys!
Secure resolvers must be configured with some
pre-trusted on-line public key (root)
The size of zone files grows up dramatically
Augments the data transferred, the messages
(hence, TCP instead of UDP), also the number of
computations (CPU cycles)
The responsibility of the administrators increases!
State of the Art



1998, first prototype of a DNSSEC package
based on BIND v4.9.4 produced by TIS Labs
(Trusted Information Systems)
The new BIND v9 (ISC) will be a major rewrite
of the underlying DNS architecture and will
provide support for DNSSEC, TSIG and CERT
RSA Co. provides the DNSsafe cryptographic
library for BIND v9
Conclusions

The security extensions provide:

protection of Internet-wide transfers:



protection of local DNS transfers:



the data is signed with public keys (SIG, KEY)
the absence of DNS data is notified (NXT)
the messages between name server and resolver
are authenticated (TSIG)
zone transfers between primary/secondary name
servers
public key infrastructure:


distribution of public keys for other security aware
protocols (KEY)
distribution of different types of certificates (CERT)