Za tohle muze taky Lennart?

12.6.2014 14:16

Tak v Ubuntu 14.04 nefunguje pripojeni k internetu pres ruzne hotspoty.

Resenim je zmenit v /etc/nsswitch.conf radek

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns

na

hosts:          files myhostname dns mdns4_minimal [NOTFOUND=return]

Rozbite avahi?

Celkem zklamani, ze takoveto elementarni problemy se znovuobjevuji na Linux desktopu .        

Komentáře

[chrono]

A je ten problém aj inde, alebo len v Ubuntu?

[kavol]

všude, kde se ta Lennartí sračka používá

pozn. pokud si níže stěžuju na Apple, tak musím dodat, že ti aspoň by default umožňují fallback, když to neresolvuje bonjour, tak se to passne na normální dns, zatímco lennart boys se zase rozhodli jít cestou "když rozbít, tak pořádně", a jak je vidno z toho blogu, fallbacku brání

[luv]

Diky za podporu aspon nekdo chape ze end userovi je politika kolem RFC nekde. Na androidi to vali, na macovi, na windows, na iphonu ale na linuxune a proc? Protoze politika.

[pavlix]

Asi by bylo dobré napsat konkrétně v čem je problém a čím se vyznačují ty hotspoty, kterých se to týká. Nejspíš za to můžou buď provozovatelé hotspotů, kteří zneužívají doménu .local nebo dodavatelé hotspotových řešení, kteří to tak pro ně nastavili.

[smazáno]

Presne - skvela dedukce! Dns fallback by mel fungovat i pokud mdns selze (i pro .local), prave z toho duvodu co si zminil.

[pavlix]

Ještě si přesně nepamatuju, co dělá _minimal.

[Sten]

mdns4_minimal dělá to samé jako mdns4, akorát se snaží resolvovat jen .local a u ostatního vrací unavail, mdns4 se snaží resolvovat cokoliv.

[pavlix]

mdns4 se snaží resolvovat cokoliv.

A to má za účel ukázat DNS-SD na globálním DNS?

[Sten]

Ne, mdns4 pošle mDNS požadavek na libovolnou doménu multicastem v lokální síti. Viz RFC 6762:

DNS queries for names that do not end with ".local." MAY be sent to the mDNS multicast address, if no other conventional DNS server is available

Odpovídající nastavení (které zkouší resolvovat .local i přes DNS) by pak bylo:

mdns4_minimal dns [NOTFOUND=return] mdns4

[pavlix]

Ne, mdns4 pošle mDNS požadavek na libovolnou doménu multicastem v lokální síti. Viz RFC 6762:

Zde si nejsem úplně jistý, k čemu je to dobré.

[Sten]

Hned následující věta v RFC 6762:

This can allow hosts on the same link to continue communicating using each other's globally unique DNS names during network outages that disrupt communication with the greater Internet

[kavol]

hm, a on někdo resolvování .local klasickou dns vyčítal, že je nebezpečné, a že s dnssec bude takové nastavení v prdeli?

a co je proboha tohle, už se ani nepotřebuju nabourat do komunikace mezi klientem a tou lokální dns, už jen stačí kýmkoliv odpovědět na multicast, jestli to dobře chápu? - tak tomu říkám pokrok a zvýšení bezpečnosti

[Sten]

Nestačí. Přímo v tom RFC je tohle omezeno if no other conventional DNS is available

[kavol]

no, takže buď

a) conventional DNS is available

- žádná změna

nebo b) conventional DNS is not available

- klient pošle dotaz multicastem => kdokoliv mu může odpovědět => "kdokoliv" může být útočník = přidán další attack vector, zhoršení bezpečnosti

a co s tím dnssec, to v tomto případě s mdns bude fungovat, když klasickému dns bylo vyčítáno že nad .local nepojede?

[pavlix]

a co s tím dnssec

DNSSEC je v tomhle složitější, protože zjevně nedokáže zajistit, co od něj velká část odborné veřejnosti očekává. Teorie je krásná věc, ale v reálném nasazení se ukazuje, že je v případě uživatelských zařízení vždy potřeba nechat ze strany sítě dynamicky nakonfigurovat výjimky, tedy podstromy, kde se DNSSEC aplikovat nebude.

[Sten]

Tipuju, že to bylo myšleno pro sítě, kde jsou všechny stroje důvěryhodné, ale které mohou mít problémy s připojením. AFAIK to stejně žádný systém ve výchozím nastavení nemá povolené a i mě přijde jednodušší pro takovou síť rozjet DNS cache server.

DNSSEC v mDNS nefunguje.

[pavlix]

To popravdě moc nezapadá ani do toho, jak se dnes sítě používají, ani do nějaké alespoň rámcové představě o bezpečnosti. Takže bych se vůbec nebál tuto část RFC ignorovat. Je to vůbec implementováno v Avahi?

[rADOn]

Co s tim ma spolecnyho Lennart? Snad uz neasimiloval i nsswitch?

[smazáno]

Koukni na sekci Documentation tady. Ten config se od toho v Ubuntu skoro nelisi a imho ma uplne stejny problem.

[smazáno]

tady

[Sten]

Řešení je vyhodit [NOTFOUND=return]. Chyba je nicméně u provozovatelů těch hotspotů, že používají TLD .local, která jim nepatří a je vyhrazena pro jiné účely.

[smazáno]

Wow, to bychom bez tebe fakt nevedeli!!

[leo]

Vyndej si prosím tě tu hlavu z řiti, chováš se jako fakan.

[smazáno]

Achjo, takovyhle komentare - fakt skoda co se s abickem stalo

[leo]

Říkám si to samé...

[frdrx]

Z toho si nic nedělej. To je na každým serveru.

[pavlix]

