Presentation_ID © 2001, Cisco Systems, Inc. All rights reserved. 1 1 1

Patrik Fältström paf@cisco.com The Domain Name System Patrik Fältström paf@cisco.com

Names & Numbers For communication on the Internet, we use a number of different identifiers URI’s Domain Names IP-Addresses MAC-Addresses The powerful thing is that the addressing is layered IP-address can change, while domain name is the same

Goal of this session The session will as a whole cover Design and functionality of DNS as we know it Tips and tricks regarding operations Future issues, good and bad You will after today better understand how DNS works, and why your DNS servers behave the way they do, and finally, you will be able to control it

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Resource Records A resource record consists of 4 (5) parts (Q)Name (Q)Type (Q)Class (TTL) Data QOwner, QClass and QType is the triple which is used in a query

Name (a domain name, variable length) The owner of a record is “the domain name” Also called “Owner, “name” or “label” If foo.example.com have IP address 192.168.1.2 foo.example.com. IN A 192.168.1.2 Then foo.example.com is the owner

Name (a domain name, variable length) A name consists of a series of labels A series of labels ending with NULL A pointer A series of labels ending with a pointer Label is one of +--+--+--+--+--+--+--+--+--+--+--+........+--+--+ | 0 0| LENGTH | DATA | +--+--+--+--+--+--+--+--+ | 0 0 0 0 0 0 0 0| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1| OFFSET |

Type (16 bits) Many different types exists A, MX, PTR, SRV, NAPTR, NS, SOA, NXT, SIG, KEY, TXT, CNAME, DNAME, A6,… Each type specify how the data is to be interpreted QType used in a query QType is a superset of Type used in a query

Class (16 bits) The class is for the Internet “IN” Other classes exists, but is not in widespread use One example: HS For realms in the Hesiod system (part of project Athena at MIT) Each class has it’s own root QClass used in a query QClass is a superset of Class

TTL - Time To Live (32 bits) In a response, the server sending the data set a minimum time to live on each record This indicates how long a server is allowed to cache the response We will look more closely at how TTL is calculated later on

Data (16 bit length field + data) The field which is the actual result of a query “The meat” Is to be interpreted differently for different Types Can be of different length for different Types

Resource Record Set A resource record set (or RR-set), is a group of records which have the same owner, same class and same type When we later look at DNSSEC, this is a very important definition to remember

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Delegation, distributed administration DNS is a protocol, but also a database with distributed administration In one server, one can delegate administration of sub-namespaces to other servers Delegation is done with an NS record which for a subdomain tell what nameservers are authoritative

Type NS An NS record hold the domain name for one nameserver for the domain given in the owner example.com. IN NS ns1.example.com. The nameservers pointed out must be authoritative for the domain If not, the delegation is said to be “Lame” More about authoritative servers later

Delegation, distributed administration In zone com: example.com. IN NS ns.example.com. In zone example.com: NS records exists in two zones

Glue records A delegation is made with NS records in the parent zone example.com. IN NS ns.example.com. example.com. IN NS ns.example.net. For the first of these two delegations, the host ns.example.com. is inside the delegated zone For this server, we need the A record in the parent zone This A record is called “glue”

Glue records In zone com: example.com. IN NS ns.example.com. ns.example.com.com. IN A 192.168.1.1 example.com. IN NS ns.example.net. In zone example.com:

Type SOA Keeps administrative information Name of master nameserver Email address to contact person Serial (version) number of zone Refresh interval* Retry interval* Timeout* TTL for Negative answers** * Only interesting for Slave servers ** Previously this was “default TTL”

Type SOA example.com. IN SOA ns.example.com. admin.example.com. ( 20020315 3600 1800 604800 900 )

Type SOA example.com. IN SOA ns.example.com. admin.example.com. ( 20020315 1h 30m 7d 15m )

Type CNAME Canonical name is an “alias” to a hostname Example: www.example.com. IN CNAME server.example.com. CNAME is given back independent on what Type the query was for This imply that if one have a CNAME, one is not allowed to have any other record with the same owner

