Multicast DNS
I datornätverk löser multicast DNS (mDNS)-protokollet värdnamn till IP - adresser inom små nätverk som inte inkluderar en lokal namnserver . Det är en nollkonfigurationstjänst som använder i stort sett samma programmeringsgränssnitt, paketformat och driftssemantik som unicast Domain Name System (DNS). Det designades för att fungera antingen som ett fristående protokoll eller kompatibelt med vanliga DNS-servrar. Den använder IP multicast User Datagram Protocol (UDP)-paket och implementeras av Apple Bonjour och Avahi -programvarupaketen med öppen källkod, som ingår i de flesta Linux-distributioner. Även om av Windows 10 var begränsad till att upptäcka nätverksskrivare, löste även efterföljande utgåvor värdnamn. mDNS kan fungera tillsammans med DNS Service Discovery (DNS-SD), en kompletterande nätverksteknik med noll konfiguration som specificeras separat i RFC 6763.
Historia
Multicast DNS föreslogs först av Bill Woodcock och Bill Manning i IETF 2000, och publicerades så småningom som standardspår IETF RFC 6762 av Stuart Cheshire och Marc Krochmal tretton år senare.
Protokollöversikt
När en mDNS-klient behöver lösa ett värdnamn, skickar den ett IP-multicast -frågemeddelande som ber värden som har det namnet att identifiera sig. Måldatorn multicastar sedan ett meddelande som innehåller dess IP-adress. Alla maskiner i det undernätet kan sedan använda den informationen för att uppdatera sina mDNS-cachar. Vilken värd som helst kan avsäga sig sitt anspråk på ett namn genom att skicka ett svarspaket med en time to live (TTL) lika med noll.
Som standard löser mDNS exklusivt värdnamn som slutar med toppdomänen .local . Detta kan orsaka problem om .local inkluderar värdar som inte implementerar mDNS men som kan hittas via en konventionell unicast DNS-server. För att lösa sådana konflikter krävs nätverkskonfigurationsändringar som mDNS utformades för att undvika.
Paketstruktur
Ett mDNS-meddelande är ett multicast UDP-paket som skickas med följande adressering:
- IPv4-adress 224.0.0.251 eller IPv6-adress ff02::fb
- UDP-port 5353
- När du använder Ethernet-ramar , standard IP multicast MAC-adress 01:00:5E:00:00:FB (för IPv4 ) eller 33:33:00:00:00:FB (för IPv6 )
Nyttolaststrukturen är baserad på unicast DNS-paketformatet , som består av två delar – rubriken och data.
Rubriken är identisk med den som finns i unicast DNS, liksom undersektionerna i datadelen: frågor, svar, auktoritativa namnservrar och ytterligare poster. Antalet poster i varje undersektion matchar värdet för motsvarande *COUNT-fält i rubriken.
Frågor
Trådformatet för poster i frågeavsnittet är något modifierat från det i unicast-DNS, och lägger till enbitars UNICAST-RESPONSE-fältet.
Fält | Beskrivning | Längdbitar _ |
---|---|---|
QNAME | Namnet på den nod som frågan hänför sig till | Variabel |
QTYPE | Typen av förfrågan, dvs typen av RR som ska returneras i svar. | 16 |
UNICAST-SVAR | Boolesk flagga som indikerar om ett unicast-svar önskas | 1 |
QCLASS | Klasskod, 1 aka "IN" för Internet och IP-nätverk | 15 |
Som i unicast-DNS består QNAME-fältet av en serie längd/värde-underfält som kallas "etiketter". Varje etikett representerar en av de punktseparerade delsträngarna i ett fullständigt kvalificerat domännamn (FQDN). Listan avslutas av antingen en enda noll-byte som representerar "roten" av DNS, eller av en byte med de två bitarna av hög ordning inställda (värde 192) för att signalera en indirekt pekare till en annan plats i meddelandet. Detta är känt som namnkomprimering i RFC-6762.
UNICAST-RESPONSE-fältet används för att minimera onödiga sändningar på nätverket: om biten är inställd BÖR svarspersoner skicka ett riktat unicast-svar direkt till den frågande noden istället för att sända svaret till hela nätverket.
QCLASS-fältet är identiskt med det som finns i unicast-DNS.
Resursposter
Alla poster i sektionerna för svar, auktoritativa namnservrar och ytterligare poster har samma format och kallas gemensamt för resursposter (RR).
Resursposter i mDNS har också ett något modifierat allmänt format jämfört med unicast DNS:
Fält | Beskrivning | Längdbitar _ |
---|---|---|
RRNAME | Namnet på den nod som posten hänför sig till | Variabel |
RRTYPE | Typ av resurspost | 16 |
CACHE-SPOLNING | Boolesk flagga som anger om föråldrade cachade poster ska rensas | 1 |
RRKLASS | Klasskod, 1 aka "IN" för Internet och IP-nätverk | 15 |
TTL | Tidsintervall (i sekunder) som RR ska cachelagras | 32 |
RDLÄNGD | Heltal som representerar längden (i oktetter) av RDATA-fältet | 16 |
RDATA | Resursdata; intern struktur varierar beroende på RRTYPE | Variabel |
CACHE-FLUSH-biten används för att instruera angränsande noder att posten ska skriva över, istället för att läggas till, eventuella befintliga cachade poster för detta RRNAME och RRTYPE.
Formaten för RDATA-fälten är desamma som de som finns i unicast-DNS. DNS Service Discovery (DNS-SD), det vanligaste användningsfallet för mDNS, specificerar dock små modifieringar av vissa av deras format (särskilt TXT-poster) .
Se även
externa länkar
- Multicast DNS - informationswebbplats som underhålls av mDNS-designern, Stuart Cheshire
- LLMNR, Multicast DNS och namn på ditt LAN