advanced dhcp and dns deploymentsd2zmdbbm9feqrf.cloudfront.net/2011/las/pdf/brknms-2640.pdf ·...

BRKNMS-2640

Advanced DHCP and DNS Deployments

Bernie Volz

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKNMS-2640 2

Introduction

This session describes the management of IP addresses (host and domain) names. We explain the functionalities of DHCP and DNS and how they collaborate to produce the foundation of a name and address management system. The recent developments in both areas will be touched as well. Finally we enumerate best practices for achieving reliability and security of both services.


Non-Information

Silence your phone, pda, pager, mp3 player…

At CiscoLive! your evaluation is extremely important

Please remember to wear your badge at all times

Please visit the World of Solutions

There is extra material in the appendix at the end of this presentation; the explanatory notes contain links to reference material; I tried to translate all acronyms

You can ask questions any time


Meet the Engineer

To make the most of your time at Networkers at Cisco Live 2011, schedule a Face-to-Face Meeting with top Cisco Engineers.

Designed to provide a "big picture" perspective as well as "in-depth" technology discussions, these face-to-face meetings will provide fascinating dialogue and a wealth of valuable insights and ideas.

Visit the Meeting Centre reception desk located in the Meeting Centre in World of Solutions.


What You Will Learn

Managing addresses with DHCP

•Concepts, protocols

•Scale & Reliability

•IPv6

Coordination between DNS and DHCP services

Providing reliable and secure name and address services

Dynamic Host Configuration Protocol – DHCP

• DHCP Scale Considerations

• DHCP Reliability Considerations

• IPv6 and DHCP

• Domain Name System – DNS

• Interaction Between DNS and DHCP


Managing the DHCP Server

Server configured with:

Network design (Layer 3): network segments, subnets, relay agents

Available addresses

Rules about address allocation

Network administrator controls DHCP service

Policies for hosts or groups of hosts

Specific configuration parameters

Which hosts to serve

DHCP Server Acts as Agent for Network Administrator


DHCP Leases Network Configuration

Administrator creates pools of addresses available for assignment to hosts

Server dynamically assigns IP address on demand with a lease time attribute

Client can ask to extend lease time

Server may reassign address after lease expires

DHCP delivers other configuration information in options

Here is Your Configuration:IP Address: 192.168.18.7Subnet Mask: 255.255.255.0Default Routers: 192.168.18.1, 192.168.18.3DNS Servers: 192.168.1.8, 192.168.1.9Lease Time: 5 days

Send My

Configuration

InformationDHCP

Server

DHCP

Client


Server 1 Client Server 2

Basic DHCP Message Exchange

Client broadcasts DHCPDISCOVER message on local subnet

Servers send DHCPOFFER messages with lease information

Client selects lease and broadcasts DHCPREQUEST message

Selected server sends DHCPACK message


Client Server

Refresh Lease Sequence

At 50% of lease time, Client refreshes lease and unicasts DHCPREQUEST message.

Selected server sends DHCPACK message, extending the lease.

If server sends a DHCPNACK, the client restarts the full lease cycle (previous slide).

If no answer, the lease stays valid until lease time expires and client should retry.

• Dynamic Host Configuration Protocol – DHCP

DHCP Scale Considerations


• IPv6 and DHCP




DHCP Relay

Agent

DHCP Relay

Agent

DHCP

Server

DHCP Server

Distributed DHCP Service

DHCP Server

Centralized DHCP Service

Pro: Centralized

Management

Pro: Reliability

Through

redundancy

Architectures for DHCP Service (1)


DHCP Server

Server Wireless APSensorCamera Printer

The Cisco IOS DHCP Server at Work

Static DHCP client : per port or per Client-id or MAC address

Range per type of clients (PC, sensor, etc.)

Secures the LAN by coupling DHCP lease to ARP cache

Manage your pools with syslog on threshold, MIB, and accounting

Update the upstream DNS server from DHCP bindings


Architectures for DHCP Service (2)

DHCP Server

Redundant DHCP ServiceHybrid DHCP Service

Pro: Independent

Operation of

Remote Site if

WAN Link Fails Pro: Reliability

Through Redundancy

with Failover

Remote

Site

DHCP

ServersDHCP

Server

DHCP Relay

AgentsDHCP Relay

Agent

DHCP Relay

Agent


Best of Both Worlds

DHCP Server

Hybrid DHCP Service

Remote

Site

DHCP

Servers

DHCP Relay

Agents

Delegation


Automating Address Pool Assignment

IPv4 has limited addresses in each subnet

DHCP service must be configured with pools of available addresses

ODAP allows dynamic reallocation of address pools

DHCP extensions for dynamic pool assignment

Dynamic allocation of subnet(s) to DHCP pool configured on network element

Automatic insertion of summarized route to appropriate routing table for allocated subnet

Hierarchical DHCP

Improves efficiency of DHCP address assignment by moving available addresses to meet demand


DHCP Relay

Agent

DHCP Relay

Agent

Slave Servers

IOS Slave Servers

For Millions of Subscribers

Redundant Master Servers

Delegation


Cisco Network Registrar Local clusters - Standards-compliant DNS,

DHCP, and TFTP services for IPv4 and IPv6

Regional cluster - Central Configuration and Monitoring

Fast and ScalableDistributed architecture, supports millions of subscribers in some of the largest deployments in the world

Extensible and CustomizableSoftware hooks that let administrators intercept protocol messages and extend server behavior

Easy to IntegrateAPI, CLI, and SNMP to facilitate automation and control

Highly-AvailableDHCP failover (v4)

HA-DNSLocal

Cluster

Backup

Cluster

Local

Cluster

Backup

Cluster Local