V tomhle případě se obávám, že má trochu pravdu.

[luv]

Jako uznavam ze ta moje reakce byla agresivni ale uz jsem se neudrzel takove podobne komentare pod blogama me uz fakt stvou a jsou tezce demotivujici cokoli psat.

[luv]

Tim myslim komentare ve stylu "pfff co to tady pises to prece kazdej vi" pritom totalne nepochopi o cem blog je a pridana hodnota je nula.

[luv]

A dobre v tom blogu jsem nenapsal presne v cem je ten problem na druhem radku jsem dal dns pred mdns ale po 30 minutach UPLNE zbytecneho hrabani se v strace a v manu jsem byl na tyhle vychytralosti tak nasranej ze jsem tam to dns hodil prvni :).

Kazdopadne o tom ten post vubec nebyl ale o tom ze tohle by end user fakt fakt resit nemel a to jestli hodit v nsswitch dns pred mdns nebo ne je uplne jedno. Ztratil jsem pul hodiny casu kdyz jsem fakt neco potreboval resit takovouhle kravinou a to pominu to ze be mych skillu bych byl nekde... A proc? Protoze Lennart a prochazimu to!!!

[luv]

Sorry za preklepy ale na tehle slamartphonech s klavesnici bez fyzicke feedbacku se fakt psat neda a to tady uz rvu kvuli idiotskymu linux a android ze me za chvilu asi vyhodi.

[luv]

Slamartphonech prej.... Hahaha :DDD

[luv]

A samozrejme se omlouvam, ze se neumim chovat a vylejvam si vztek na ostatnich, uz se to nestane

[luv]

Zato krast nekomu identitu je naprosto ok .. sbohem abicko.

[luv]

Podrezu si zily .. sbohem kruty svete

[smazáno]

lol

[luv]

Hlavne se snazim rict ze se to stejne info da pridat i s respektem k OP!!

[pavlix]

Celý originální zápisek šel napsat s respektem a především více informacemi. Já osobně se o tyhle problémy fakt dost zajímám a ta bezobsažnost zápisku mě mrzí. Hlavně že musí být provokativní.

[kavol]

více informací by neuškodilo, to je fakt, ale o jakém respektu to mluvíš?

lze mít respekt k někomu, kdo se vyloženě baví tím, aby věci co nejvíce rozbil a lidem zkomplikoval život?

na tenhle problém jsem narazil na Fedoře před dvěma lety (tedy ještě před vydáním toho RFC, btw), co jsem tehdy hledal, všichni umožňovali fallback (včetně toho, že Apple vydával nějaké opravy, aby to netrvalo moc dlouho), jenom Lennart prohlásil, že prostě nechce, aby to fungovalo, protože to nezapadá do jeho představy ideálního světa, takže uživateli máš smůlu (ostatně viz mj. aktuální diskuse o grupě floppy)

[Bystroushaak]

Minimálně respekt ke čtenářům by nebyl k zahození.

[pavlix]

+1

[pavlix]

Hlavně že od vás, kteří věčně nadáváte mám alespoň jednu kvalitní alternativu k Avahi a nss-mdns, abych tu Lennartovu věc nemusel používat. Ono je lehké nadávat, ale poskytnout lepší alternativy ke všem lennartovinám, co člověk z různých důvodů denně používá, nebo alespoň patche na opravu těch existujících lennartovin, to po té armádě kritiků nemůžu chtít, že. Rozdíl mezi Lennartem a nejhlasitější částí jeho kritků je v tom, že zatímco Lennart produkuje špatný software, tahle skupina lidí neprodukuje prakticky žádný.

[pavlix]

Tím se ani tak nechci dotknout tebe osobně a už vůbec ne lidí, kteří se snaží pro situaci něco udělat. Jde jen o to, že já vidím celý problém v té epidemii debility, jejímž důsledkem je, že si lidé myslí, že za všechny jejich problémy může jeden jiný člověk, viník, na kterého lze vše shodit. Přitom kdyby jeho práci nikdo používat nechtěl, tak může být každému u prdele kvalita kódu, který produkuje.

[drunkezz]

musim povedat ze tymto si trafil klinec po hlavicke, ja sa nejako nevyjadrujem verejne k lennartovi a pod, to si radsej necham na konstruktivne nadavanie priamo redhatakom.S cim nesuhlasim je implikacia ze ten kto nedodava ziadny kod nema narok frflat na styl prace aktualnych baselinerov v redhate. Je to nezmysel. Ako si niekde trefne pisal systemd uz nie je len init ale jeden velky repozitar noveho userspace....USERspace.

moj pohlad je taky ze

A, epidemia debility tu je

B, bod A, tu je lebo ludia si radi zhmotnia anti krista (ak ked za celym problemom systemd (lebo imo to problem je)) je redhat ako taky a jeho mimoriadne necitatelny management

C, lennart je arogantny curak, to ale neznamena ze si nemoze kodit ako chce

D, je smutne ze klasicke principy doterajsieho vyvoja OSS (verejne testovanie+reflexia na bugy atd...sak vieme ako to prebehlo s poslednymi bugmi) sa aj pod vplyvom bodu C, jemne povedane nie velmi uplatnuju

E, zasadna vec podla mna=> sracky z desktopu idu do serverov, na serveroch potrebujem mat cim stabilnejsie a statickejsie (samozrejme v ramci pouzitelnosti) management prostredie, nie dynamicke <>viny ktore sa parsuju asi ako jablon v rybe, lebo na kazdom boxe maju inu formu....atd atd

D.

[ewew]

Keď niekto prevádzkuje server je predpoklad, že vie čo robí a nemusí mu nejaká binárka určovať čo môže a nemôže.

