The Cable Guy - March 2004

Local Server-Less DNS Name Resolution for IPv6

By The Cable Guy

Local Server-Less Domain Name System (LSLDNS), also known as multicast DNS, is a new capability in the IPv6 protocol that is provided with Microsoft Windows CE version 4.1 and later. LSLDNS is described in the Internet draft titled "Local Server-less DNS (LSLDNS) query resolution" (draft-ietf-dnsext-mdns-07.txt).

Note  In recent revisions of the multicast DNS Internet draft, the name of the protocol has been changed to Linklocal Multicast Name Resolution (LLMNR) and many implementation details have been changed. This article does not describe LLMNR.

LSLDNS provides a method to resolve names on an ad hoc, single-subnet network that does not contain a functioning DNS server. IPv4 in Windows TCP/IP solves this problem by using NetBIOS over TCP/IP (NetBT), which is enabled by default. With NetBT, a querying node broadcasts a NetBIOS Name Query Request message to the local subnet broadcast address. The node that owns the queried name sends back a unicast NetBIOS Name Query Response to the requestor and the name is resolved.

This method does not work for IPv6 for the following reasons:

• NetBIOS is not defined to operate over IPv6.
• There are no broadcast addresses in IPv6.

LSLDNS is a simple request-reply mechanism used on ad hoc, single-subnet networks to allow IPv6 nodes to resolve each other's names in the absence of DNS name resolution functionality. Multi-subnet networks are assumed to have a functioning router and DNS server. Because broadcasts are not defined for IPv6, multicasts are used instead.

LSLDNS is similar to DNS in the following ways:

• Uses fully qualified domain names (FQDNs)
• Uses the same messages and message structure as DNS, as defined in RFC 1035

LSLDNS is different than DNS in the following ways:

• LSLDNS messages are sent to TCP and UDP port 5353, rather than TCP and UDP port 53
• LSLDNS message queries are sent to a multicast address, rather than the unicast address of a DNS server
• The LSLDNS name cache is separate from the DNS name cache

LSLDNS is used when DNS servers:

• Are not configured
• Do not return a response to a query
• Respond with Return Code (RCODE) set to 0, but there are no answer records
• Respond with RCODE set to 3 (domain name does not exist)

The multicast address used for DNS Name Query Request messages is known as the solicited name multicast address, and is constructed from the following:

• The prefix FF02::2:0:0/96.
• The high-order 32-bits of the Message Digest 5 (MD5) hash calculation on the host name portion of an FQDN or unqualified name. For example, if the FQDN is officecomputer.example.com, the host name is officecomputer.

The host that is assigned the host name listens on the solicited name multicast address and the host attempting name resolution of an FQDN beginning with the host name uses the solicited name multicast address as the destination address of a DNS Name Query Request message.

How LSLDNS Works

During the startup process, a node that supports LSLDNS calculates its own solicited name multicast address and instructs IPv6 to listen for packets sent to that address.

When an application uses the getaddrinfo() Windows Sockets function call to resolve an FQDN or non-qualified name to an address, the LSLDNS-capable node extracts the host name, calculates the MD5 hash of the host name, and appends the high-order 32 bits to the FF02::2:0:0/96 prefix to form the solicited name multicast address.

The querying node then constructs and sends a DNS Name Query Request message with the following contents:

• IPv6 header

  Source Address field is set to the link-local address of the interface of the querying node

  Destination Address field is set to the solicited name multicast address

  Hop Limit field is set to 255

• UDP header

  Source Port field is set to 5353

  Destination Port field is set to 5353

• DNS header

  Recursion Desired (RD) flag set to 0

Question section contains the full name as originally specified by the application and a request for the record type specified in the getaddrinfo() function call

Note that the Hop Limit in the IPv6 header is set to 255. The receiver verifies that the Hop Limit field is set to 255 before performing further processing on the message. This check is similar to the practice for Neighbor Discovery messages, in which the receiver verifies that the message came from a node that is attached to the local link. If the node were off-link, the Hop Limit field would be less than 255.

Note also that the RD flag in the DNS header is set to 0, indicating that the requestor does not wish the receiver to perform recursive queries on its behalf.

The multicast DNS Name Query Request message is received by the nodes that are listening on the specified solicited name multicast address (there is typically only one). They first verify that the Hop Limit field is set to 255. If it is not, the message is silently discarded.

The receiving host then checks to see if it is authoritative for the name in the Question section of the message. Contrary to normal DNS behavior, LSLDNS nodes are authoritative for specific names that have been assigned to them, rather than for a portion of the namespace beginning at the assigned name. Using conventional DNS server terminology, LSLDNS nodes are only authoritative for the zone roots corresponding to their assigned names (the term zone is used here loosely as LSLDNS nodes are not DNS servers that store zones). For example, an LSLDNS node that has been assigned the name office.example.com is not also authoritative for all names that begin with office.example.com.

If a node that receives the DNS Name Query Request message is authoritative for the name in the Question section of the message, it constructs and sends a DNS Name Query Response message with the following contents:

• IPv6 header

  Source Address field is set to the link-local address of the sending interface of the responder

  Destination Address field is set to the Source Address field of the received DNS Name Query Request message (the link-local address of the requestor)

  Hop Limit field is set to 255

• UDP header

  Source Port field is set to 5353

  Destination Port field is set to 5353

• DNS header

  Authoritative Answer (AA) flag set to 1

  Recursion Available (RA) flag set to 0

  RCODE field set to 0

  Question section includes the Question section fields and contents from the DNS Name Query Request message

  Answer sections include the appropriate records for the names and their associated types as requested in the DNS Name Query Request message

If the entire DNS Name Query Response message is larger than 512 bytes, the responder will set the Truncation (TC) flag to 1. The requestor can then either repeat the query using a unicast, TCP-based DNS Name Query Request message or it can retry the UDP-based query using EDNS0 (as defined in RFC 2671).

If the requestor does not receive a reply, it can retransmit the DNS Name Query Request message up to three more times. Only after not receiving any replies from its retransmitted queries can LSLDNS conclude that the name being queried for does not exist on the network and indicate the name resolution failure to the application that called the getaddrinfo() function.

It is possible that more than one node on an ad hoc or single subnet network is using the same host name. For example, one node is assigned the FQDN officecomputer.example.com and another node is assigned the FQDN officecomputer.upstairs.example.com. For both of these computers, the solicited name multicast address is the same. A query for the name officecomputer.example.com sent to the solicited name multicast address corresponding to the host name officecomputer is processed by both of these computers. However, only the computer assigned the officecomputer.example.com name sends a response.

It is also possible that more that one node is assigned the same FQDN. For both of these computers, the solicited name multicast address is the same. A query sent to the solicited name multicast address corresponding to the host name in the FQDN is processed by both of these computers and both computers send a response. In this case, the requestor treats the multiple responses as if it received multiple answer records in a single reply.

For More Information

For more information about IPv6, consult the following resources:

• Internet Protocol Version 6 Technology Center
• IETF DNS Extensions Working Group
• Internet Protocol Version 6 (IPv6) Support in Windows CE 4.1 and later

For a list of all The Cable Guy articles, click here.