Cluster

Backup

Cluster

Regional Cluster



DHCP Reliability Considerations

• IPv6 and DHCP




Reliable DHCP Service

Problem: provide increased reliability for DHCP service through redundancy

Solution: deploy multiple DHCP servers and enable all servers to respond to messages

DHCP client broadcasts messages, and relay agent can forward to multiple servers, so more than one DHCP server may receive messages from clients

DHCP client is required by protocol specification to be able to receive responses from multiple servers

DHCP client broadcasts rebinding request, so it can locate secondary server if primary is not accessible


But Independent Servers have Issues

Requires much more address space (2 times)

If original server is down when client re-connects or during renewal process:

Client must change address (remaining server has different address space)

Original server‘s lease still marked as in use until it expires as it doesn‘t know client has changed addresses

If DNS is updated, both addresses in DNS

If leasequery done, both servers might respond with active lease information


Better if Servers Shared State

Servers notify each other of assignments

If assigning server fails, other server(s) will have a record of the assignment and can respond

However, notification may take some time

DHCP specification does not allow sufficient time to do update before responding

Most hosts will timeout and retransmit before the interserver update completes

Therefore, server can‘t wait for update to complete before sending response


Solution …. DHCP Safe Failover

Main DHCP Server

Backup DHCP Server

Backup Address Pool192.168.18.151-200Main Address Pool

192.168.18.101-150


Safe Failover Requirements and Goals

Requirements

Compatible with RFC 2131 clients

Provide for coordination between servers not located on the same subnet

No duplicate IP address assignment when one server fails

Goals

Client keeps existing address if communicating with either server

Client can get new address from either available server

Server can recover lost database from other server


Failover With Both Servers Operational

1. DHCPDISCOVER

2. DHCPOFFER

Any Address Between 1-200

Client

Main

Backup

Address Pool:

10.10.10.1-254

Backup Pool: 201-254

4. DHCPACK


5. DHCPBNDUPD

6. DHCPBNDACK

Shhhhh

Main Pool:

1-200


Failover When Only Backup Operational

1. DHCPDISCOVER

Main

Backup

Address Pool:

10.10.10.1-254

Backup Pool: 201-254

Backup Uses Backup Pool for New

Clients

2. DHCPOFFER


DHCPPOLL

COMMUNICATIONS-

INTERRUPTED STATE

Client

Main Pool:

1-200


Lazy Update and MCLT

Safe Failover does not require the server to update partner before responding

However what if this update fails to happen because the server goes ‗down‘?

Partner has no record of lease or lease extension

How does partner know when it is safe to (re)use the lease?

MCLT – maximum client lead time

Limits the time ―in advance of what the partner knows‖ for any lease time assignments/extensions

As MCLT time is usually ‗short‘ (60 minutes), how do clients get long lease times?


Lazy Update Message Traffic

Client

1. DHCPDISCOVER

3. DHCPREQUEST

2. DHCPOFFER

4. DHCPACK

Lease time = MCLT =Y

MainBackup

(Within a short time)

5. DHCPBNDUPD

Lease Time = X+(Y/2)

24+(1/2) hours = 24.5

6. DHCPBNDACK

X = Desired Client Lease Time (Option 51)

Assumed to be 24 hours

Y = Maximum Client Lead Time

Assumed to be 1 hour

/2 = Client renewal time is 50% of lease time

8. DHCPACK

Lease time = X

(About 30 minutes later)

7. DHCPREQUEST

(Within a short time)

9. DHCPBNDUPD

Lease Time = X+(X/2)

24+(24/2) hours = 36

10. DHCPBNDACK




IPv6 and DHCP




IPv6 Introduction

Functionally similar to IPv4

Connectionless network-layer protocol

Used by transport protocols (TCP and UDP)

Runs over all possible hardware technologies

But:

Larger addresses

Completely new datagram header format

Fewer fields in header

Option headers follow main header


Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

IPv4 Header IPv6 Header

Fields Name Kept from IPv4 to IPv6

Fields Not Kept in IPv6

Name and Position Changed in IPv6

New Field in IPv6

Legend

20 Bytes

40 Bytes

IPv4 and IPv6 Header Comparison

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address


IPv6 Addresses

Divided into two conceptual parts (like IPv4)

Prefix

Globally unique

Assigned to a link

Known as link address or link prefix

Suffix

Only unique within a link

Assigned to an individual interface

Known as interface identifier


Address Assignment

Manual

DHCPv6

Stateless address auto-configuration; host:

Derives EUI-64 interface identifier from MAC address

Constructs address from prefix advertised by router and EUI-64 interface identifier

Performs duplicate address detection to confirm address is not already in use

2001:DB8:3:0:Prefix from RA:

MAC Address from Interface:

214:51ff:fed9:a45a

00:14:51:d9:a4:5a

2001:DB8:3:0::/64


Improvements in DHCPv6 over DHCPv4

L3-only transport

Link-local addressing between client and server (or relay agent)

No need for all-zeros IP source address

Assignment of multiple addresses to a client

Unique, uniform client identification

Explicit lease renewal and lease rebinding messages

Larger option code space (16-bit option code)

Most information carried in options (instead of fixed header fields)

Relay agent ―chaining‖ through message encapsulation

Server message to force client reconfiguration


Motivation for DHCPv6

Doesn‘t stateless address auto-configuration eliminate the need for DHCPv6?

No

Some organizations want to control and monitor the IPv6 addresses in use on the network

Stateless provides no means to differentiate hosts

Hosts need other information such as addresses of DNS servers, search lists, …

Routers and home gateways need prefix delegation


Use as Default Router

Don’t Use DHCPv6

Link Prefix 1 – Use SLAAC

