Section 3.5. The Structure of the Multicast DNS Message


3.5. The Structure of the Multicast DNS Message

The Multicast DNS Message format is modeled closely on the Unicast DNS Message format. In fact, they are so similar that packet-sniffing software such as Sniffer, EtherPeek, and Ethereal can decode and display mDNS packets using the same decoder as uDNS packets. There are, however, a few minor differences:

  • Unicast DNS packets are limited to, at most, 512 bytes. Multicast DNS packets are allowed to be up to 9,000 bytes, though it's recommended that implementations try to limit themselves to using packets only as large as the local link can carry without breaking the packet into multiple IP fragments. Standard Ethernet can carry packets up to 1,500 bytes without fragmentation. Subtracting 28 bytes for the IP and UDP headers, this leaves up to 1,472 bytes for the DNS portion of the packet.

  • Multicast DNS uses UDP port 5353 instead of port 53.

  • Multicast DNS uses UTF-8, and only UTF-8, to encode resource record names. Unicast DNS, for a variety of legacy compatibility reasons, has to use arcane encoding for non-roman text, but Multicast DNS is a new technology not saddled with those limitations, so it has the luxury of using the much simpler UTF-8 for everything.

  • Unicast DNS only allows query packets to contain one question each. For efficiency, Multicast DNS allows clients to pack in as many questions as they wish. They're still treated by the receiver just the same as if they were separate packetspacking them into a single packet is just an optional optimization to save network bandwidth.

  • Multicast DNS "borrows" the top bit of the rrclass field in a resource record. Remember that the only DNS class in widespread use todayout of the 65,536 possible values for this 16-bit fieldis the Internet class. By repurposing the top bit, we cut the range of possible class values in half to 32,768, but that's still a lot when you consider that we're only actually using one today. In responses, the top bit of the rrclass field is called the cache flush bit and signals the receiver that this new data should completely replace all old records with the same name, rather than adding cumulatively to any existing data. In questions, setting the top bit of the rrclass field signals a request to have the response for that record sent via unicast instead of multicast. This is something that's occasionally done in situations where it is believed that a unicast response would be more efficient on the network, but current operational experience seems to indicate that the actual benefit is very minor, so it's possible that future versions of mDNSResponder may not use this capability.




Zero Configuration Networking. The Definitive Guide
Zero Configuration Networking: The Definitive Guide
ISBN: 0596101007
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net