V prípade, že systemd ostane len init systémom tu nie je problém.Urobiť monolitický systém je chyba, pretože aj malá porucha v celku zoberie celý systém.

[pavlix]

Ako si niekde trefne pisal systemd uz nie je len init ale jeden velky repozitar noveho userspace....USERspace.

Přesně tak. Lennart byl pokud vím dostatečně známý už před napsáním systemd a tím, že všichni možní lidé až už s RH nebo z širší komunity jeho práci přijeli takto pozitivně, nelze vše házet na jednoho člověka. Open source je mimojiné právě o tom, že jeden člověk nemůže diktovat ostatním, co mají používat.

S cim nesuhlasim je implikacia ze ten kto nedodava ziadny kod nema narok frflat na styl prace aktualnych baselinerov v redhate.

Je rozdíl mezi kritikou něčí práce a ovcovatěním, kdy si člověk vybere jednoho boha (třeba djb) a jednoho ďábla (třeba lennarta) a celou svoji mysl zasvětí takto vzniklému náboženství.

B, bod A, tu je lebo ludia si radi zhmotnia anti krista (ak ked za celym problemom systemd (lebo imo to problem je)) je redhat ako taky a jeho mimoriadne necitatelny management

Asi pochopíš, když toto nebudu nijak komentovat :). S ostatními body souhlasím až na drobné výhrady vůči E.

nie dynamicke <>viny ktore sa parsuju asi ako jablon v rybe, lebo na kazdom boxe maju inu formu....atd atd

Já jsem toho názoru, že jestliže statická konfigurace serveru funguje dle očekávání, možnost použití dynamické konfigurace je jenom vítaná. Jinak řečeno, v mnoha případech mi přijde dynamická konfigurace serverů užitečná, pokud to neznamená obětovat základní funkcionalitu. Ale to by bylo na delší povídání. Týká se to jak systemd, tak NetworkManageru, tak mnohého jiného software.

[kavol]

Přitom kdyby jeho práci nikdo používat nechtěl, tak může být každému u prdele kvalita kódu, který produkuje.

no, tohle je právě ten základní kámen té debilizace - že lidi, co mají nějakou moc rozhodovat, ty sračky používat chtějí

a ne, fakt nemám čas kutit si vlastní distro a patchovat různé programy, aby mi v tom distru na žádné lennartovině nezávisely

jinak není "si lidé myslí, že za všechny jejich problémy může jeden jiný člověk" vpodstatě stejná generalizace, jako proti které se ohrazuješ?

[pavlix]

no, tohle je právě ten základní kámen té debilizace - že lidi, co mají nějakou moc rozhodovat, ty sračky používat chtějí

To souhlasím.

a ne, fakt nemám čas kutit si vlastní distro a patchovat různé programy, aby mi v tom distru na žádné lennartovině nezávisely

Respektuju to, že k takovým věcem nemáš možnosti a/nebo motivaci, nicméně pak nezbývá než s těmi výsledky žít. Já osobně jsem začal systemd používat na Gentoo a musím přiznat, že to má mnohé výhody. Tudíž nemám zapotřebí se zbavovat závislostí na lennartovinách, jen se snažím, abych mohl ty lennartoviny používat k rámcové spokojenosti a abych tu stejnou možnost dal dalším.

jinak není "si lidé myslí, že za všechny jejich problémy může jeden jiný člověk" vpodstatě stejná generalizace, jako proti které se ohrazuješ?

Někteří.

[Josef Kufner]

Co to tak z povzdálí sleduji, chtělo by to spíš Lennarta občas trošku proplesknout, aby nedělal moc velké blbosti. Pokud by mu za zády stál QA tým s velkým bičem, mohlo by to být docela dobré.

[Ondrej 'SanTiago' Zajicek]

Hlavně že od vás, kteří věčně nadáváte mám alespoň jednu kvalitní alternativu k Avahi a nss-mdns, abych tu Lennartovu věc nemusel používat.

No, me by spis zajimalo, kdo a k cemu vubec potrebuje Avahi / mDNS a proc je tak tlacen do desktopovych prostredi (napr. zavislosti ruznych desktopovych metapackages v Debianu). Pro ad-hoc adresaci pocitacu pres jejich jmena existuje v domacim prostredi davno alternativa - propagace jmena pocitace skrz DHCP na domaci router, ktery pak na ta jmena odpovida v ramci sve funkce rekurzivniho DNS serveru.

[pavlix]

No, me by spis zajimalo, kdo a k cemu vubec potrebuje Avahi / mDNS

Mám dojem, že na toto téma jsme se už bavili vícekrát, jedná se o různé use cases typu just works. Přijde mi nanejvýš rozumné používat jen jednu discovery vrstvu a tu používat z dalších aplikací a pokud možno stavět tu discovery vrstvu nad již známými protokoly, což je v tomto případě DNS.

1) Já osobně mám Multicast DNS rád, jiní s oblibou používají různé obdoby téhož. Mám doma na síti tiskárnu od HP, nijak jsem ji nekonfiguroval, nemá ani přidelenou stálou IP adresu. Nakonfigurovat ji na systému s mDNS je záležitostí několika vteřin a prakticky žádných znalost. Při konfiguraci dovedené do dokonalosti by nebylo nutné nic konfigurovat a bylo by možné na ni rovnou tisknout.

2) Běžně dělám bootstrap síťových prvků. Většinou je nutné někde vyzjistit výchozí IP adresu, dostat zařízení do stavu, kdy ji použije (failsafe mode, factory reset, ...) nebo použít nějakou technologii na to zařízení najít. Jedním z důvodů, proč se stal Mikrotik oblíbeným je to, že stačí otevřít WinBox a ten už si lokálně připojeného Mikrotika najde. Navíc se k němu umí připojit přes MAC adresu, čemuž zhruba odpovídá použití automatické link-local IPv6 v kombinaci s mDNS.

