Její doménou budou především sítě bez profesionální správy či sítě příležitostné a náhodně vznikající. Modelová situace: sejde se skupinka lidí s notebooky a chtějí si vyměnit data. Ještě typičtější příklad použití bude běžná domácí síť. K Internetu je připojena ADSL modemem, který pro ni funguje jako NAT a DHCP server. Domácím počítačům přiděluje adresy, ale nezavádí je do DNS. Pokud mezi nimi chcete komunikovat internetovými službami, musíte si zjistit aktuální IP adresu a tu použít. Přitom uživatel svůj počítač zpravidla pojmenuje a bylo by příjemnější používat i pro vzájemnou TCP/IP komunikaci tato přidělená jména místo adres.
A právě v takových případech přijde k duhu LLMNR, které dokáže neformální jména počítačů převádět na IP adresy. Nabízí tedy podobnou službu jako DNS pro jména oficiálně zaregistrovaná. Jeho interní mechanismy poněkud připomínají ARP. Pokud uživatel zadá jméno a systém je potřebuje převést na IP adresu, rozešle do sítě LLMNR dotaz. Tazatel se v oficiální terminologii protokolu označuje jako odesílatel (sender) a svůj dotaz posílá protokolem UDP na pevně danou skupinovou adresu – 224.0.0.252 pro IPv4 a ff02::1:3 pro IPv6, port 5355. V obou případech se jedná o lokální linkovou adresu a dotaz by neměl opustit danou linku, která zpravidla odpovídá jedné podsíti. (Pro srovnání, ARP posílá dotaz na linkový broadcast ff:ff:ff:ff:ff:ff.)
Vlastník poptávaného jména (v terminologii LLMNR odpovídající, responder) pak pošle odpověď cíleně na individuální adresu, z níž dotaz obdržel. Také v ARP se odpověď posílá na individuální MAC adresu tazatele. LLMNR tedy nemá žádné servery, respektive každý je sám sobě serverem a je v protokolu zodpovědný za své jméno a své IP adresy. Právě jeho schopnost obejít se bez serverové infrastruktury je hlavní příčinou jeho atraktivity, ale zároveň omezuje jeho schopnosti. Platnost jmen je například omezena jen na linku, k níž jsou přímo připojeni její vlastníci.
Formát zpráv LLMNR převzalo z DNS a teoreticky umožňuje v dotazech a odpovědích libovolné typy DNS záznamů. V praxi budou pochopitelně nejčastější převody jmen na IP adresy (záznamy A a AAAA) a obráceně (záznamy PTR). U reverzních dotazů, kdy se k IP adrese hledá jméno, je situace poněkud odlišná, protože tazatel zná IP adresu zodpovědného stroje. V tomto případě se jeho chování mění a dotaz posílá protokolem TCP na individuální IP adresu dotazovaného stroje.
Problém představují duplicity. Nedá se pochopitelně zabránit tomu, aby se u víceméně náhodných strojů nevyskytla dvě stejná jména. Protokol proto pamatuje na hledání duplicit a řešení takových situací (jméno si ponechá stroj s nejnižší IP adresou, ostatní kolidující je musí přestat používat).
LLMNR nemá žádné ambice poskytovat informace o jménech a adresách nacházejících se mimo danou linku. Slouží skutečně pouze pro ad hoc připojené stroje. Samotné RFC o něm mluví nikoli jako o konkurenci DNS, ale o jeho doplňku. LLMNR by mělo sloužit jako sekundární mechanismus pro konverzi adres a jmen. Specifikace protokolu doporučuje, aby se rezoluční mechanismus volil podle zadaného jména. Pokud bude obsahovat jen jedinou doménu (např. pepa), mělo by se k jeho řešení použít LLMNR a vynechat DNS. Jakmile má jméno více částí (pepa.kdesi.cz), mělo by se naopak použít pouze DNS, nikoli LLMNR.
Nabízí se myšlenka na vzájemný překlad mezi oběma světy. Kdyby byl k lince připojen někdo (jako vhodný kandidát se nabízí třeba některý ze směrovačů), kdo by dotazy přicházející po LLMNR převáděl do DNS a přeposílal by pak získané odpovědi, získaly by všechny zdejší počítače přístup k DNS, aniž by musely mít konfigurován DNS server. Hlavním problémem tohoto přístupu je bezpečnost. Jak ochránit účastníky před falešným překladatelem, který bude údaje z DNS padělat? To je pravděpodobně hlavní důvod, proč RFC 4795 vzájemný překlad nenavrhuje. Chtějí-li počítače žít plnohodnotným síťovým životem, musí si opatřit adresu lokálního DNS serveru a využívat jeho služby standardním způsobem.
Bezpečnost je obecně slabým místem LLMNR. Útočník připojený k lince může posílat falešné odpovědi a například úmyslně kolidovat se jmény ostatních, aby jim zabránil ve fungování (DoS), nebo se snažil na sebe stáhnout cizí provoz. Specifikace se obecně zmiňuje o třech možnostech autentizace LLMNR (TSIG nebo SIG(0), ESP hlavička z IPsec či využití DNSSEC), ale jistě i její autoři cítí, že zapojení bezpečnostních mechanismů bude vyžadovat konfigurační zásahy, které naruší původní bezobslužnost. Právě obavy o bezpečnost vedou ke striktnímu požadavku, aby cache LLMNR byla samostatná a neměla nic společného s cache pro DNS.
A špetka kyselinky závěrem. Za návrhem LLMNR stojí Microsoft (původně se protokol jmenoval Server-Less Domain Name System). Již před ním přišel Apple s Multicast DNS (mDNS), což je totéž v bledě modrém. Používá jiné adresy (224.0.0.251 a ff02::fb, port 5353), odpovědi ohlašuje skupinově (usnadňuje to kontrolu duplicit) a za jména připojuje .local, aby se zdůraznila jejich příslušnost k lokálnímu jmennému prostoru. V jádru jsou si však oba dva přístupy velmi podobné. mDNS je podle mého soudu propracovanější, ale nepřekročil stadium návrhu.
V případě Apple se jedná o jednu ze součástí architektury pro co největší usnadnění síťování, označované jako Zeroconf. Svého času existovala i stejnojmenná pracovní skupina IETF, která ale uzavřela svou činnost v roce 2004, když dokončila přípravu RFC 3927 pro dynamickou volbu lokální linkové IPv4 adresy. Že si Microsoft (MS) vynalézá své vlastní kolo, nepřekvapuje. Patří to k jeho firemním standardům, stejně jako následná marketingová kampaň, že jeho kolo je daleko kulatější než konkurenční produkty. Ostatně i další prvky Zeroconf mají své MS analogie. Proč se v soukolí IETF do podoby RFC prosadil tento návrh, a ne starší a lepší mDNS, si netroufám soudit. Počítám, že důvodem bude nasazení a osobní vazby zúčastněných.
Výsledkem je RFC pro LLMNR, které je implementováno ve Windows CE i Windows Vista. Pro jmenné služby ale významný krok vpřed nepředstavuje. Drtivá většina práce nadále zůstává na bedrech DNS.
