Documente Academic
Documente Profesional
Documente Cultură
Kyle Rankin
http://greenfly.org/talks/security/dnssec.html
1. ns1.someisp.com to root:www.greenfly.org?
request goes to ns1.someisp.com which goes to root DNS server.
2. root to someisp.com to root:www.greenfly.org?
the root levels, odn't know your website, only top levels (org, net etc). Go
talk to ...
3 someisp.com to org: www.greenfly.org
4. org to ns1.someisp.com: no clue, bu ns1.greenfly.org and ns2.greenfly.org know
about it. Here are their addresses...
6.
7.
(see slides)
DNSSEC-enabled zones get key sinngatures signed, bpulicsed by TLD (need to get them
signed and published by their org servers)
DNSSEC_caapable resolveres anchor trust in root DNS keys (they implicitly trust
each other... they org trusts root, DNS servers trust org, etc to validate the
entire chain)
If record tampered with, signature won't match (impossible to spoof because they
dont' have your private key)
If record doesn't exist, absence is also signed (you cannot just inject a record if
name server doesn't have it, it will sign the record is absent also)
root (.) has a DNSKEY (KSK), com has a key, trian of trust goes from . to com to
google
Terms
// share public key w your parent and in your own zone (ZSKs have them in
your own zone so you share them there too, that's the only one you make public)
// ensure you keep the public key private or you can be exploited!!!
NSEC - Next SEcure, used in "negative answers" to prove whether a name exists or
not
NSEC3 - Next Secure (v3). Like NSEC, protects against "zone walking". NSEC flaw
let you walk the entire zone to know the records existed, even if you don't know
their contents, DNS is open, shouldn't nec treat them as secret, but some ppl do
DS - Delegation Signer. Contains KSK signature & submitted 2 zone parent as part
of chain of trust (this si the rec you send up that they sign & publish etc)
DLV - DNSSEC Look-aside Validation. Much like DS records, used when DS records not
supported. Your avg com net or org today, u want to enable DNSSEC, there may be 3-
4 registrars in the US that could shared DNSSEC if you want (GoDaddy charges $30/mo
extra) and a few others. Need some kind of cert that you are the administrator,
lets you have a diff root of trust (other name server that will sign my zone, ISC
is the primary, DLV.ISC.ORG is the site. BIND lets you implicitly trust DLV.ISC.ORG
// use dlv.isc.org if you cannot use the resource records directly for
some reason
root (.) trusted by org ((dark keys are KSK, light keys are ZSK, sometimes you have
multiples)
dlv.isc.org (KDK, ZSK, and your record you pub & send to them)
Implementing DNSSEC
Or if using DLV:
...
zone "greenfly.org" {
type master;
file "/etc/binddb.greenfly.org.signed";
allow-transfer {slaves; } ;
};
To validate DLV zones, add addiitional BIND option and trusted key
options { dnssec-lookaside . trust-anchor dlv.isc.org.; };
trusted-keys {
dlv.isc.org. 257 3 5 "BEAAAAPHMu//5onzrEE7z1egmhz/WPO0+juoZrW
};
// useful if you want to run this thing internally only and don't want to send it
to the outside world to get it signed
// sounds like a CA system, can you use it to replace a CA system? (some CAs are
really upset about this)
// tells resolver to enable dnssec and try to validate the chain of trust
// flags: qr aa rd ra;
// aa = it is itself saying "I'm fine"
// there is a diff flag, ad, that signifies that DNS was validate (query someone
except that name server and tell them to do a recursive query).
NS reecords (1 RRSIGN for both NS records, 1 set, 1 sig that applies to both)
Prolbem with CA system, u have to implicitly trust them all. In this case, instead
of trusting all these guys, you can kick out some (13 root name servers no matter
what happens). Now, what are you going to do? DANE causes you to trust fewer
entities in a way you can't revoke them every. An alternative is proposed to let
you invoke and revoke trust by entity. (more decentralized).
?: We sitll have to trust the core root implicitly (up, but not secure). Not to
lie to me. That's what the CA system is for, puts trust in 1 entity, the DNS
system itself.
If you want to test it: Chrome since 2011, add on for firefox.
Implicitly trust: how do we ensure the top end is secure to begin with. HOw do we
trust the root zones before we trust them (w/o having Dan Kaminsky showing his
key). Download from bind from