3) Běžně dělám bootstrap serverů mimo síť, ve které se budou provozovat. Jako první zapínám síť, SSH a nss-mdns, abych nemusel tomu serveru zcela zbytečně přidělovat pevnou adresu a DNS jméno v mé síti, a přitom k němu mohl vždy hned po startu přistupovat vzdáleně aniž bych si musel pamatovat nebo zapisovat někam IP adresu.

4) Rád bych měl možnost když přijdu na lokální síť kontaktovat uživatele, kteří chtějí být kontaktování. To umí zajistit XMPP a aby nevytvářelo vlastní discovery protokol, používá mDNS.

5) Rád bych na síti provozoval i další zařízení, která se ohlašují do sítě a ať už z titulu malé uzavřené sítě nebo pomocí další autentizace si mohl vybrat zařízení, které chci použít. Může se jednat o síťové repráky (tedy sound server), může se jednat o nějaký síťový zdroj dostupný pro všechny, kdo mají zájem si udělat discovery na síť (dejme tomu webserver).

6) Na školeních jsem vždycky rád využíval toho, že když si jeden člověk nastaví hostname, je vidět na mDNS a druhý člověk se může k němu připojovat po libovolném protokolu, se kterým se zrovna pracuje (SSH, HTTP, whatever), aniž bych musel zajišťovat, že všichni budou používat stejný DNS server, na kterém jim ty jména budu během školení nastavovat já ručně.

Osobně mi přijde discovery natolik užitečné, že spíše nedokážu pochopit, jak se někdo může na jeho užitečnost vůbec ptát.

Propagaci přes DHCP za dobrou alternativu nepovažuju, protože:

1) Je to podle mého skromného názoru nehorázná prasárna zasírat jinak důvěryhodné DNS záznamy přijatými od náhodně připojených strojů. V případě Multicast DNS člověk alespoň ví, že všechny záznamy jsou z principu nedůvěryhodné a podle toho může zachovat.

Tady uznávám systém, co používá (mimojiné) Microsoft, kdy se záznamy v DNS objevují na základě nějakého definovaného vztahu mezi strojem a doménou.

2) Řešení, které vyžaduje konfiguraci DHCP a DNS serveru nemůže nahradit řešení, které funguje samo o sobě.

[pavlix]

K druhé části:

3) Řešení, které vyžaduje DHCP server nefunguje při přímém spojení kabelem, tedy například při bootstrapu jakéhokoliv zařízení po IPv6LL + mDNS nebo při spojení tiskárny s podporou IPv6LL a mDNS kabelem napřímo do počítače.

[Ondrej 'SanTiago' Zajicek]

Přijde mi nanejvýš rozumné používat jen jednu discovery vrstvu a tu používat z dalších aplikací a pokud možno stavět tu discovery vrstvu nad již známými protokoly, což je v tomto případě DNS.

S tim souhlasim, ale je dobre diskutovat zvlast mDNS a service discovery vrstvu. To jsou koncepcne odlisne zalezitosti a uz jen amalgamovat to do jednoho demona nemusi davat dvakrat dobry smysl. Koncepcne tu mame DNS resolver (napr. ve forme cachujiciho demona), ktery muze a nemusi podporovat mDNS, a pak service discovery vrstvu, ktera muze implementovat ruzne service discovery protokoly a jejiz rozhrani vuci DNS vrstve se az tak moc nelisi od pozadavku ostatnich aplikaci na DNS resolver. Krom toho i specificky tento service discovery protokol (DNS-SD) muze bezet jak pres mDNS tak pres regularni DNS.

Co se tyce existence service discovery vrstvy, tam v zasade namitky nemam, snad az na to, ze stale existuje mnoho alternativnich protokolu (SLP, UPnP, Zeroconf a ruzne domenove specificke) a tak povazovat jeden konkretni za automatickou soucast linuxoveho desktopu nemusi byt dvakrat korektni.

Jinak mam namitky specificky proti mDNS:

1) Automaticky se ztotoznuje 'site' (intuitivni vymezeni prirozeneho dosahu discovery protokolu) s jednou linkovou siti. Uzivatelske protokoly by mely prirozene skalovat i v pripade, kdy 'lokalni sit' se sklada z nekolika routovanych linkovych siti

2) Je zde prostor pro pseudo-NBMA site, ktere maji jen limitovanou podporu multicastu (pro specificky implementovat systemove protokoly), napr. rozsahle infrastructure wifi site. Tam veci stojici na na link-level multicastu prestanou fungovat.

3) Aplikace by mely mit moznost centralne prepnout z 'ad-hoc' rezimu do 'administrovaneho' rezimu, aniz by doslo k zasadni zmene user experience. Uz stary neighbor discovery v SMB / Windows umoznoval propagovat adresy WINS serveru pres DHCP a tak prepnout multicast/broadcast based discovery na centralni bez uzivatelske zmeny chovani. Oproti tomu striktni vyhrazeni domeny 'local' pro mDNS znamena, ze takove prepnuti neni mozne.

2) Běžně dělám bootstrap síťových prvků.

No, vzhledem k variabilite discovery protokolu v teto oblasti to neni prilis dobry argument pro mDNS. Napr. ja mam doma momentalne off-the-shelf router, ktery mDNS asi neumi, UPnP se na nem da zapnout, ale standardne pouziva trivialni CDP.

3) Běžně dělám bootstrap serverů mimo síť, ve které se budou provozovat.

To zajisti stejne tak i reseni pres DHPC/DNS