se a b ns ns Domain and Zone All records with the same suffix are in the same domain A zone is a domain without the records which are part of delegated domains a b ns ns

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Difference between client and server Client and Server are relations A Client queries a Server A piece of software can both act as server and client, but not all do All Internet Software have some sort of client functionality built in, and that is called “the resolver” In some cases, the resolver is a special daemon, and not something which is linked with the main program. In this discussion, this distinction is though not relevant.

Difference between client and server Application DNS Server DNS Server Resolver (Client) Resolver (Client) Resolver (Client)

Resolver configuration The resolver need one thing only The IP address of DNS server to query One can also specify a search path Search path is added if the domain name is relative (do not end with a period), and only if lookup fails, the domain name itself is used

Recursion When a resolver send a query to a DNS server, it can (but doesn’t have to) ask for recursion The server can deny fulfilling the request Recursion means that the server queried will try to get the result by asking more than one DNS server if needed If recursion is not requested, the queried server only returns whatever he already knows

Recursion With recursion Without recursion Application DNS Server Resolver (Client) Application DNS Server Resolver (Client) Resolver (Client) DNS Server Resolver (Client) With recursion DNS Server Resolver (Client) Without recursion

Caching A resolver is allowed to cache the data given back from a DNS server, and the TTL is included in the response If the resolver get back a record with TTL 58 seconds, and it give away the record after 16 seconds, the TTL in the response must be 42 seconds This imply that TTL of 0 (zero) is not recommended, the record has timed out before it is used Whether this create problems or not is implementation dependent

Negative caching If no response exists (NXDOMAIN), the SOA record is sent back as authoritative information in the answer The fact that no information exists can be cached for the shortest value of TTL of the SOA record itself the TTL for negative answers inside the SOA record Max-cache-time = MIN(ttl-in-soa, ttl-of-soa)

Authoritative responses When a response is coming back from a server, the answer can come from two different sources A master or slave server A caching server (as cached result) In the first case, the answer has a flag set which says that the answer is authoritative

Example: using the command DIG The following example show the output from the command “dig” which is normally installed on UNIX computers One good thing with “dig” is that the output is very much structured like the DNS packet itself.

dig www.cisco.com. A - Page 1(2) ; <<>> DiG 9.3.0s20020317 <<>> www.cisco.com a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37547 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, ;; AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.cisco.com. IN A ;; ANSWER SECTION: www.cisco.com. 17433 IN A 198.133.219.25

dig www.cisco.com. A - Page 2(2) ;; AUTHORITY SECTION: cisco.com. 163351 IN NS NS1.cisco.com. cisco.com. 163351 IN NS NS2.cisco.com. ;; ADDITIONAL SECTION: NS1.cisco.com. 163351 IN A 128.107.241.185 NS2.cisco.com. 69881 IN A 192.135.250.69 ;; Query time: 382 msec ;; SERVER: 130.244.127.169#53(10.0.1.1) ;; WHEN: Mon Mar 25 15:12:30 2002 ;; MSG SIZE rcvd: 115

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Primary Server A primary server, or master, is reading the zone content from a (local) configuration The configuration must include all records in the zone, and administrative information Access control regarding queries, zone transfers and updates

Secondary Server A secondary server get the zone content by copying it from an authoritative server (master or slave) It looks in the SOA record to know how often it should check if the zone has changed (refresh) A zone “has changed” if serial number in SOA has increased

Stealth A stealth server is an authoritative server which is not announced via NS records in the zone itself Very normal to have the primary server being stealth This so noone query the primary server for data

Zone transfer A secondary server check the serial number in the SOA when timer “refresh” is zero If refresh fails, retry according to “retry” If failed for “timeout” period of time, stop responding to queries Zone transfer is over TCP, i.e. one example where DNS protocol is using TCP and not only UDP

Notify If a primary server is updated, it can send a NOTIFY message to secondary server(s) When a secondary server receive a NOTIFY message, the “refresh” timer is to be set to zero (so normal verification of serial number happens) Important to set how often Notify is to be sent in an environment where zone is updated often