Link Prefix 2 – Use SLAAC

Role of Routers in Host Configuration

Routers are configured with:

Whether to act as default router

Prefixes on each link

Whether hosts should use DHCPv6 (M/O bits)

Routers send router advertisement messages with list of prefixes and signal for use of DHCPv6


Theory and Practice of DHCPv6

Similar to DHCPv4

Many details differ

Allows assignment of multiple addresses to one interface

Performs prefix delegation

Uses IPv6 addressing modes, including link-local addresses and multicast

Logically independent from DHCPv4

May be implemented in same server process

May share interfaces


DHCPv4/DHCPv6 Coexistence

IETF design decision: DHCPv4 and DHCPv6 are separate protocols

Different message formats

Different message exchanges

Separate options

Host runs DHCPv4 and DHCPv6 as separate functions

What about options that provide same information in DHCPv4 and DHCPv6; e.g., DNS servers?


Server 1 Client Server 2

Basic DHCPv6 Message Exchange

Client multicasts SOLICIT message on local subnet

Servers send ADVERTISE message with lease information

Client selects lease and multicast REQUEST message

Selected server sends REPLY message


Client Server

DHCP Transport over IPv6

DHCPv6 uses Layer 3 delivery by using link-local addresses

Client transmits messages with:

Layer 3:

All_DHCP_Relay_Agents_and_Servers dest

interface link-local source

Server responds with:Layer 3:

client link-local dest

server link-local source

L3 dst=FF02::1:2

src=FE80::214:51ff:fed9:a45a

L3 dst=FE80::214:51ff:fed9:a45a

src=FE80::214:51ff:fe65:7413


Stateless DHCPv6

Used in conjunction with stateless address auto-configuration

DHCPv6 server does not need to retain state for each client; e.g., assigned addresses, lease state

Client uses stateless DHCPv6 (RFC 3736) to obtain configuration information

Very simple protocol server; can be easily deployed in routers rather than as centralized service


IPv6 Deployment Model for SOHO

IPv6 has enough prefixes to assign a prefix to every service provider subscriber or branch office

Subscriber network will have IPv6 router (instead of computer or NAT) connected to service provider

DHCPv6 prefix delegation informs subscriber router of prefix to use

Assignment of a prefix to a subscriber or an organization, rather than a single address, is recommended for IPv6

IPv6 prefix delegation uses DHCPv6 to provision a router with the prefix to be used at that site

Site router then assigns /64 prefixes from delegated prefix to each link in the site network


CMRouter

Service Provider Admin Domain

Customer Admin Domain

Home Network

CMTS Router

Servers

• DHCP, DNS

• TFTP

• TOD

• Management

CNR

CNR

BAC

BAC

To Internet

Home IPv6 Network Model (Cable)

HFC Link: Assigned 2001:DB8:FFFF:0::/64 (mgmt) and 2001:DB8:FFFE:0::/64 (Service)

Customer Home Network Link 0 (Wireless): Assigned 2001:DB8:0:30::/64

Customer Home Network Link 1 (Bridged): Assigned 2001:DB8:0:31::/64

Customer Home Network Link 2 (ZigBee): Assigned 2001:DB8:0:32::/64

WirelessAccess Point

• CM Router initiates DHCPv6 after receiving RAReceives IPv6 address for HFC link

Receives 2001:DB8:0:30::/60 (prefix delegation)

Receives list of DNS servers and other configuration

CM Router must have stateful firewall

• CM Router assigns /64 prefixes from 2001:DB8:0:30::/60 to customer network links

EthernetBridge

CoreHFC

ZigBee


IPv6 Deployment Model for Branch Office

IPv6 prefix can be assigned to enterprise branch office

Branch office gateway router provides IPv6 service to branch office network

DHCPv6 prefix delegation informs branch office router of prefix to use

Branch office router assigns /64 prefixes from delegated prefix to each branch office network link

Add interface index to /48 prefix to generate /64 for each link

Delegated prefix 2001:DB8:3::/48 and assign prefix 2001:DB8:3:1::/64 to interface 1


Branch Office IPv6 Network Model

Branch Office Network

Servers

• DHCP

• DNS

• Management

Core

BranchRouter

Router

• Branch Router initiates DHCPv6

Receives IPv6 address for enterprise net link

Receives 2001:DB8:3::/48 (prefix delegation)

Receives list of DNS servers and other configuration

• Branch Router assigns /64 prefixes from 2001:DB8:3::/48 to branch office network links

Enterprise Network Link: Assigned 2001:DB8:FFFF:0::/64

Branch Office Link 0 (Wireless): Assigned 2001:DB8:3:0::/64

Branch Office Link 1 (Desktop): Assigned 2001:DB8:3:1::/64

Branch Office Link 2 (Data Center): Assigned 2001:DB8:3:2::/64


Routing and DHCPv6 Prefix Delegation

Prefix delegation requires routing updates in delegating router and requesting router

Injection of routing information for delegated prefix

Determination of default router

DHCPv6 snooping typically used

DHCPv6 leasequery (RFC 5007 and 5460) allows requesting router to obtain information about delegated prefixes from DHCPv6 server


Domain Name System – DNS

• DNS Deployment

• DNS Service Security



Names

org

(root)

bucknell

edu

purdue

cswww

example

com

.

com.

example.com.

www.example.com.


The Domain Name System (DNS)

DNS is a distributed database, with distributed administration and responsibility

The database key is a Fully Qualified Domain Name(FQDN) that consists of a string of tokens separated by ―.‖

Example : www.cisco.com

The data is stored in Resource Records (RR) of which there are many types, examples are A, AAAA, PTR and MX.