Na školeních jsem vždycky rád využíval toho, že když si jeden člověk nastaví hostname, je vidět na mDNS a druhý člověk se může k němu připojovat po libovolném protokolu, se kterým se zrovna pracuje (SSH, HTTP, whatever), aniž bych musel zajišťovat, že všichni budou používat stejný DNS server, na kterém jim ty jména budu během školení nastavovat já ručně.

Pri pouziti DHCP se standardne nastavi i DNS server, samozrejme to muze byt overridden, ale stejne tak uzivatel nemusi mit nastaveny mDNS nebo defaultni hostname (coz bych hadal za nejcastejsi problem).

Propagaci přes DHCP za dobrou alternativu nepovažuju, protože:

1) Je to podle mého skromného názoru nehorázná prasárna zasírat jinak důvěryhodné DNS záznamy přijatými od náhodně připojených strojů. V případě Multicast DNS člověk alespoň ví, že všechny záznamy jsou z principu nedůvěryhodné a podle toho může zachovat.

IMHO ty zaznamy jsou taky jasne odlisitelne (naucene zaznamy jsou bud samostatna hostname, nebo budou v separatni poddomene), brana navic muze umoznovat filtrovani ci definici well-known jmen a centralne monitorovat a resit kolize. coz pristup s mDNS neumoznuje. Hlavne je ale transparentni pro pripad kdy se pouziva vic oddelenych linkvych siti.

[pavlix]

S tim souhlasim, ale je dobre diskutovat zvlast mDNS a service discovery vrstvu.

Zkusme se držet tématu. Ptal ses, k čemu by kdo kdy mohl použít mDNS a Avahi, já jsem ti dal vcelku podrobnou odpověď. Netvrdil jsem, že je to jediná možnost jak to řešit, ale shrnul jsem i některé vlastnosti, které jsou v těch případech užití zajímavé.

Krom toho i specificky tento service discovery protokol (DNS-SD) muze bezet jak pres mDNS tak pres regularni DNS.

V případech užití, o kterých jsem psal jde právě o kombinaci mDNS, DNS-SD a v mnohých případech i autokonfiguraci adres. Někdy se tomu souhrnně říká Zeroconf, ale jsem si jistý, že tohle všechno znáš.

povazovat jeden konkretni za automatickou soucast linuxoveho desktopu nemusi byt dvakrat korektni.

V tomto ohledu se necítím být vinen. Na mDNS se mi nejvíc líbí to, že používá de facto DNS a tím pádem lze specifikovat služby společně pro DNS-SD nad globálním DNS i mDNS.

1) Automaticky se ztotoznuje 'site' (intuitivni vymezeni prirozeneho dosahu discovery protokolu) s jednou linkovou siti. Uzivatelske protokoly by mely prirozene skalovat i v pripade, kdy 'lokalni sit' se sklada z nekolika routovanych linkovych siti

Vyvráceno. Osobně jsem používal mDNS napříč několika L2 segmenty.

2) Je zde prostor pro pseudo-NBMA site, ktere maji jen limitovanou podporu multicastu (pro specificky implementovat systemove protokoly), napr. rozsahle infrastructure wifi site. Tam veci stojici na na link-level multicastu prestanou fungovat.

To samo o sobě nevidím jako důvod ten link-level nástroj nenasadit tam, kde je pro mě užitečný.

3) Aplikace by mely mit moznost centralne prepnout z 'ad-hoc' rezimu do 'administrovaneho' rezimu, aniz by doslo k zasadni zmene user experience

Ano, to by bylo docela užitečné rozšíření.

No, vzhledem k variabilite discovery protokolu v teto oblasti to neni prilis dobry argument pro mDNS. Napr. ja mam doma momentalne off-the-shelf router, ktery mDNS asi neumi, UPnP se na nem da zapnout, ale standardne pouziva trivialni CDP.

Ptal ses, na co mDNS a Avahi je. Já je pro tento účel používám a zatím nevím o nástroji, kterým bych mohl Avahi nahradit, aby mDNS nadále fungovalo k mé spokojenosti a ještě mi začaly fungovat ostatní protokoly. Pokud takový software existuje, budu rád, když se o něj podělíš.

To zajisti stejne tak i reseni pres DHPC/DNS

Pokud jsi dočetl až do konce, tak víš, že to není ekvivalentní řešení.

[čavo]

1) Je to podle mého skromného názoru nehorázná prasárna zasírat jinak důvěryhodné DNS záznamy přijatými od náhodně připojených strojů. V případě Multicast DNS člověk alespoň ví, že všechny záznamy jsou z principu nedůvěryhodné a podle toho může zachovat.

Mám o tomto málo vedomostí, ale keď dám ping, kde sa dozviem, že mi tú ip dodalo nedôveryhodné mdns?

[pavlix]

Za předpokladu, že se mDNS používá jen pro doménu .local, to člověk pozná ve chvíli, kdy takovou doménu do parametru napíše.

[čavo]

Pravda. A podľa konfigurácie v článku, by to asi tak aj malo byť, keďže sa použilo mdns4_minimal.

I keď mená v doméne .local môžu byť dodané aj inak, ale hádam to ničomu neuškodí, keď aj tie budeme považovať za nedôveryhodné.

[kavol]

Za předpokladu, že se mDNS používá jen pro doménu .local ...

... který dle diskuse výše nemusí být splněn

co potom?

[pavlix]

... který dle diskuse výše nemusí být splněn

Pokud vím, tak právě diskuze výše už můj názor na věc obsahuje.

[kavol]

ovšem z toho mi není zřejmá odpověď na otázku, jak se pozná, že odpověď dodalo nedůvěryhodné mdns ...

[pavlix]

Není mi jasné, co na tom nechápeš.

[Sten]

