NIC a AXFR (was Re: ACL v BINDU - vyznam...)

[Martin `MJ' Mares]

Hello, world!\n

Pokusim se shrnout sve nazory na nektere momenty uplynule diskuse
o AXFR.  Jelikoz zadne RFC ani jiny dostatecne autoritativni dokument
nijak jasne nerika, jak jsou name servery povinny se chovat, doufam,
ze mi ctene obecenstvo odpusti ton spise filosoficky.

Osoby a obsazeni:

	PN == Petr Novotny <Petr.Novotny na antek.cz>
	MK == Michal Krause <mike na navrcholu.cz>

Dejstvi prve aneb Proc povolovat?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PN> Tohle je teziste me argumentace - ne "Proc zakazat", ale "Proc 
PN> povolit".

   AXFR je zcela standardni soucasti protokolu DNS (samozrejme nikdo nikde
nerika, ze povinnou), takze opravdu nevidim zadny duvod, proc by defaultni
stav mel byt `zakazat'.  To je srovnatelne s tim, kdybyste svuj nameserver
nakonfiguroval tak, ze zasadne nebude odpovidat na dotazy z nejake site
a argumentoval tim, ze to preci nikde nikdo neprikazuje a proc by to tedy
melo byt povolene.

PN> To je vec nazoru. Ja treba nevim, proc bych ho mel povolovat. 
PN> Stejne tak mam na firewallu zakazany porty 135-139 na "ochranu" 
PN> windowsu ve vnitrni siti, i IP spoofing. Taky bych to zakazovat 
PN> nemusel...

   Ale to je preci neco uplne jineho. To, jak "bezpecna" jsou Windows, vsichni
dobre vime a prave to je asi duvod, proc mate tyto porty na firewallu zakazane.
Na druhou stranu jeste stale nikdo nenadhodil zadne bezpecnostni riziko, ktere
by mohlo byt zpusobene povolenim AXFR.

PN> Jeho povoleni neni povinnou soucasti. Stejne tak je soucasti SMTP 
PN> open relay - a naopak vsichni blokuji stroje, ktery ho maji povolen.

   To neni tak docela pravda, open relay neni soucasti protokolu SMTP. Tato
specifikace (a dokumenty pribuzne) rika myslim dosti jasne, jakym zpusobem
se maily routuji, z cehoz mimo jine take vyplyva, ze na mail-server se mail
muze dostat budto tak, ze jej tam posle nejaky MX record nebo ze je pouzit
explicitni routing. Takze nikde nikdo nehovori o tom, ze by mail server
mel byt schopen akceptovat postu pro nekoho uplne jineho, tudiz ma plne
pravo takovou postu odmitnout. Blokovani relayingu ma v tomto kontextu
velice jasny vyznam: je to jednoducha ochrana proti nespravne nakonfigurovanemu
(at jiz umyslne ci neumyslne) mail routingu a kohokoliv, kdo protokol
SMTP pouziva korektnim zpusobem, nikterak neomezuje.


Dejstvi druhe aneb Internet ecology
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PN> A co tim AXFR zkontroluje? Bude rekurentne prochazet i 
PN> subdomeny, a hledat konzistentnosti v forward<->reverse DNS 
PN> lookupech? Bude zkouset, zda stroje, ktere jsou v DNS uvadeny, 
PN> existuji? Zkousi vubec, zda nekdo na adrese v SOA cte maily a 
PN> rozumi jim? Jestli ne, tak zkouska s AXFR neprinasi zadnou 
PN> dodatecnou kontrolu kompetentnosti adminu.

MK> Tady s tebou ovsem nesouhlasim. Pokud je pri registraci domeny provedena
MK> zakladni kontrola zaznamu, urcite to prispiva k dobre funkcnosti Internetu
MK> jako celku. Nevim, jake mas zkusenosti ty, ale ja osobne vim, ze bordel v DNS
MK> muze zpusobovat (a zpusobuje) mnoho komplikaci, stejne jako nedodrzovani
MK> mnoha jinych standardu. Navic, CZ NIC odpovida za provoz domeny .cz a jako
MK> takovy ma podle mne pravo kontrolovat subdomeny v ni.

   V dnesnim Internetu se o mnohe servery (a o DNS to, myslim, plati dvojnasob)
staraji lide, kteri prislusna RFC nevideli ani z dalky, natoz pak aby si je
pozorne precetli a pochopili, jaka je filosofie DNS a jak DNS funguje. A na tom
uz asi nikdo nic nezmeni. Proto take potkavame cim dal tim vice domen s fatalne
nekonsistentnimi zaznamy, ktere v dusledku komplikuji zivot vsem.

   To, ze NIC pri registraci domeny vyzaduje, aby prosla urcitymi testy,
samozrejme tuto neprijemnou situaci nevyresi, nicmene ji to alespon ma urcitou
sanci zlepsit, coz je samo o sobe chvalyhodne. A nezalezi na tom, jestli
automaticke testovani odhali opravdu vsechny mozne chyby -- samozrejme, cim
vice, tim lepe, ale lepsi neco nez nic (!= NIC).

   Ostatne, CZ NIC neni sam, kdo se teto strategie drzi -- jeho francouzska
obdoba to jiz dela leta. A kuprikladu GTS poskytuje svym zakaznikum sekundarni
name-server zdarma, nicmene za podminky, ze obsahuje konsistentni recordy,
a to podle testu mnohem tvrdsich nez tech NICovskych.

PN> To je dobre. Jeste by mel udelat kontrolu SMTP, WWW, zjistit, 
PN> zda nepouziva derave verze programu, atd.

   Procpak? Vzdyt NIC se ma starat o DNS a o nic jineho.

PN> Je to hrube nad ramec toho, co ma delat - registrovat domeny. 
PN> Podminkou registrace (technickou) by mela byt existence 
PN> funkcnich nameserveru.

   Vzdyt take je. Ale nikoliv podminkou postacujici.


Dejstvi treti aneb K cemu AXFR?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MK> Na druhou stranu si ale nejsem ani uplne jisty, jestli souhlasit s Martinem a
MK> povolovat AXFR uplne vsem. Myslim, ze minimalne za urcitych okolnosti neni od
MK> veci jej zakazat (napriklad kdyz nechci, aby si nekdo vylistoval vsechny
MK> domeny tretiho radu apod.). 

   AXFR samozrejme pro "zivot" Internetu neni nezbytne, ale myslim si, ze
zde je spousta pripadu, v nichz poskytuje neocenitelne sluzby. Namatkove:

o  Vyhledavaci stroje -- spousta programu pro automaticke indexovani dokumentu
   ziskava sve znalosti o dokumentech primarne z DNS, na coz ovsem je AXFR
   nutnou podminkou.  [Zde muzete namitnout, ze preci NIC publikuje kompletni
   dump domeny .cz na svem FTP serveru -- ale tim spise nic nezachranite
   zakazem AXFR.]

o  Approximative search -- nevim jak vam, ale mne uz se nekolikrat stalo,
   ze jsem znal jmeno nejakeho pocitace, na ktery jsem chtel poslat mail,
   pouze velice priblizne, takze jsem si vylistoval prislusnou domenu
   a jmeno hrave nalezl.


Opona
~~~~~
				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj na ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice."    -- Albert Einstein