1. 1 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. PE 3G/GPRS live access address: NAT64 NSP::/96 domain: “.nokia.com,.nsn.com” DNS WiFi access provider (by NTT) address: 2001:8000::/32 domain: “.wifi-access.com” [RA] 2001:8000:1000::/64 (SLLAC) [DHCPv6] DNS (specific selection rule) and IA_RT (specific route) options Web if0 (3G) if1 (WiFi) DHCPv6 server WiFi AP bridged mode 2001:8000::80 2001:8000::53 DNS64 DHCPv6 server NAT64 Internet [RA] for SLAAC and [DHCPv6] with DNS and IA_RT options Nokia Siemens Networks 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 Scenario B – see live demo Nokia N900 GGSN

8. 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-ietf- mip4-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

9. Proposal Adopt draft-savolainen-mif-dns-server-selection- 04 as MIF WG document (proposed standard)? 9