DHCP vyžaduje jednu centrální autoritu a DynDNS vyžaduje tunu nastavení (a koordinace s DNSSEC taky není zrovna jednoduchá). Navíc to úplně zbytečně komplikuje sítě s IPv6, kde DHCP nepotřebujete, a nefungují tam SRV záznamy, protože DHCP nemá, jak je zjistit. mDNS oproti tomu funguje dobře i v síti, kde žádnou centrální autoritu nemáte, a SRV záznamy tam fungují správně, včetně toho, že se umí aktualizovat pouhým spuštěním či vypnutím příslušné aplikace.

[pavlix]

+1

Takové řešení nelze považovat za 100% náhradu za mDNS.

[smazáno]

Příloha:

• fallback_to_dns_even_for_local (293 bytů)

No imho je idealni prave zmenit ten nsswitch.conf aby pouzil dns jako fallback i pokud mdns selze - tzn presne to co navrhl Sten .

Ale jestli chces patch primo kodu, tak v priloze workaround aby to fungovalo i se stavajicim nsswitch.conf :-P

[pavlix]

V tomhle případě je ta změna sama o sobě trochu málo. Podstatná je přesná specifikace problému a pokud možno poslaná na to správné místo a dále odkazovaná. Chápu, že u Lennarta je zadávání bug reportů jen formalitou, ale to ještě neznamená, že by měl člověk tuto formalitu přeskočit.

[smazáno]

Tim patchem, resp. "patchem", jsem chtel ukazat, ze toto neni technicky problem a sam bych to fixnul behem hodiny i kdyz jsem nss-mdns codebase v zivote pred tim nevidel. Ovsem bez sance prosadit tuto zmenit v upstreamu. Lennart se k tomu vyjadril treba tady.

Co se tyka Ubuntu, tak ten bug byl reportovany uz pred sedmi lety.

[pavlix]

Díky. Pokud jde o konfiguraci, není problém to opravit jak na lokální úrovni, tak na distribuční úrovni. Lennart může mluvit pokud vím jen do upstreamu a do Fedory.

[pavlix]

Jak to tak čtu, tak problém je především v tom, že neexistuje jednoznačný pohled na to, jak to řešit. Lennart je vždy se vším rychle hotový, ale jeho návrh ohledně detekčního skriptu není úplně mimo. Ale určitě nejde jednoznačně říct, jestli je žádoucí přenechat .local na mDNS, na DNS nebo na kombinaci obojího.

[smazáno]

Uplne mimo ten navrh rozhodne neni - a je ocividne uz pekne dlouho implementovany prave v Ubuntu (/usr/lib/avahi/avahi-daemon-check-dns.sh) a predpokladam i v Debianu. Akorat je problem ze ten pristup, narozdil od zbytku sveta (vcetne OS X, ktery s mDNS prisel), ktery ocividne pouziva fallback na DNS, v mnoha pripadech proste nefunguje!

[pavlix]

On ten fallback taky nemusí být vždy nejlepší řešení.

[kavol]

Lennart se k tomu vyjadril treba tady.

hmm ...

The line upstream suggests looks like this:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

This line resembles closely the behaviour MacOSX - the OS which pioneered mDNS - exposes.

- k té výše diskutované debilizaci, mě nepřestává fascinovat, kolik lidí je ochotno naslouchat šmejdovi, co lže, kudy chodí ... jak už bylo v této diskusi zmíněno, masox se nechová tak jak Lennart tvrdí, že se chová (je tam fallback na normální dns, viz např.)

[smazáno]

Na druhou stranu to psal Lennart v roce 2006, OS X 10.5 vysel v roce 2007. Nekdo by mel pingnout Lennarta, a prozradit mu, ze jeho modla, take zmenila pristup k mDNS.

[smazáno]

Jeste jsem nasel tohle, ale to take popisuje pouze, dnes uz predpotopni, OS X 10.6. Podle tohoto dokumentu OS X 10.6 nepouziva DNS fallback, ale pouze DNS pro domeny ve tvaru *.xxx.local a pouze mDNS po domeny xxx.local. (Tento pristup mimochodem resi moje originalni problemy se spatne konfigurovanymi hotspoty protoze ty take pouzivaji domeny tretiho radu - nejspis prave kvuli Apple.)

Celkem by me zajimal soucasny pristup OS X a iOS a opravdu si myslim, ze by Ubuntu a jine linuxove distribuce, ktere chteji byt pouzitelne out of the box meli, v zajmu kompatibility, v tomto pripade chovani apple napodobit (i kdyz to jde proti RFC a muzou s tim byt spojene dalsi problemy) - prece jen desktop linux ma marketshare kolem 1% ne 10%, takze si takoveto vylomeniny nemuze dovolit.

PS: Kdyz jsem googloval jak to OS X a iOS resi tak jsem narazil na ohromne mnozstvi podobnych problemu reportovanych proti temto OS, ale vsechny tyto reporty jsou nekolik let stare.

[kavol]

Na druhou stranu to psal Lennart v roce 2006, OS X 10.5 vysel v roce 2007.

ah, pardon, to mi uniklo, verzování masoxu není moje silná stránka, měl jsem dojem, že vyšel tak před deseti lety (a současně s tím draft na tuto zkriplenost, což se níže odkazuje dokonce na roky 2001-2002); na druhou stranu podobné nesmysly mi tvrdil před dvěma lety, takže ta datace není až tak podstatná

[smazáno]

Jo a apple teda poskytuje mDNS i pro Linux (resp POSIX systemy). A podivaj se jak tam maji nastaveny ukazkovy nsswitch.conf.

Ty zdrojaky jsou celkem sranda

Treba toto z mDNSMacOSX/mDNSMacOSX.c:

mDNSexport void NotifyOfElusiveBug(const char *title, const char *msg)  // Both strings are UTF-8 text
{
    static int notifyCount = 0;
    if (notifyCount) return;

    // If we display our alert early in the boot process, then it vanishes once the desktop appears.
    // To avoid this, we don't try to display alerts in the first three minutes after boot.
    if ((mDNSu32)(mDNSPlatformRawTime()) < (mDNSu32)(mDNSPlatformOneSecond * 180)) return;

    // Unless ForceAlerts is defined, we only show these bug report alerts on machines that have a 17.x.x.x address
    #if !ForceAlerts
    {
        // Determine if we're at Apple (17.*.*.*)
        NetworkInterfaceInfoOSX *i;
        for (i = mDNSStorage.p->InterfaceList; i; i = i->next)
            if (i->ifinfo.ip.type == mDNSAddrType_IPv4 && i->ifinfo.ip.ip.v4.b[0] == 17)
                break;
        if (!i) return; // If not at Apple, don't show the alert
    }
    #endif

    LogMsg("%s", title);
    LogMsg("%s", msg);
    // Display a notification to the user
    notifyCount++;

#ifndef NO_CFUSERNOTIFICATION
    mDNSNotify(title, msg);
#endif /* NO_CFUSERNOTIFICATION */
}

[Sten]

Tak proč jsi to tu nenapsal?

[smazáno]

Prvni cast tveho prispevku - presne to pisu v tom blogu.

Druha cast tveho prispevku - napsal pavlix do komentaru.

Proto ta moje, dobre, priznavam, agresivni, reakce.

[Sten]

Kde v tom blogu je napsáno, že stačí odstranit [NOTFOUND=return]? Já to tam teda nevidím.

[Bystroushaak]

Proto ta moje, dobre, priznavam, agresivni, reakce.

To je to, co se s abíčkem stalo. Agresivní reakce na úplně konstruktivní příspěvek, který bude díky google pravděpodobně užitečnější, než celý ten blog.

[zakouti]

+1

[luv]

Konstruktivni jak prase .... nic uz to tady na abicko radeji balim teda.

[luv]

Hele ja nejsem jen nakej cu*rak co si stezuje a je agresivn, onehda jsem st avil asi pet dnu v gdb abych vyresil jeden bug v ubuntu abych pomohl vytvorit ideálni system pro end usery a pak narazim na problemy kvuli idiotske politice a tvrdohlavosi s kteryma se neda nic delat a misto podpory tohle. Linux for human beings???? To tezko.

[Bystroushaak]

Ty hlavně nejsi registrovaný luv, takže nikoho nezajímáš.

[igor]

To máš těžký, ty zase nikoho nezajímáš, ani když jsi registrovaný

[kavol]

Chyba je nicméně u provozovatelů těch hotspotů, že používají TLD .local, která jim nepatří a je vyhrazena pro jiné účely.

jasně, už víc než rok, co se Applu povedlo protlačit tenhle zmetek, takže honem všichni musí běžet změnit léta funkční konfigurace, jen aby vyhověli neschopnosti IETF odmítnout RFC, které nerespektuje "první přijde první mele", tedy mění použití něčeho již zaužívaného ...

[Sten]

Problém je, že používají doménu, která jim nepatří. A to se netýká jen .local, mohli používat třeba .house, která je od loňska taky registrovaná TLD. Vyhrazená doména pro tohle je .test.

[smazáno]

Ani ne poslys - i kdyby ten hotspot pouzil treba rozbijemevsechno.cz, tak by to furt fungovalo .

[Sten]

A co kdyby používal google.com?

[pavlix]

+1

[luv]

Tak by furt valilo vsechno krome google.com a furt bych si ten email poslat mohl a i ten prikaz v bance zadat coz jsem takhle nemohl!!

[Sten]

No, to záleží. Stačilo by, abyste měl zapnuté DNSSEC, a fungovat to nebude. A nebude fungovat ani .local.

[kavol]

Problém je, že používají doménu, která jim nepatří.

to samé se dříve dalo říci o bonjour/avahi taky, zajímavé, že to nikdo jako protiargument nepoužíval (resp. nevšiml jsem si)

A to se netýká jen .local, mohli používat třeba .house, která je od loňska taky registrovaná TLD.

irelevantní, .house nebyla narozdíl od .local zaužívaná doména před uvolněním TLD - taky mohli jezdit červeným mercedesem, že ...

Vyhrazená doména pro tohle je .test.

WTF, co je tohle za dezinterpretaci?

      ".test" is recommended for use in testing of current or new DNS
      related code.

[RFC2606]

[Sten]

to samé se dříve dalo říci o bonjour/avahi taky, zajímavé, že to nikdo jako protiargument nepoužíval (resp. nevšiml jsem si)

V době nasazení Bonjour už existovaly drafty, které to jméno vyhradily. Ono to RFC nevzniklo přes noc, jeho první draft je z roku 2001 a vyhrazení .local je tam od roku 2002.

irelevantní, .house nebyla narozdíl od .local zaužívaná doména před uvolněním TLD

Irelevantní

WTF, co je tohle za dezinterpretaci?

".test" is recommended for use in testing of current or new DNS related code.

[RFC2606]

RFC 2606 bylo nahrazeno RFC 6761, které využití .test nijak neomezuje. Pokud chcete nějakou doménu mimo globální registr, máte jenom tuto.

Mimochodem ve vámi odkazovaném RFC 2606 je celkem jasně napsáno toto:

[…] a site might set up some local additional unused top level domains for testing of its local DNS code and configuration. Later, these TLDs might come into actual use on the global Internet. As a result, local attempts to reference the real data in these zones could be thwarted by the local test versions.

Což je přesně to, co se stalo zde a co byste neměl dělat.

[kavol]

to samé se dříve dalo říci o bonjour/avahi taky, zajímavé, že to nikdo jako protiargument nepoužíval (resp. nevšiml jsem si)