Product of the IETF to replace original HOSTS.TXT file


DNS Features

The DNS is designed for look-up queries

The DNS holds two major types of information

The actual data available as answers to queries

Structural information for DNS itself

Information is logically grouped in zones; a zone is the unit of control, modification rights and replication operations apply to zones


Data in the DNS Namespace Database

Each FQDN in the namespace has one or more RRs containing the data associated with the FQDN

A RR consists of a left- and right-hand side

Left hand side = FQDN/owner (lookup key)

Right hand side = type of record and data

FQDN TTL CLASS TYPE VALUE

www.example.com. 1800 IN AAAA 2001:DB8:1:1::22www.example.com. 1800 IN A 192.168.50.22

Many RR types: MX, CNAME, PTR


Queries

Lookup is based on FQDN, class, and type

Query for example.com

example.com. ? IN A ?

example.com. 4711 IN A 192.168.1.1


DNS is a Universal Lookup Service

Lookup by name to find IPv4 address(es)www.l.google.com: type A, class IN, addr 64.233.169.147

www.l.google.com: type A, class IN, addr 64.233.169.105


xn--9n2bp8q.xn--9t4b11yi5a : type A, class IN, addr 199.7.85.16

Lookup by name to find IPv6 address(es)ipv6.l.google.com: type AAAA, class IN, addr 2001:4860:b004::68

Lookup by name to find mail server(s)cisco.com: type MX, class IN, preference 10, mx sj-inbound-b.cisco.com

cisco.com: type MX, class IN, preference 15, mx rtp-mx-01.cisco.com

cisco.com: type MX, class IN, preference 25, mx syd-inbound-a.cisco.com

Lookup by IPv4 address to find domain name25.219.133.198.in-addr.arpa: type PTR, class IN, www9.cisco.com



Lookup by service to find host and port_sip._tcp.example.com: type SRV, class IN,

priority 0, weight 10, port 5060, host sip.example.com

Lookup by name to find servicesexample.com: type NAPTR, class IN, 1 1 "s" "" "" _sip._tcp.example.com

example.com: type NAPTR, class IN, 1 1 "s" "" "" _clip._tcp.example.com

example.com: type NAPTR, class IN, 1 1 "s" "" "" _wins._tcp.example.com

Lookup by E.164 number to find URL or URN5.4.3.2.1.e164.arpa.: type NAPTR, class IN, 1 1 "u" "E2U+sip"

"!.*!sip:[email protected]!" .



Lookup by name to find the real name of the address

www.google.com: type CNAME, class IN, cname www.l.google.com



ipv6.google.com: type CNAME, class IN, cname ipv6.l.google.com

ipv6.l.google.com: type AAAA, class IN, addr 2001:4860:b004::68

Lookup by zone name to find name servercisco.com: type NS, class IN, ns ns1.cisco.com

cisco.com: type NS, class IN, ns ns2.cisco.com

Lookup by zone name to find Start of Authoritycisco.com: type SOA, class IN, mname dns-rtp2-3-l.cisco.com …


Reverse Zone

PTR records used to resolve name for an IP address

Canonical representation of IP address used as FQDN

IPv4—―reversed‖ dotted decimal concatenated with IN-ADDR.ARPA. (for

address 192.168.50.22)

22.50.168.192.in-addr.arpa 1800 IN PTR www.example.com

IPv6—―reversed‖ dotted hexadecimal nibbles concatenated with IP6.ARPA. (for address 2001:db8:1:1::22)

2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 1800 IN PTR www.example.com

Zone delegations based on address-FQDN components; gets tricky when delegations are not on FQDN component boundaries

http://www.example.com/

http://www.example.com/


Internationalized Domain Names (IDN)

According to Global Reach at www.glreach.com

60 percent of Internet users are non-English speakers, while the dominant language used on the Internet is English

Enter the URL http://실례.테스트

This is “example.test” in Korean Hangul script

result = query for xn--9n2bp8q.xn--9t4b11yi5a

See also RFC 3490


IDN

http:// إختبار .مثال

“example.test” in

Arabic script


Domains and Zones

All nodes below a node are included in the same domain

Nodes are grouped in administrative zones

Each node can be the start of a new zone, but it doesn‘t have to be

A node which is the start of a new zone is called a ―delegation point‖

root-zone

bucknell

example.com-zone

com-zone

purdue.edu-zone

com-domain

Zone

Domain

edu

purdue

cswww

example

com org


A DNS Server performs two functions

Hosts must be able to query FQDNs of the entire DNS namespace

Recursive servers provide resolution service

Hosts and recursive servers must be able to issue DNS queries about zones you administer

Authoritative servers respond to queries for FQDNs under their authority

Recursive

Server

Internetcom Name

Server

example

Name Server

FQDN ResolutionRoot

Server

DNS Database

Application

Stub

Resolver


DNS Name Resolution

1. An application wants to resolve www.widgets.example.com into an IP address

2. Stub Resolver code (typically in a library on the host where the application runs) sends a DNS protocol request message to (local) recursive server

3. Recursive server sends DNS protocol request messages to many DNS name servers; the recursive server may cache the answers

4. Recursive server returns IP address to stub resolver through a DNS protocol message

5. Stub resolver communicates IP address to application

Recursive

Server

Internet

com Name

Server

example

Name Server

1.2.3.4

Root

Server

DNS Database

Application

Stub

Resolver

Widgets

Name Server

1

2

43

5

www.widgets.example.com ?

http://www.widgets.example.com/


Recursive Resolution

1. Question = resolve www.widgets.example.com In the DNS protocol the question will always be the same.

2. Ask root server(s) (known via hint list); they will only answer which server(s) know com. which is likely a top level domain (TLD)

