What is DNS? Systems to convert domain names into ip addresses: For an instance; www.tashicell.com 118.103.136.66 Reverse: 118.103.136.66 www.tashicell.com
DNS Hierarchy
Root Servers The top of the DNS hierarchy There are 13 root name servers operated around the world, with names from [a-m].root-servers.net There are more than 13 physical root name servers Each rootserver has an instance deployed via anycast Root hints file come in many names (db.cache, named.root, named.cache, named.ca) Get it from ftp.rs.internic.net See root-servers.org for more detail
DNS QUERY-How Does It Work? Image:(nsrc)
Background The original DNS protocol wasn t designed with security in mind It has very few built-in security mechanism DNSSEC and TSIG were developed to help address this problem
Name Servers Name servers answer DNS questions Several types of name servers Authoritative servers master (primary) slave (secondary) Caching or recursive server also caching forwarders
Authoritative Nameserver A nameserver that is authorised to provide an answer for a particular domain. Can be more than one auth nameserver primary Two types based on management method: secondary Primary (Master) and Secondary (Slave) Only one primary nameserver All changes to the zone are done in the primary secondary Secondary nameserver/s will retrieve a copy of the zonefile from the primary server Slaves poll the master periodically Primary server can notify the slaves
Caching Vs Authoritative Server DNS servers can be put in two categories: caching and authoritative Caching nameservers act as query forwarders on behalf of clients, and cache answers for later. Can be the same software (often is), but mixing functionality (recursive/caching and authoritative) is discouraged (security risks + confusing) The TTL of the answer is used to determine how long it may be cached without requerying.
ZONE File Sample $TTL 86400 ; 24 hours could have been written as 24h or 1d $ORIGIN example.com. @ 1D IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 3H ; refresh 15 ; retry 1w ; expire 3h ; minimum ) IN NS ns1.example.com. IN MX 10 mail.another.com. ns1 IN A 192.168.0.1 ;name server definition www IN A 192.168.0.2 ;web server definition fred IN A 192.168.0.4
Reverse Zone File Sample $TTL 86400 ; 24 hours, could have been written as 24h or 1d $ORIGIN 0.168.192.IN-ADDR.ARPA. @ 1D IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 3H ; refresh 15 ; retry 1w ; expire 3h ; minimum ) IN NS ns1.example.com. 1 IN PTR ns1.example.com. 2 IN PTR www.example.com. 4 IN PTR fred.example.com.
Record Types Basic record types: A, AAAA: IPv4, IPv6 address NS: NameServer MX: Mail exchanger CNAME: Canonical name (alias) PTR: Reverse
DNS RISKS Misdirection of queries for an entire domain(cache Poisoning) Response to non-existent domains MX hijacking Make a large domain (SLD or TLD) domain disappear from an ISP's cache DoS Identity theft using SSL stripping attacks (banks, egovernance) Many more
DNS Cache Poisoning 1 I want to access www.example.com Client DNS Caching Server 3 www.example.com 192.168.1.99 2 QID=64569 QID=64570 QID=64571 QID=64571 match! (pretending to be the authoritative zone) Root/GTLD QID=64571 www.example.com 192.168.1.1 3 Webserver (192.168.1.1) ns.example.com
DNS DOS Attack Reflected DNS amplification Using open recursive DNS servers and spoofed source IP (target) Seeks to exhaust target network s resources (bandwidth) with responses from multiple DNS servers DNS query floods flood of legitimate-seeming queries sent to target DNS server for a domain Uses botnet that automatically sends a significant number of queries Difficult to differentiate between a standard and malicious query
DNS Amplification A type of reflection attack combined with amplification Source of attack is reflected off another machine Traffic received is bigger (amplified) than the traffic sent by the attacker UDP packet s source address is spoofed (Spamhaus Attack)
Open Resolvers DNS servers that answer recursive queries from any host on the Internet http://openresolverproject.org/ Check if you re running open resolvers http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl More statistics at http://dns.measurement-factory.com/surveys/openresolvers/asn reports/latest.html
Good DNS Practices Enter the correct e-mail address of the responsible person for each zone you add to or manage on a DNS server. Do not combine authoritative and recursive nameserver functions -- have each function performed by separate server sets. Run multiple, distributed authoritative servers, avoiding single points of failure in critical resource paths. A variety of strategies are available (including anycast and load-balancing) to ensure robust geographic and network diversity in your deployment.
Securing NameServers Run the most recent version of the DNS software Apply the latest patch Hide version Restrict queries Allow-query { acl_match_list; }; Prevent unauthorized zone transfers Allow-transfer { acl_match_list; }; Run BIND with the least privilege (use chroot) Use TSIG and DNSSEC
DNS: Data Flow Zone administrator Zone file 1 master 4 Caching forwarder 2 3 5 Dynamic updates slaves resolver
DNS Vulnerabilities Corrupting data Zone administrator Zone file 1 Impersonating master master 4 Caching forwarder Cache impersonation Dynamic updates 2 Unauthorized updates slaves 3 Cache pollution by Data spoofing 5 resolver Server protection Data protection
TSIG Protected Vulnerabilities Zone administrator Impersonating master Zone file master Caching forwarder Dynamic updates slaves resolver Unauthorized updates
What is TSIG - Transaction Signature? A mechanism for protecting a message from a primary to secondary and vice versa A keyed-hash is applied (like a digital signature) so recipient can verify message DNS question or answer and the timestamp Based on a shared secret - both sender and receiver are configured with it
Transaction Signatures (TSIG) TSIG is most-commonly used to authenticate slave servers to master servers during zone transfers Protects against impersonating master and unauthorized updates Master and slave servers: share a common secret key & agree on key name Synchronized clocks (NTP) The shared information (key) is used to authenticate a client to a server Remember to change the key periodically
What is TSIG - Transaction Signature? TSIG (RFC 2845) authorizing dynamic updates & zone transfers authentication of caching forwarders Used in server configuration, not in zone file
TSIG steps Generate secret dnssec-keygen -a <algorithm> -b <bits> -n host <name of the key> Communicate secret scp <keyfile> <user>@<remote-server>:<path> Configure servers key { algorithm...; secret...;} server x { key...; } Test dig @<server> <zone> AXFR -k <TSIG keyfile>
DNS Security Extensions (DNSSEC) Protects the integrity of data in the DNS by establishing a chain of trust Uses public key cryptography each link in the chain has a public/private key pair A form of digitally signing the data to attest its validity Standard is defined in RFC4033, RFC4034, and RFC4035 Guarantees Authenticity Integrity Non-existence of a domain
DNSSEC Concepts Changes DNS trust model from one of open and trusting to one of verifiable Use of public key cryptography to provide: Authentication of origin Data integrity Authenticated denial of existence No attempt to provide confidentiality (NO encryption) DNSSEC does not normally place computational load on the authoritative servers (!= those signing the zone) No modifications to the core protocol.
DNSSEC Concepts Build a chain of trust using the existing delegation-based model of distribution that is the DNS.
DNSSEC Concepts Don't sign the entire zone, sign a RRset Note: the parent DOES NOT sign the child zone. The parent signs a pointer (hash) to the key used to sign the data of child zone (DS record). Always on the master server. Check if slaves are receiving the signed zones.
DNSSEc: new RRs RRSIG = Signature over RRset made using private key DNSKEY = Public key, needed for verifying a RRSIG DS = Delegation Signer; Pointer for building chains of authentication NSEC = Next Secure; indicates which name is the next one in the zone and which typecodes are available for the current name authenticated non-existence of data DS record provides a mechanism to delegate trust to public keys of third parties
Types of Keys Zone Signing Key (ZSK) Sign the RRsets within the zone Public key of ZSK is defined by a DNSKEY RR Key Signing Key (KSK) Signed the keys which includes ZSK and KSK and may also be used outside the zone
Signing the zone (using the BIND tools) 1. Generate keypairs 2. Include public DNSKEYs in zone file 3. Sign the zone using the secret key ZSK 4. Publishing the zone 5. Push DS record up to your parent(how?) (Note:signing always done in Master and validation in resolver)
Creation of Keys Trusted anchor in a security aware server Part of the chain of trust by a parent name server Use of a single key or both keys is an operational choice (RFC allows both methods) Create ksk(key signing key) and zsk(zone signing key), be it manual or automated signing.
Key Generation # Generate ZSK dnssec-keygen [-a rsasha1 -b 1024] -n ZONE myzone # Generate KSK dnssec-keygen [-a rsasha1 -b 2048] -n ZONE -f KSK myzone Signing Of Zone:dnssec-signzone myzone
KEY MANAGEMENT Need to implement secure key storage, management procedures Need to sign your zones Registries need to accept DS records from users (how?) Need to publish DS records to parents (how?) Manual Signing: Key RollOvers Key Never expire. Need to resign Automated Signing: Opendnssec or inline signing.
Inline Signing Dnssec Signing made easy.(automatic signing and key rollovers) Requires Bind Version 9.9 and above. Enabled by the "inline-signing yes;" statement in named.conf Create zsk and ksk but sign using inline and resign using (auto-dnssec maintain). Check if it s signing. Check logs. $ dig @localhost mytld NS +dnssec(to check if dnssec is working, for manual also) $ sudo named-checkzone -D -f raw -o - mytld mytld.signed less how do we update the zone and resign it? Problem:Doesn t generate keys in some distro,use haveged.