V době nasazení Bonjour už existovaly drafty, které to jméno vyhradily.

když pošlu IETF draft, ve kterém bude, že mi máš zaplatit korunu za každé písmenko, co na webu napíšeš, budeš se jím řídit?

Ono to RFC nevzniklo přes noc, jeho první draft je z roku 2001 a vyhrazení .local je tam od roku 2002.

díky za upřesnění datace, nicméně i v roce 2002 (a už dávno předtím) se .local nebo .localnet hojně používalo; o to větší ostuda IETF to je, že se s tímto problémem za jedenáct let od návrhu k přijetí nedokázali vypořádat

WTF, co je tohle za dezinterpretaci?

      ".test" is recommended for use in testing of current or new DNS
      related code.

[RFC2606]

RFC 2606 bylo nahrazeno RFC 6761, které využití .test nijak neomezuje.

co kdybys konečně přestal mlít nesmysly? - RFC6761 nic nenahrazuje, pouze aktualizuje (doplňuje) ... pokud máš problém rozumět slovu "updates" (resp. rozdílu proti "obsoletes"), a obecně anglicky (vysvětluje se to dále v sekci Introduction), tak se nejprv douč jazyk

Pokud chcete nějakou doménu mimo globální registr, máte jenom tuto.

nemáme ani tuto (.test), protože ta je vyhražena pro testování, nikoli pro provoz lokálního namespace; platí totéž co výše, je ostudou IETF, že se s tím za ta léta nedokázali vypořádat a něco nabídnout, a naopak neberou ohled na praxi a jdou proti tomu, co se stalo neformálním standardem

Mimochodem ve vámi odkazovaném RFC 2606 je celkem jasně napsáno toto:

[…] a site might set up some local additional unused top level domains for testing of its local DNS code and configuration. Later, these TLDs might come into actual use on the global Internet. As a result, local attempts to reference the real data in these zones could be thwarted by the local test versions.

Což je přesně to, co se stalo zde a co byste neměl dělat.

no, zjevně tedy skutečně neumíš anglicky anebo i obecně porozumět textu, protože problém popsaný v blogu se netýká "testing of its local DNS code and configuration"

[PavelC]

₊+₊ 1

[Sten]

když pošlu IETF draft, ve kterém bude, že mi máš zaplatit korunu za každé písmenko, co na webu napíšeš, budeš se jím řídit?

Ne, protože drafty RFC vydávají pracovní skupiny IETF, ne jen tak někdo.

díky za upřesnění datace, nicméně i v roce 2002 (a už dávno předtím) se .local nebo .localnet hojně používalo; o to větší ostuda IETF to je, že se s tímto problémem za jedenáct let od návrhu k přijetí nedokázali vypořádat

no, zjevně tedy skutečně neumíš anglicky anebo i obecně porozumět textu, protože problém popsaný v blogu se netýká "testing of its local DNS code and configuration"

IETF nikdy nepředpokládalo, že budete používat takové TLD na něco jiného než testování vaší lokální DNS, a podle toho se chová. Každý, kdo používal neoficiální TLD, to dělal na vlastní riziko, že jednou ta TLD může být delegovaná. Tohle se nezměnilo, např. již RFC 1918 specifikuje nastavení, kdy pro privátní adresy je používána globálně registrovaná doména, ale vůbec neuvádí případ, kdy by pro lokální adresy byla vlastní TLD.

[kavol]

když pošlu IETF draft, ve kterém bude, že mi máš zaplatit korunu za každé písmenko, co na webu napíšeš, budeš se jím řídit?

Ne, protože drafty RFC vydávají pracovní skupiny IETF, ne jen tak někdo.

pracovní skupina "Stuart Cheshire, Apple Computer, Inc."? - takže když si do podpisu připojím zaměstnavatele, tak už jo?

IETF nikdy nepředpokládalo, že budete používat takové TLD na něco jiného než testování vaší lokální DNS, a podle toho se chová.

za prvé, toto tvrzení je v rozporu se současnou situací, jestliže právě zavedlo .local, který bonjour používá právě "na něco jiného než testování vaší lokální DNS"

za druhé, kdyby tomu tak skutečně bylo (resp. jestli tomu tak je s výše uvedenou vyjímkou), tak je to prostě chyba, nereflektuje to reálné potřeby (abychom nebyli jen u .local/.localnet, tak co třeba .uucp ...)

[Ondrej 'SanTiago' Zajicek]

Ne, protože drafty RFC vydávají pracovní skupiny IETF, ne jen tak někdo

Drafty RFC mohou vydavat jak pracovni skupiny IETF, tak nezavisle osoby. V prvnim pripade se pouziva jmeno draft-ietf-<wg>-..., v druhem draft-<person>-... . Drafty pro RFC 6762 podle jmena vypadaji jako osobni drafty Cheschira, aniz by ten dokument sel pres nejakou IETF working group, coz je ale zrejme kvuli tomu, ze dnsext WG je neaktivni.

[Sten]

Tohle je ale draft-cheshire-dnsext-multicastdns

dnsext WG je neaktivní od července 2013

[Ondrej 'SanTiago' Zajicek]

Ano, a kdyby slo o draft, ktery by byl pracovnim dokumentem wg dnsext, tak by se jmenoval draft-ietf-dnsext-multicastdns.

Viz treba draft-uttaro-idr-add-paths-guidelines (drivejsi navrh) a draft-ietf-idr-add-paths-guidelines (po prijeti za pracovni dokument wg idr).

[smazáno]

A jeste bych doplnil, ze ani ta soucasna Lennartova implementace mDNS patricne RFC stejne nedodrzuje .

[pavlix]

To bych ani neočekával ;).

[frdrx]

Zeman za to může, ne Poettering.