3. Ask server(s) for com.; they return a NS list that know about example.com.

4. Ask server(s) for example.com.; dependent on how the zones are laid out they might return the answer for www.widgets.example.com or else return a NS list that know about widget.example.com.

5. Finally the widget.example.com name server returns the answer

com

Name Server

example.com

Name Server

Root Server

DNS Database

Widgets.example.com

Name Server

www.widgets.example.com ?

NS for com = a, b, c

NS for example.com = x, y

NS for widgets.example.com = m, n

www.widgets.example.com = 1.2.3.4




Resolution Details

Recursive server provides complete resolution

Recursive server follows pointers to contact next name server to work it‘s way through the components from right to left

Delegation = name servers return pointers to next name server(s)

Optimization through caching

Recursive servers cache results of name resolution

Subsequent requests are resolved through local cache

Authoritative servers control time of caching through TTL

Negative caching (saving information about non-existent records) is required by RFC 2308



DNS Deployment What – Where – Why?




Deploying Authoritative Servers

Use a hidden primary or gold master

It will make authorization of changes easier

Slave servers answer all requests authoritatively, they obtain info only from the master

Close to your own hosts

In your DMZ, reachable from outside

At least one slave somewhere else on the Internet

This gives responses when your own slaves are not reachable


Detailed Network [Enterprise] Layout

192.168.17.53

192.168.2.2

192.168.33.3

192.168.33.4-6

1.168.51.15

Router A

Router B

Router C

+ firewall

Router D

+ firewall

+ NAT

Hidden Master

= Authoritative

Internal Cache

= Recursive

DMZ Cache

= Recursive

External Slave

= Authoritative

Internal DMZ External

DMZ Slave

= Authoritative

Internet

192.168.1.2Internal Cache

= Recursive

Internal Slave

= Authoritative

192.168.3.5


Queries from the Inside

Hidden Master

= Authoritative

Internal Cache

= Recursive

DMZ Cache

= Recursive

External Slave

= Authoritative


DMZ Slave

= Authoritative

Internet

Internal Cache

= Recursive

Internal Slave

= Authoritative


Zone Transfers Update the Slaves

Hidden Master

= Authoritative

Internal Cache

= Recursive

DMZ Cache

= Recursive

External Slave

= Authoritative


DMZ Slave

= Authoritative

Internet

Internal Cache

= Recursive

Internal Slave

= Authoritative


Queries from the Outside

External Slave

= Authoritative


DMZ Slave

= Authoritative

Internet


Queries from Subscribers


DMZ Slave

= Authoritative

Internet

Access

Network



• DNS Deployment

DNS Service Security



Security Exposures in DNS

1. Corruption of name server database: DDNS, admin spoofing

2. False zone transfers

3. Spoofed responses to recursive server queries

4. Spoofed responses to stub resolver queries

Recursive

Server

Internet

com

Server

widgets

Name Server

example

Name Server

(Master)

FQDN Resolution

example Name

Server (Slave)

example

Name Server

(Database)

Root

Server

Application

Stub

Resolver 4

2

1

3


TSIG, SIG(0), and DNSSEC

TSIG: uses shared secret key to protect DNS transactions

Sender computes hash of transaction using secret key

Received confirms integrity using secret key

SIG(0): uses public/private key pair to protect DNS queries

Sender computes signature of transaction using private key of public/private key pair

Receiver confirms authenticity using public key

DNSSEC: uses signed RRset to protect DNS data

Sender computes signature of RRset using private key of public/private key pair

Receiver confirms authenticity using public key


Securing Database Updates

Administrative security policies and mechanisms—don‘t let the bad guys access the database

TSIG between DNS components that are part of same administrative organization and that can share a private key

Zone transfers

Resolution requests/responses between stub resolver and recursive server


DNSSEC Detects Spoofed Responses

DNSSEC used to prove response comes from zone owner

Zone owner adds to the RRset a RRSIG containing signature using private key of public/private key pair for that zone

Resolver authenticates signature using matching public key

RRset with signatures can be forwarded and cached

www.example.com

Has Address…

Signature

Key for example.com

A Resolver That Trusts

This Public Key…

…Can Use This

Signature…

…to Verify

This Data


www.example.com

Has Address…Signature

Key for

example.com

example.com Key

Has Signature…Signature

Key for com

But…How Does the Resolver Get the Key for example.com?

Three new RR types used to store cryptographic data

DNSKEY—holds public key

DS—holds public key hash for a subzone

RRSIG—holds RRset signature

(There are 3 other RRs: NSEC, NSEC3, NSEC3PARAM)

Hash of public key for example.com is stored in a DS RR in the com zone; public

key is stored in a DNSKEY RR in the example.com zone

Resolver with public key for com

Uses public key for com to authenticate signature of DS RR for example.com

Retrieves public key for example.com in DNSKEY RR

from example.com zone and authenticates with DS RR

Resolves www.example.com and authenticates RR(s)

with key from example.com DNSKEY RR

Signature


Global view of signatures and keys

FQDN CL TYPE RDATA

com. IN DNSKEY xyz23Cryryptogrm4d3DS

example.com IN RRSIG

DS

Signature of DS

Hash for public key of

example.com

example.com IN DNSKEY 3245sdFD56G4ggf15R5

www.example.com IN A

RRSIG

64.64.64.64

Signature for RR

co

m.

zo

ne

exa

mp

le.c

om

. z

on

e

means ―authentified by‖means ―used to validate‖


Why Aren’t We Using DNSSEC Today?

Requires chain of signed zones

Root TLDs organizations

Trust islands may be an interim step

Processes for key and trust anchor management and rollover need to be worked out

