I Presentation by ANML June 2004 N D I A N A U N I V E R S I T Y IPv6: DNS and Programming I N D About the Presenter I A N •Mark Meiss A • Academic Background: – B.S. Mathematics, B.S. Computer Science U N – Ph.D. student in Department of Computer Science I • Research interests: V – Structural analysis of network traffic data E – High-performance file transfer protocols R S – Autonomous information retrieval agents I T Y I N D About the Presenter I A N • Professional Experience: A – Over 10 years in software development U – With IU IT Services since 1997 N – Worked with Bloomington NOC I V – First employee of ANML E – Developed Animated Traffic Map, Router R Proxy, Tsunami file transfer protocol, etc. S I T Y I N D Overview I A N 1. DNS nameserver changes under IPv6 A • New resource types and compatibility issues U 2. DNS resolver changes under IPv6 N • Reasons for change and using the new I V interface E R S I T Y I N D DNS Nameserver Changes I A N A U N I V E R S I T Y I N D Review of DNS Operation I A N • Before we dig too deep, let’s review DNS A • The Domain Name Service is a distributed U database that maps from hostname to IP N address and vice-versa I – Includes a variety of record and query types V – We will focus on the most common queries: E • Hostname-to-Address (“forward lookup”) R • Address-to-Hostname (“reverse/inverse lookup”) S I T Y I N D Typical Forward Lookup I A N Joe User A Q: Address of MK.ULTRA.MIL? U N Joe’s Local I Nameserver V E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Typical Forward Lookup I A N Joe User A U N Joe’s Local I Nameserver V Q: Address of MK.ULTRA.MIL? E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Typical Forward Lookup I A N Joe User A U N Joe’s Local I Nameserver V A: Ask ULTRA.MIL server at 127.55.83.1 E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Typical Forward Lookup I A N Joe User A U N Joe’s Local I Nameserver V Q: Address of MK.ULTRA.MIL? E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Typical Forward Lookup I A N Joe User A U N Joe’s Local I Nameserver V A: MK.ULTRA.MIL is 127.55.83.50 E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Typical Forward Lookup I A N Joe User A A: MK.ULTRA.MIL is 127.55.83.50 U N Joe’s Local I Nameserver V E R Root ULTRA.MIL S Nameserver Nameserver I T Y I N D Zone Files I A N • Nameservers store DNS information in a set A of zone files, which contain resource records U N • Resource records map a name to a value I – A record: name to IPv4 address V – PTR record: IP address to name E R – CNAME record: alias to canonical name S – (and quite a few others…) I T Y I N D IPv4 A Records I A N A ; Part of ULTRA.MIL. Zone file U mk IN A 127.55.83.50 N I Hostname IPv4 Address V E Class Resource R (Internet) Record Type S I T Y I N D IPv6 AAAA Records I A N A ; Part of ULTRA.MIL. Zone file U mk IN AAAA 2004:5b::f23b:10ff:fe87:559d N I Hostname IPv6 Address V Resource E Class (Internet) Record Type R S I T Y I N D IPv6 AAAA records I A N • Straightforward extension of A resource A record from IPv4 to IPv6 addresses U • Defined in RFC 3596 N • Can coexist with A records defined for the I V same hostname E • …but this isn’t the whole story R S I T Y I N D IPv6 A6 Records I A N A ; Part of ULTRA.MIL. Zone file U mk A6 64 ::f23b:10ff:fe87:559d ultra-net ultra-net A6 16 0:5b:: mil-net N mil-net A6 0 2004:: I V Hostname Prefix Size Prefix Name E Resource IPv6 Address R Record Type S I T Y I N D IPv6 A6 Records I A N • Much more complicated than AAAA A • Defined in RFC 2874 U • Prefix delegation can introduce external N points of failure for every address lookup I V • Additional danger of delegation loops E R • Now relegated to experimental status and S may disappear I T Y I N D Typical Reverse Lookup I A N Joe User A Q: Host for 127.55.82.50? U Joe’s Local Nameserver N I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N Q: Hostname for 127.55.83.50? I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N A: Ask 127.* server at 127.1.0.4 I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N Q: Hostname for 127.55.83.50? I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N A: Ask 127.55.83.* server at 127.55.83.1 I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N Q: Hostname for 127.55.83.50? I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A U Joe’s Local Nameserver N A: 127.55.83.50 is MK.ULTRA.MIL I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D Typical Reverse Lookup I A N Joe User A A: 127.55.83.50 is MK.ULTRA.MIL U Joe’s Local Nameserver N I V Root 127.55.83.* Nameserver Nameserver E R 127.* S Nameserver I T Y I N D IPv4 PTR Records I A N A ; Part of 83.55.127.IN-ADDR.ARPA Zone file U 50 IN PTR mk.ultra.mil N I Last Byte Full Hostname V Class Resource E (Internet) Record Type R S I T Y I N D IPv6 PTR Records I A N ; Part of 0.0.0.0.0.0.0.0.b.5.0.0.4.0.0.2.IP6.INT Zone file A ; OR 0.0.0.0.0.0.0.0.b.5.0.0.4.0.0.2.IP6.ARPA Zone file d.9.5.5.7.8.e.f.f.f.0.1.b.3.2.f IN PTR mk.ultra.mil U N Least Full Hostname I Significant V Nibbles Class Resource E (Internet) Record Type R S I T Y I N D IPv6 PTR Records I A N • Domain is either IP6.INT or IP6.ARPA A – IP6.ARPA is superceding IP6.INT (RFC 3596) U • Address is split into 32 four-bit nibbles N – Difficult to maintain in zone files I – Potential increase in DNS queries by factor of 8 V E • Purpose of nibbles is to allow finer division R of inverse domain S – Still isn’t enough granularity I T Y I N D Bitstring Labels I A N A Base Specifier Separator Closing Delimiter U N \[xf23b10fffe87559d/64] I V Opening Delimiter Hex Digits Significant Digits E R S I T Y I N D IPv6 DNAME Records I A N • Bitstring labels in DNAME records are used to give symbolic names to parts of the PTR record A – These records can be stored on different nameservers – Subject to all the drawbacks of the A6 record U – Now relegated to experimental status as well N I \[x2004/16].IP6.ARPA. IN DNAME mil. V \[x005b/16].mil. IN DNAME ultra.mil. E \[xf23b10fffe87559d/64].ultra.mil. IN PTR mk.ultra.mil. R S I T Y I N D Other DNS Concerns I A N • In general, you still need to do IPv6 queries A using IPv4 U – There isn’t a full set of IPv6 root nameservers N – Some root servers (F-Root) do use native IPv6 I V • Still in rapid transition E – AAAA vs. A6 debate has flipped several times R – .IP6.INT vs. .IP6.ARPA is settling as well S I T Y I N D Other DNS Concerns I A N • Even after the transition period A – Many IPv6 stacks will need to be updated U – Possible need to support all of these options N • Greater latency possible for clients I V – Recursive queries can be much more complex E – Potentially a greater load on nameservers R S • Zone files become harder to maintain I T Y I N D DNS Resolver Changes I A N A U N I V E R S I T Y I N D What is the Resolver? I A N •The resolver is the standard programmer’s A API for working with DNS U • Built around two main calls: N – gethostbyaddr() I V – gethostbyname() E • Other resolvers and APIs exist, but this is R S the one in the POSIX standard I T Y I N D Standard Resolver Calls I A N struct hostent *gethostbyaddr A (const char *addr, int len, int type); • addr is the address we’re looking up • len is size of that address U • type is the sort of address we’re looking up (i.e., AF_INET) N I struct hostent *gethostbyname(const char *name); V • name is the hostname we’re looking up E R S I T Y I N D Why Does It Need to Change? I A N • Inflexibility A – gethostbyname() doesn’t let you specify U whether you want a IPv4 or IPv6 address N – gethostbyaddr() doesn’t let you specify I whether you want an AAAA or A6 record V holds an array of E – struct hostent R addresses, not a linked list S • The address type must be homogeneous I T Y I N D Why Does It Need to Change? I A N • Reentrancy A – The current calls are not thread-safe U – The pointers returned are to static data N maintained by the resolver itself and reused for I each call V E – This means than an application using this API R must serialize all DNS lookups S • Ever wonder why IE and Netscape hang for a while? I T Y I N D Quick Fix I A N gethostbyname2(const char *name, int af); A • name is the hostname we’re looking up • af is the address family for the lookup (AF_INET, etc.) U N I • This call is a GNU extension V • This does not resolve any reentrancy issues E R • However, it’s quick and easy S I T Y I N D Another Fix I A N int gethostbyname_r A (const char *name, struct hostent *ret, char *buf, size_t buflen, U struct hostent **result, int *h_errnop); • name is the hostname we’re looking up N • ret stores the result of the call I • buf stores chunks of auxiliary data V • buflen specifies the size of buf E • result uses bit of buf to store host structures R • h_errnop holds any error number generated S I T Y I N D Another Fix I A N • The technical expression for this interface is A “horrid train wreck” U • This is also a GNU extension N • There is also a I gethostbyname2_r() V call that works similarly E – Adds the ability to specify address family R S I T Y I N D POSIX