150 likes | 295 Views
DNS Discovery. Dave Thaler Microsoft. Overview of design team recommendation. Transport Mechanism: Q: How do discovery messages get from devices to servers (if any)? A: Site-scoped anycast Content Mechanism Q: What’s the format of the discovery messages? A: DNS SRV lookups.
E N D
DNS Discovery Dave Thaler Microsoft
Overview of design team recommendation • Transport Mechanism: • Q: How do discovery messages get from devices to servers (if any)? • A: Site-scoped anycast • Content Mechanism • Q: What’s the format of the discovery messages? • A: DNS SRV lookups
Anycast deployment scenarios How do you securely inject anycast host route? • Run DNS servers on routers • Run routing daemons on DNS servers to talk to routers • Run multiple servers on same link, configure servers’ routers with static route • Upgrade servers’ routers to advertise route based on ND responses for anycast address • Develop a real host-router anycast group joining protocol (draft-haberman-ipngwg-host-anycast-00.txt)
Response Content Requirements • Response must be able to contain: • 1 or more DNS server addresses (ordered?) • Could just be the anycast address • Multiple addresses allow end nodes to more quickly fail over to other servers • Client’s domain name • Client’s search path (ordered) • Response must fit in 512 bytes
Other Requirements • Allow single config for entire site • Allow per-subnet config as an option • Request should include subnet information • Want a single request message • Implies a single query in practice
Anycast for name resolution • DNS server list MAY just contain the anycast address itself • Nodes just send UDP queries to the DNS server anycast address to resolve names • Deployment notes: • Already tried (w/o domain name or search path) • Trivial to obtain & maintain “server list”, but slower convergence time on server failure • Reply doesn’t come from request destination
Using DNS SRV messages • Resolver does a lookup using a well-known domain name and service name • IPNG WG will define details of how to embed necessary information in SRV records • Mechanism can be disabled using an existing flag in Router Advertisements that says to use DHCP for other configuration
SRV record basics • Specified in RFC 2782 • Record has format _Service._Proto.Name TTL Class SRV Priority Weight Port Target • Query for: _Service._Proto.Name • Example: _ldap._tcp.example.com • Priority field imposes an ordering • Weight field used for probabilistic load balancing within a priority • Target is a name
Example from RFC 2782 $ORIGIN example.com. ... ; foobar - use old-slow-box or new-fast-box if ; either is available, make three quarters of the ; logins go to new-fast-box. _foobar._tcp SRV 0 1 9 old-slow-box.example.com. SRV 0 3 9 new-fast-box.example.com. ; if neither old-slow-box or new-fast-box is up, ; switch to using the sysdmin's box and the server SRV 1 0 9 sysadmins-box.example.com. SRV 1 0 9 server.example.com. ; NO other services are supported *._tcp SRV 0 0 0 . *._udp SRV 0 0 0 .
Basic questions • What name do you ask for? • How do you do longest match, so that you get subnet-specific information if available, and site information otherwise? • How encode 3 types of information?
Proposal (Queries) • Well known (domain) Name (local.arpa?) • Well known Protocol: e.g. _dnsinfo • Don’t need to use this field for anything else • Allows use of Service field for longest match wildcarding • Put SLA in Service field of query • Example: • Client is on subnet fec0:0:1234::/64 • Query for _1234._dnsinfo.local.arpa
Proposal (Server config) • Use Port to encode type (e.g., 0=domain name, 1=search path, 2=server) • Use Priority to specify ordering within a type • Only server Targets need address records
Site-specific example $ORIGIN local.arpa. ... ; Specify default domain name *._dnsinfo SRV 1 0 0 seattle.example.com. ; Specify default search path *._dnsinfo SRV 1 0 1 seattle.example.com. *._dnsinfo SRV 2 0 1 example.com. *._dnsinfo SRV 3 0 1 foobar.com. ; Specify server list. Split among dns1-3 if ; available, else fall back to dns.foobar.com. *._dnsinfo SRV 1 1 2 dns1.example.com. *._dnsinfo SRV 1 1 2 dns2.example.com. *._dnsinfo SRV 1 1 2 dns3.example.com. *._dnsinfo SRV 2 0 2 dns.foobar.com.
Subnet-specific example ; Specify default domain name _1234._dnsinfo SRV 1 0 0 marketing.example.com. ; Specify default search path _1234._dnsinfo SRV 1 0 1 seattle.example.com. _1234._dnsinfo SRV 2 0 1 example.com. ; Specify server list. Split among dns1-3. _1234._dnsinfo SRV 1 1 2 dns1.example.com. _1234._dnsinfo SRV 1 1 2 dns2.example.com. _1234._dnsinfo SRV 1 1 2 dns3.example.com.
Conclusions • Can encode multiple types of information • Can support 2-level “longest” match • Site-specific and subnet-specific • No changes to existing DNS servers