Organizations need to get keying information into TLDs

RFC 5011 mechanisms need to be deployed for trust anchors

Applications are unprepared for DNSSEC

How does an application react to an unsecured response or a response that fails authentication?

Organizations need to deploy DNSSEC

Name servers; recursive servers

…with a mechanism for securing DNS traffic between hosts and recursive servers

Root zone has been signed since July 15, 2010 …

Good information source - http://www.dnssec-deployment.org/

http://www.dnssec-deployment.org/




Root

Zone

com

Zone

example.com

Zone

Trust Island for DNSSEC

Resolver can be configured with public key for example.com zone

Resolver performs unsecured resolution through root and com zones

Then, resolver applies example.com zone key for secure resolution of example.com zone

Resolver

Example.com Zone

Public Key



Interaction Between DNS and DHCP


DNS Namespace and IP Addressing

DNS namespace and IP addressing architecture are fundamentally orthogonal

Name hierarchy need not follow network topology; two devices on the same link may use different domain names

Address assignment must follow network topology, so an address assigned to a device must come from a prefix assigned to the link

… but name and address management interact in several ways

IP addresses in PTR records

Configuration of host to know DNS servers (evaluation order)

Configuration of host for evaluation order

Reverse delegation—Delegation of IP addresses implies delegation of zone authority


Address Assignment and DNS

RRset(s) for a device must be updated with address(es) assigned to the device

IP addresses in A/AAAA RRs for the device‘s FQDN

must reflect the IP addresses assigned to the host

Static: simultaneously add entries to DHCP and DNS services

Automatic: simultaneously add entries when address is first assigned

Dynamic: add entries when address is first assigned; update RRs if address changes; delete RRs if lease expires


Getting New IP Addresses into DNS

Update DNS server database manually

Edit configuration file

Through a GUI

(Dynamic) DNS Update (DDNS) from host

Host sends DNS Update when new address is assigned

What name to use/allow?

Update both forward and reverse?

Authentication and authorization requires trust relationship with each host; does this scale?

What if the DHCP address lease expires?


Getting New IP Addresses into DNS

DNS update from DHCP server

DHCP and DNS servers must have a trust relationship; fewer components to secure

Can purge expired address

Requires explicit collaboration if DHCP and DNS servers are in different admin domains

Only works for addresses assigned through DHCP

DHCP

ClientDHCP Relay

Agent

Organization

Network

DHCP

Server

DHCP Client DHCP Service

example

Name Server

com Name

Server

widgets Name

Server

DNS Database

Root

Server

bvolz.widgets.example.com

DNS update for

bvolz.widgets.example.com


Why Use DNS Update?

Mobility is easier

Laptops are not the only devices that uses IP addresses and need domain names

Platform and proprietary solutions have existed, but a standardized version was missing

Fast, secure updates of the DNS are required

DNS Update provides mechanism in DNS to update RRs

Can be secured (i.e., TSIG)

Used by host (with appropriate trust and security)

Used by DHCP server (for reverse and perhaps forward)


Update of PTR Record

PTR records should be updated at same time as A (and AAAA) when addresses are changed

If addresses are assigned through DHCP, the network admin ―owns‖ the address (reverse zone) and should have the DHCP server do the update

DHCP server can learn host FQDN through DHCP options or can enforce its own naming policy

If client‘s name used, assumes implicit trust relationship between host and DHCP server - host is authorized to use name

Explicit authentication of host identity and authorization of host to use name and authentication of DHCP message exchange is an unsolved problem


DHCP

Server

Organization

Network

DHCP Client DHCP Service

example Name

Server

com Name

Server

widgets Name

Server

DNS Database

Root

Server

router.widgets.example.com

DHCP

Client

*RFC 4702 DHCP client FQDN option

Cisco IOS DHCP Client and Server Running DDNS

The Cisco IOS DHCP client can perform DNS* or HTTP updates and use client FQDN option to communicate choice to the DHCP server

The Cisco IOS DHCP server can perform DNS* or HTTP updates and uses or override client preference


Configuration of Host for DNS

Obtaining pointers to DNS service is almost as important to host operation as obtaining an IP address

DHCP service can be (and usually is) configured to pass information about DNS to the DHCP client via DHCP options

Addresses of recursive servers

List of domain names for FQDN resolution




• IPv6 and DHCP


• DNS Deployment




NMS sessions offered (1 of 2)

Session Title

Monday:

BRKNMS-1204

Introduction to Network Performance Measurement with Cisco IOS

IP Service Level Agent

BRKNMS-2032 Rapid and Repeatable Service Delivery Through Automation

BRKNMS-3021 Advanced Cisco IOS Device Instrumentation

Tuesday:

BRKNMS-1032 Network Management KPI's

BRKNMS-1532 Introduction to Accounting Principles with NetFlow and NBAR

BRKNMS-2010 Using a Network Hypervisor to Build Public and Private Clouds

BRKNMS-2031 SYSLOG Design, Methodology and Best Practices

BRKNMS-2035 Ten Cool LMS Tricks to Better Manage Your Network

BRKNMS-2501 Enterprise QoS Deployment, Monitoring and Management


NMS sessions offered (2 of 2)

Session Title

Wednesday:

BRKNMS-2031 SYSLOG Design, Methodology and Best Practices

BRKNMS-1942 Managing Infrastructure as a Service (IaaS) for Cloud Environment

BRKNMS-2499 Operating and Managing Converged Enterprise Architectures

BRKNMS-3043

Advanced Performance Measurement for Critical IP Traffic with

Cisco IOS IP Service Level Agreements

BRKNMS-3132 Advanced NetFlow

Thursday:

BRKNMS-2006 Energy Management

