the name servers they use But they need not be trustworthy Rogue DHCP server hands out resolv.conf pointing to pirates Attackers can take over networks (think WiFi in hotels) Viruses/trojans can alter local configuration In all cases: We loose control over DNS replies Install a validating DNS resolver "close" to applications auth servers validating resolver client
the name servers they use But they need not be trustworthy Rogue DHCP server hands out resolv.conf pointing to pirates Attackers can take over networks (think WiFi in hotels) Viruses/trojans can alter local configuration In all cases: We loose control over DNS replies Install a validating DNS resolver "close" to applications auth servers validating resolver client auth servers resolver client valid. resolv
caching-only, portable DNS server Maintained by NLNetlabs under BSD license Designed with DNSSEC and IPv6 from the ground up Trusts nothing Good security Many "distros" have packages I recommend newest version http://unbound.net/ Lightweight, fast, and easy to configure No split-personalities (And I was first to write about Unbound :-)
well known Establish a chain of trust from the root to any signed zone Each link validates the next Parent’s DS record validates child zone’s DNSKEY A child’s DS record in parent is signed by private key of parent Chain of trust root zone signed in July 2010 validation starts at trust "anchor"
in the configuration Get trust from delegation tree (DS in parent) Try to look up trust in DLV zone DNSSEC validation via parent (i.e. root) has priority over DLV
anchors in a file "my.keys", which contains DS or DNSKEY records p0000.aa IN DS 47534 8 1 74526d3f57... p0000.aa IN DS 47534 8 2 82512fb4ad... de. 86400 IN DNSKEY 257 3 8 AwEAAZ1FqQED8QBrk3Jk4q96lg example.com IN DS 47534 8 3 296fc89ee0... Configure keys into Unbound trust-anchor-file: "/etc/unbound/my.keys" Alternatively use trust-anchor configuration statements Configure the zone stub-zone: name: "de" stub-addr: 81.91.161.228 # auth-fra.dnssec.denic.de stub-addr: 87.223.175.25 # auth-ams.dnssec.denic.de
clients For example, a static "zone": local-zone: "ukuug." static local-data: "beamer.ukuug. IN A 192.168.1.12" local-data: ’paul.ukuug. TXT "Hi Paul!"’ local-data-ptr: "192.168.1.12 beamer.ukuug" Will it work? $ dig +short @127.0.0.1 paul.ukuug txt "Hi Paul!" No DNSSEC But local data can be added on-the-fly with unbound-control
normally) local-data: "foo.jpmens.org A 127.0.0.1" Redirect a whole domain to an IP local-zone: "example.aa" redirect local-data: "example.aa A 127.0.0.9"
Full control over DNS queries sent out by Unbound Full Control over DNS replies returned to Unbound clients Prototyping Gather Unbound statistics http://unbound.net/documentation/howto_statistics.html Wrap a resolver into your own application with libunbound http://unbound.net/documentation/libunbound.html
Unbound Forward to caches if possible Fallback to authoritative servers Fallback to NLnetLabs server via port 443 dnssec- trigger Unbound NLnetLabs Unbound public DNS caching DNS A B C