Transcript DNS Server Selection on Multi-Homed Hosts

Improved DNS Server Selection for
Multi-Homed Nodes
draft-savolainen-mif-dns-server-selection-04
Teemu Savolainen (Nokia)
Jun-ya Kato (NTT)
MIF WG meeting @ IETF#79
11-Nov-2010
1
Related MIF milestone




1) DNS server selection solution: a specification for describing a
way for a network to communicate to nodes information required to
perform advanced DNS server selection at name resolution request
granularity in scenarios involving multiple namespaces. The
specification shall describe the information to be delivered for
nodes and the protocol to be used for delivery.
With the exception of support for additional DHCP options in DHCP
servers, group shall not assume any software beyond basic IP
protocol support on its peers or in network nodes.
Jan 2011 Initial WG draft on advanced DNS server selection
solution
Nov 2011 Submit advanced DNS server selection solution to IESG
for publication as a Proposed Standard RFC
2
Recap on what this draft proposes




A new DHCPv6 option to inform nodes (hosts or
CPEs) about non-global namespaces a particular
DNS server has knowledge about
For deployments managing with relatively few and
carefully selected suffixes and prefixes (to keep
message size small enough)
Hosts need to look for each DNS query which DNS
server to send it
IPv4 is still not included - to be considered later
(should be very similar)
3
Changes since -03 (Maastricht) 1/2

Prefix/suffix field separation was removed, now prefixes for
reverse lookups are communicated using ”ip6.arpa”.
Preference bits added.
4
Changes since -03 (Maastricht) 2/2


Suffix ”.” is used to indicate capability to be a default
nameserver. Lack of ”.” means ”only specific”
Set of editorial updates




E.g. ”split DNS”/”private names” -> ”local namespaces”
Clarification that this document is often assumed to
be used with solutions delivering more specific
address selection policies / routes
Clarification that some of the hard problems in this
space require user intervention (manual selection of
a network interface to use)
Appendix A is now listing set of tools as ”BCP”
5
Bar BOF experieces from Monday



Host implementation done for Nokia N900, using
parallel live 3G network and WLAN, worked fine
(see next slide for details)
Successful IOP testing where N900, using
modified ISC DHCPv6 client, talked to ISC
DHCPv6 server on cellular access and modified
WIDE-DHCPv6 server on WLAN access
Two interoperable implementations (by
Nokia/NSN and NTT)
6
Scenario B – see live demo
3G/GPRS live access
WiFi access provider (by NTT)
address: NAT64 NSP::/96
domain: “.nokia.com, .nsn.com”
address: 2001:8000::/32
domain: “.wifi-access.com”
2001:8000::80
Internet
Web
2001:8000::53
DNS
NAT64
DNS64
Nokia
Siemens
Networks
DHCPv6
server
GGSN
PE
[RA] 2001:8000:1000::/64 (SLLAC)
[DHCPv6] DNS (specific selection rule)
and IA_RT (specific route)
options
WiFi
AP
[RA] for SLAAC
and [DHCPv6] with
DNS and IA_RT options
Host: modified Nokia N900 with ISC BIND
and modified ISC DHCPv6 client
GGSN: NSN Flexi-ISN
NAT64/DNS64: Viagenie Ecdysis
DHCPv6: Modified ISC DHCPv6 server
if0 (3G)
DHCPv6
server
bridged
mode
if1 (WiFi)
Nokia N900
Possible updates for next revision



Instead of multiple option instances change to use
suboptions similar to DHCPv6 IA_RT
Install specific route for each DNS server address to
ensure the DNS queries go out of right interface
Should the DNS suffix list be compressed, like
defined in RFC1035 section 4.1.4 or at draft-ietfmip4-nemo-haaro-02 section 4.2 (dictionary based)?


Savings would probably be quite small, but some
Decrease amount of text related to conflict
resolutions (security aspects), as that is more
generic problem than DNS server selection?
8
Proposal

Adopt draft-savolainen-mif-dns-server-selection04 as MIF WG document (proposed standard)?
9