BRKNMS-2030 Onboard Automation with Cisco IOS Embedded Event Manager

BRKNMS-2640 Advanced DHCP and DNS Deployments

BRKNMS-2658 Securely Managing Your Networks and SNMPv3

BRKNMS-1035 The NOC at CiscoLive


Complete Your Online Session Evaluation

Receive 25 Cisco Preferred Access points for each session evaluation you complete.

Give us your feedback and you could win fabulous prizes. Points are calculated on a daily basis. Winners will be notified by email after July 22nd.

Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

Don‘t forget to activate your Cisco Live and Networkers Virtual account for access to all session materials, communities, and on-demand and live activities throughout the year. Activate your account at any internet station or visit www.ciscolivevirtual.com.

http://www.ciscolivevirtual.com/


Recommended Reading

The DHCP Handbook

Ralph Droms and Ted Lemon.

Sams Publishing, 2002. ISBN: 978-0-672-32327-3

Available Onsite at the Cisco Company Store


Recommended Reading

DNS and BIND

by Cricket Liu & Paul AlbitzO‘ReillyISBN: 978-0-596-10057-5

Available Onsite at the Cisco Company Store


Recommended Reading

IP Address Management Principles and Practice

by Timothy Rooney

ISBN 978-0-470-58587-0

Introduction to IP Address Management

by Timothy Rooney

ISBN 978-0-470-58588-7

http://www.amazon.com/Address-Management-Principles-Practice-Network/dp/0470585870/ref=sr_1_1?ie=UTF8&s=books&qid=1306371960&sr=1-1

http://www.amazon.com/Introduction-Address-Management-Press-Network/dp/0470585889/ref=sr_1_2?ie=UTF8&s=books&qid=1306371960&sr=1-2


Thank you.

Appendix A:Terminology, Acronyms, References


Terminology

Class A field in a DNS Resource Record that class field specifies the protocol group (usually IN for Internet)

DDNS A method for dynamic updates to DNS data through DNS messages

DHCP Server Responds to DHCP messages; manages IP address assignment and reclamation; assigns configuration information to hosts

DHCP Client Initiates DHCP message exchanges; implemented on a host to obtain an IP address and other configuration information for the host

DHCP Relay Agent A function of a network element like a router, that forwards DHCP messages between clients and servers and eventually modifies the messages

DHCPv6 PD Prefix delegation for DHCPv6; an extension to DHCPv6 that allows a DHCPv6 server to delegate prefixes to other DHCPv6 servers thus forming a delegation hierarchy

DNSSEC A method for securing DNS RRs using public/private keys and a trust chain to authenticate the public key


Terminology

Domain A subtree of the global DNS name space. Often used to refer to an organization‘s subtree, e.g., the ―MIT‖ domain, the ―ISI.EDU‖ domain, the ―root‖ domain

EDNS0 Updates to the DNS protocol, expanding several fields and allowing for longer UDP messages (RFC 2671)

FQDN Fully qualified domain name; the name of a node in the DNS name space

Link A communication facility or medium over which nodes can communicate at the link layer (RFC 2460)

Name Server A program that holds DNS data and answers queries

ODAP On Demand Address Pools; an extension to DHCPv4 that allows DHCP servers to assign and recover addresses in address pools

Prefix A bit string that consists of some number of initial bits of an address (RFC 2461)

Recursive Server A program that accepts a DNS resolution request from a host and exchanges DNS protocol messages to complete the name resolution


Terminology

Resolver A program that accepts DNS resolution requests from an application and initiates a DNS protocol message exchange

Root Server The name servers for the root of the DNS name space

RR Resource Record; the atomic unit of information in the domain system

RRset A set of all RRs associated with an FQDN and type

SIG(0) A method for securing DNS message exchanges using public/private keys (not in common use)

TLD Top level domain; e.g., .com, .edu, .org, .uk

TSIG A method for securing DNS message exchanges using a shared secret or GSS-API

TTL Time-to-Live – A field in a DNS Resource Record that specifies how long a domain resolver should cache the RR before it throws it out and asks a domain server again

Zone A zone is a portion of the DNS name space that is managed as a unit


DNS and the IETF

DNS is a product of the IETF; specifications are published in RFCs

Original specification: RFC 1034, RFC 1035

DNS dynamic updates (DDNS): RFC 2136

EDNS0: RFC 2671

DNS security

DNSSEC: RFC 4033, RFC 4034, RFC 4035, RFC 5155

SIG(0): RFC 2931

TSIG: RFC 2845

DNS extensions (dnsext) working group of the IETF continues to develop extensions to DNS

DNS operations (dnsop) working group develops guidelines for the operation of DNS software servers and the administration of DNS zones


IETF Standards related to DNS

RFC 974 (2821, 5321), 1034, 1035

RFC 1995 (Incremental Zone Transfer)

RFC 1996 (Notify)

RFC 2136 (Dynamic Update)

RFC 2782 (SRV Records)

RFC 2308 (Neg. Caching)

RFC 2317 (Classless in-addr.arpa)

RFC 2181(DNS Clarification)

RFC 2845 (Secret Key Transaction Authentication)

RFC 2915 (NAPTR)

RFC 3152 (Delegation of ip6.arpa)

RFC 3363 (Representing IPv6 Addr in DNS)


DHCP and the IETF

DHCP is a product of the IETF; specifications are published in RFCs

Work on DHCP began in 1990

Current specification published in 1997 as RFC 2131 and RFC 2132

Based on earlier protocol, BOOTP

Dynamic Host Configuration (DHC) working group of the IETF continue to develop extensions to DHCP

New options for services, location information, relay agents

DHCP for IPv6 (published as RFC 3315 in 2003)