Quite normal setup Primary/Stealth Secondary Secondary ns.example.com. 192.168.1.2 example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. Primary/Stealth Secondary Secondary ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Practice: How to set up a zone Configure primary server Ask someone to be secondary Wait for successful zone transfer Report the NS records to parent Wait for acknowledgement

Configure primary server ns1.example.com. 192.168.1.1 example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Ask someone to be secondary ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. IN NS ns1.example.com. ns1.example.com. IN A 192.168.1.1 example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Wait for successful zone transfer example.com. AXFR example.com. zone ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 Zonetransfer ok! example.com. { type slave; master 192.168.1.1; } example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Report the NS records to parent example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns1.verisign.com. 10.1.0.1 ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.1; } example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Wait for acknowledgement example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 Ok! ns1.verisign.com. 10.1.0.1 ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.1; } example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Practice: Moving master server Set up new master Change old master to slave Ask secondaries to copy from new master Wait for successful zone transfer Talk with parent Wait for acknowledgement

Set up new master example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.1; } example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Change old master to slave example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.1; } example.com. { type slave; master 192.168.1.2; } example.com. IN SOA … example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net.

Ask secondaries to copy from new master example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. IN NS ns2.example.com. ns2.example.com. IN A 192.168.1.2 example.com. { type slave; master 192.168.1.1; } example.com. { type slave; master 192.168.1.2; }

Wait for successful zone transfer example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 Ok! example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.1; } example.com. { type slave; master 192.168.1.2; }

Talk with parent example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Wait for acknowledgement example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.net. ns1.example.com. IN A 192.168.1.1 ns2.example.com. 192.168.1.2 Ok! ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns1.example.net. 10.0.0.1 ns1.example.com. 192.168.1.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Practice: Moving slave server Set up new slave Mention this to master server admin Wait for acknowledgement Verify successful zone transfer Master admin must change zone content Master admin must talk with parent Wait for an acknowledgement

Set up new slave example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.net. 10.0.0.2 ns1.example.net. 10.0.0.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Mention this to master server admin example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.net. 10.0.0.2 ns1.example.net. 10.0.0.1 replaced by ns2.example.net. 10.0.0.2 ns1.example.net. 10.0.0.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Wait for acknowledgement example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.net. 10.0.0.2 Ok! ns1.example.net. 10.0.0.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Verify zonetransfer ok example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.net. 10.0.0.2 ns1.example.net. 10.0.0.1 Ok! Let’s see if this works… example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Mention this to master server admin example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.net. ns2.example.com. IN A 192.168.1.2 example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.net. ns2.example.com. IN A 192.168.1.2 Ok! ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns1.example.net. example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.net. ns2.example.net. 10.0.0.2 Zonetransfer ok! ns1.example.net. 10.0.0.1 example.com. { type slave; master 192.168.1.2; } example.com. { type slave; master 192.168.1.2; }

Wait for an acknowledgement example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.net. ns2.example.com. IN A 192.168.1.2 ns2.example.com. 192.168.1.2 ns1.verisign.com. 10.1.0.1 example.com. IN SOA … example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.net. ns2.example.net. 10.0.0.2 example.com. { type slave; master 192.168.1.2; } ns1.example.net. 10.0.0.1 Ok! example.com. { type slave; master 192.168.1.2; }

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Firewalls A few different problems: No ability to send DNS queries from inside to world Must use “Forwarder” or internal root server Some names should not be visible in the world Different responses depending on where the query comes from

Forwarder A DNS server which receives a query normally query root servers, and query recursively until response is gathered If the server do not have access to Internet, but a second server do, the second can act as a forwarder for the first The first server query the second with “Recursion Desired” flag turned on In many cases, this can be combined with using root servers, and is called “forward-first” or “forward-last”

Internal forwarding server External DNS Server Server With recursion OFF With recursion ON With recursion ON Internal DNS Server

Different responses In some software, one can have different versions of a zone which are used depending on things like What interface the query is arriving to What IP-address the query is sent from This is called “split-DNS”

Different responses Query from outside Query from inside DNS Server for zone Server Query from inside

