In a computer network, the multicast Domain Name System ( mDNS protocol) resolves host names to IP addresses in small networks that do not include local name servers. This is a zero-configuration service, using essentially the same programming interface, package format and semantic operations as unicast Domain Name System (DNS). Although Stuart Cheshire designs mDNS as a stand-alone protocol, it can work in conjunction with standard Domain Name System (DNS) servers.
The mDNS protocol is published as RFC 6762, using IP Multicast User Datagram Protocol (UDP) packets, and is implemented by Apple Bonjour and open source Avahi software. Android contains mDNS implementations. mDNS has also been implemented in Windows 10, but its use is limited to finding networked printers.
mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a zero companion configuration technique specified separately in RFC 6763.
Video Multicast DNS
Ikhtisar protokol
When the mDNS client needs to resolve the host name, it sends an IP multicast request request that the host has the name to identify itself. The target machine then multicasts a message that includes its IP address. All machines on that subnet can then use that information to update their mDNS cache.
Each host can release its claim to the domain name by sending a response packet with time to live (TTL) equal to zero.
By default, mDNS only and exclusively resolves hostnames ending in .local top-level domains (TLD). This can cause problems if the domain includes hosts that do not implement mDNS but that can be found through a conventional unicast DNS server. Resolving such conflicts requires a change in network configuration that violates the zero-configuration goal. Maps Multicast DNS
Package structure
The mDNS message is a UDP multicast packet sent to the following location:
- When using Ethernet frames, standard multicast MAC addresses 01: 00: 5E: 00: 00: FB (for IPv4 ) or 33: 33: 00: 00: 00: FB (for IPv6).
- IPv4 addresses 224.0.0.251 or IPv6 addresses ff02 :: fb .
- UDP port 5353.
The load structure is based on a unicast DNS package format, which consists of two parts - headers and data.
Headers are identical to those found in DNS unicast, such as sub-sections in the data section: questions, answers, authoritative name servers, and additional notes.
The number of records in each sub-section corresponds to the corresponding * COUNT field values ​​in the header.
Queries
The wire format for notes in the query section is slightly modified from the one in DNS unicast, adding a single bit-area.
As in DNS unicast, the QNAME field consists of a series of long/value sub-fields called "labels". Each label represents one of the point-delimited substrings in a fully qualified domain name (FQDN). This list is terminated by one byte-zero, representing the "root" of the DNS.
The UNICAST-RESPONSE field is used to minimize unnecessary broadcasting on the network: if bits are set, respondents MUST send a unicast-directed response directly to the node in question rather than broadcasting responses across the network.
The QCLASS field is identical to that found in the DNS unicast.
Resources Note
All notes in answer, authoritative-name servers, and additional record sections have the same format and are collectively known as "Resource Records" (RR).
Resource Records in mDNS also have a slightly modified general format of DNS unicast:
The CACHE-FLUSH bit is used to instruct the neighboring nodes that the record must overwrite, rather than add to the existing cache entries for RRNAME and RRTYPE.
The format of the RDATA field is the same as that found in the DNS unicast. However, DNS Service Discovery (DNS-SD), the most common use case for mDNS, specifies slight modifications to some of its formats (especially TXT records).
Example
Attempting to ping host appletv.local will cause the mDNS client computer to multicast the following UDP packets:
00 00 Transaction ID 00 00 Flag 00 01 Number of questions 00 00 Number of answers 00 00 Number of records of authority resources 00 00 Number of additional resource records 07 61 70 70 6c 65 74 76 "appletv" 05 6c 6f 63 61 6c "local" 00 Terminator 00 01 Type (A record) 00 01 Class
The appletv.local host will respond by multicasting its mDNS response packet. As an example:
00 00 84 00 00 00 00 01 00 00 00 02 07 61 70 70 6c 65 74 76 05 6c 6f 63 61 6c 00 00 01 80 01 00 00 78 00 00 04 99 6d 07 5a c0 0c 00 1c 80 01 00 00 78 00 00 10 fe 80 00 00 00 00 00 00 02 23 32 ff fe b1 21 52 c0 0c 00 2f 80 01 00 00 78 00 00 08 c0 0c 00 04 40 00 00 08
In the headers, non-zero fields are Flags (84 00), ANCOUNT (001), and ARCOUNT word (00 02). The data again starts with FQDN (hex 07 61 70 70 6c 65 74 76 05 6c 6f 63 61 6c 00 for appletv.local), followed by the host's DNS information:
- code of type A/IPv4 address (hex 00 01),
- IPv4 class code (hex 80 01),
- IPv4 TTL (hex 00 00 78 00 to 30720 sec),
- length of IPv4 (hex 00 04),
- four IPv4 byte addresses (hex 99 6D 07 5A, or 153.109.7.90 in dotted-decimal notation),
- offset FQDN (hex C0 0C for byte 12),
- AAAA/IPv6 address type code (hex 00 1C),
- IPv6 class code (hex 80 01),
- IPv6 TTL (again hex 00 00 78 00),
- length of IPv6 (hex 00 10),
- 16 IPv6 byte addresses (hex FE 80 00 00 00 00 00 00 02 23 32 FF FE B1 21 52),
- offset FQDN (hex C0 0C for byte 12),
- type code of NSEC (hex 00 2F),
- the NSEC class code (hex 80 01),
- NSEC TTL (again hex 00 00 78 00),
- length of NSEC (hex 00 08, for 8-byte name part records), and
- block of 8EC and bitmap byte (hex C0 0C 00 04 40 00 00 08)
See also
- Avahi (software)
- Bonjour (software)
- Bonjour Sleep Proxy
- Service Switch Name (NSS)
- Zero network configuration (Zeroconf)
- Local Linked Multicast Name Resolution (LLMNR)
References
External links
- Multicast DNS
- New DNS Technology on LAN
- nss-mdns, GNU NSS plugin for multicast name resolution
Source of the article : Wikipedia
0 Comments