Significant Extensions

Relay agent options (RFC 3046)

DHCP message authentication (RFC 3318, RFC 4030)

DHCP for IPv6 (RFC 3315) and DHCPv6 prefix delegation (RFC 3633)

Many new options, redefinition of option code space to allow for more DHCP options


IETF Standards

RFC 951 (Bootstrap Protocol)

RFC 1048, 1395, 1497, 1542, 2132 (BOOTP Vendor Info)

RFC 1534 (Interoperation Between DHCP and BOOTP)

RFC 2131 (Dynamic Host Configuration Protocol)

RFC 3004 (User Class Option for DHCP)

RFC 3011 (IPv4 subnet selection)

RFC 3046 (DHCP Relay Agent Information Option)

RFC 3074 (DHCP Load Balancing)

RFC 3256 (The DOCSIS Device Class DHCP Relay Agent Information Suboption)

RFC 3442 (The Classless Static Route Option for Dynamic Host Configuration Protocol [DHCPv4])

RFC 3495 (Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client)

RFC 3527 (Link Selection Suboption for the Relay Agent Information Option for DHCPv4)

RFC 3594 (PacketCable Security Ticket Control Suboption for the DHCP CableLabs Client Config [CCC])

RFC 3315, 3633, 3736 (DHCP for IPv6, Prefix option, Stateless DHCP for IPv6)

Appendix B: DHCP as an IP address management system


IPv4 Address Management

IPv4 address plan

Start with network link topology

Estimate hosts on each link

Pick IPv4 prefix length (subnet mask) to accommodate expected hosts

Assign IPv4 prefixes for aggregation

Can ―split‖ a prefix later when new links are added


Sources of Information About Networks

Network management tools should contain IP addresses in use, observed or planned

Router configurations provide

Interfaces for link topology

Assigned networks and subnet masks

Can be obtained with grep from Cisco® IOS®

egrep “^[ \t]ip address” *-confg |grep

“255\.255”

Can be queried using SNMP

snmpwalk {options} mib-2.ip.ipAddrTable


How Do You Count the Number Of Devices?

00:fa:66:ee:2e:8b:12:aa

00:fa:66:e1:2e:8b:52:aa

00:fa:66:e1:2b:8b:12:aa

00:fa:66:3c:2e:8b:12:aa

00:fa:88:e1:2e:8b:22:aa

00:fa:16:e1:2e:8b:12:aa

00:fa:61:e1:2e:8b:12:aa

f0:fa:66:e1:2e:8b:12:aa

0f:fa:66:e1:2e:8b:12:aa

00:fa:66:e1:2e:8b:12:aa

00:fa:66:e1:2e:8b:12:9a

00:fa:66:e1:2e:8b:12:ea

00:fa:66:e1:2e:8b:12:aa00:fa:66:e1:2e:8b:12:aa

00:fa:66:ec:2e:8b:12:aa

00:fa:66:e1:2e:8b:12:aa00:fa:66:e1:2e:8b:12:aa

00:fa:66:e1:2e:8b:12:aa00:fa:66:e1:2e:8b:12:aa

00:fa:66:e1:2e:8b:12:aa


Host Address Management

Address assignment

Manual

Static, automatic, dynamic => DHCP

Auto-configuration

DHCP service has to choose address from right prefix

Address plan configured into DHCP server

DHCP server identifies subnet to which client is attached from giaddr and chooses an address from the prefix for that link

DHCP server uses Option 82 to identify last mile copper pair and decides subnet for customer

Appendix C: DHCP Class of Service


Examples of Class of Service

Address leases—How long a set of clients should keep its addresses

IP address ranges—From which lease pool to assign clients addresses, example: walled garden

DNS server addresses—Where clients should direct their DNS queries

DNS hostnames—What name to assign clients

Denial of service—Whether unauthorized clients should be offered leases


How the Client Is Classified

MAC address

Link (=subnet) to which client is attached

Port to which client is attached

Device type: PC, IP phone, cable modem

Device status: unauthenticated/authenticated


DHCP Relay: Centralized DHCP Service

DHCP client broadcasts a DHCPDISCOVER packet

Relay agent on the router receives the message, fills in the ’giaddr’field with IP address of the receiving interface of router, and forwards it to the server

DHCP relay agent forwards (unicasts) the packet to multiple DHCP server ; client will choose the ―best‖ DHCPOFFER

DHCP server uses ’giaddr’ field

of DHCP packet as an index into the network topology and selects an address from 192.168.1.0/24

Network Prefix

192.168.1.0/24

Relay Agent

IP Address

192.168.1.1

DHCP

Client

Organization

network

DHCP Server

192.168.200.8

Network Prefix

192.168.2.0/24

Relay Agent

IP Address

192.168.2.1DHCP

Packet

GIADDR

Relay Agent

IP Address

192.168.50.1


Relay Agent Options

Relay agent can attach additional information to DHCP message in relay agent options

Originally defined in RFC 3046 for cable broadband

Option encodes information about source of DHCPDISCOVER or DHCPREQUEST MESSAGE

Server returns options back to relay agent, which uses information to forward message to cable modem client

Additional relay agent options encode information such as DOCSIS device class, subnet for address assignment


DHCP Server 192.168.1.5

DHCP Server 192.168.2.5

DHCP Client

DHCP Relay Options

DHCP

Request

GIADDR

Option 82

DHCP

Request

Option 82

DHCP

Request

Visit the Cisco Store for Related Titles

http://theciscostores.com

http://theciscostore.com/


Thank you.

advanced dhcp and dns deploymentsd2zmdbbm9feqrf.cloudfront.net/2011/las/pdf/brknms-2640.pdf ·...

Documents