Root Nameserver A DNS server need to be primed It has a list of nameservers for “.”, the root Or rather, it has a list of servers which knows the list of nameservers for “.” First thing that happens is that a DNS server query the list of servers for nameservers for root After that, the new list is used Because of this, IP-address of root server(s) is not changed, if possible

Internal root server In some cases, no access to Internet is allowed (or possible) For DNS to work, internal root servers are needed Configure as normal, with a primary server for “.” (the root zone) Set up at least 2 slave servers for this primary Use the 3 IP-addresses in a hint file for internal forwarding servers

Internal root Query from outside Query from inside Internal root forwarder Query from inside DNS Server for zone Server

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Delegation in in-addr.arpa on no-octet boundaries - 1(2) Say one have 192.168.1.16/28 192.168.1.16-192.168.1.31 Parent set up NS for delegation and CNAME at locations of PTR owner(s) some-domain. IN NS ns.example.com. 16.1.168.192.in-addr.arpa. IN CNAME 16.some-domain. 17.1.168.192.in-addr.arpa. IN CNAME 17.some-domain. : 31.1.168.192.in-addr.arpa. IN CNAME 31.some-domain.

Delegation in in-addr.arpa on no-octet boundaries - 2(2) Child set up zone according to parent instructions some-domain. IN SOA … some-domain. IN NS ns.example.com. 16.some-domain. IN PTR what1.example.com. 17.some-domain. IN PTR what2.example.com. : 31.some-domain. IN PTR what31.example.com.

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

Why is DHCP and DNS problematic together? DHCP imply hostname to IP-address mapping (and inverse) change over time When that mapping changes, DNS is to be updated Even if primary server is updated asap, there is delay Slave servers need to be updated Caching servers might cache records Note that TTL of zero is not recommended

Dynamic update A command (query type) in the DNS protocol which makes it possible to update the data in a primary server DNS Client (DHCP client and/or server) send a Dynamic Update to Primary Server(s) for zone(s) when the IP-address is changed for a host

Secure dynamic update Two different ways, TSIG and SIG(0) TSIG - Symmetric Encryption, Shared Secret Used by DHCP servers SIG(0) - Assymetric Encryption, public key in DNS itself as KEY record, and temporary SIG record in update Used by DHCP clients Interoperability test January 2002 and used during IETF in Minneapolis March 2002 show this is possible to deploy now http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

TSIG - Transaction Signatures TSIG is a new RR type, which is not to be cached Shared Secret and HMAC-MD5 hash used, and requires secure storage of shared secret Used between two parties which trust each other DHCP-server and DNS server Resolver and forwarding server Zone transfers

SIG(0) Signature sent together with update request Assymetric keys, and not symmetric RSAMD5, RSASHA1, DSA RSAMD5 recommended Requires public key in Zone itself As KEY record Requires private key available for client Used when client authenticates to server

Agenda Definitions Delegation Resolver Master and slave Configuration examples Firewalls Delegation on non-octet boundaries Dynamic update DNSSEC

DNSSEC, what does it do? Secure record sets so Resolver can verify that data is not changed during transfer Resolver can know the data comes from someone having access to private key for zone Note that it doesn’t matter where the records come from (including non-trusted caching servers)

DNSSEC, what does it not do? Secure transfer between two parties Encrypt data between two parties Authenticate resolver to server Explicitly allow “inheritance” to other PKI’s (for example IPSEC based transport security)

DNSSEC records SIG - Holds signature of one RR-Set KEY - Holds public part of key used to sign records NXT - Indicate for one owner what the next owner in the zone is, in alphabetical order DS - Indicates in Parent Zone what key is used to sign child zone

se a b ns ns Chain of trust Key se. you trust Signed by key se. Key a.se. b ns Signed by key a.se. Key b.a.se. ns Signed by key b.a.se.

EDNS0 A mechanism for sending pseudo records between client and server Client can announce to server for example maximum packet size accepted Extensible mechanism, not yet deployed, but possibly needed when DNSSEC and other mechanisms are used which require larger packet size

Presentation_ID © 2001, Cisco Systems, Inc. All rights reserved. 90 90 90