DNS odpoved, authority section

Dan Lukes dan at obluda.cz
Sun Nov 25 23:42:15 CET 2007


Radim Kolar wrote:
> zajimalo by mne zda jsou v dns reply vyzadovany nebo doporucovany
> zaznamy v authority section, nenasel jsem zadne dokumenty co to
> popisuji, pripadne dokumentaci popisujici doporucovane postupy v DNS.
> 
> studuji rfc1035.

RFC1035 je "implementace". Principy jsou 1034, takze je asi lepsi zacit tou.

> podle mne je to zbytecne posilat u normalnich dotazu, pokud se to
> nepouziva k delegaci dotazu na jiny ns, protoze klient ocividne adresu
> a jmeno NS zna, kdyz tam ten dotaz
> poslal.

	Do AU sekce patri autoritativni nameservery. Presne receno "ostatni 
autoritativni nameservery". To, ze se klient pta *nejakeho* nameserveru 
neimplikuje, ze nejaky autoritativni nameserver pro danou zonu zna a i v 
pripade, ze se pta nejakeho autoritativniho, neni jasne, ze zna i 
ostatni autoritativni nameservery.

	Mohli bychom se zeptat, zda takovou informaci k necemu potrebuje, ale 
tak otazka, rekl bych, neznela. Otazka znela - ci rika RFC o obsahu AU 
sekce.

  -- RFC1034 3.7 --------------
...
The four sections are:
...
Authority   Carries RRs which describe other authoritative
             servers. May optionally carry the SOA RR
             for the authoritative data in the answer
             section.
...
  -----------------------------

	Striktni vyklad by tedy byl, ze neautoritativni server uvede vsechny 
autoritavini nameservery; autoritativni server uvede vsechny krome sebe. 
SOA udaj je nepovinny.

	Praxe byva trochu jina, i autoritativni nameservery uvadeji typicky 
vsechnu autoritativni nameservery, tedy vcetne sebe.

> djbdns:
> ;; QUESTION SECTION:
> ;www.karneval.cz.               IN      A
> 
> ;; ANSWER SECTION:
> www.karneval.cz.        10641   IN      A       62.24.68.107

	Dle meho je takova odpoved chybna.


> bavit, djbdns ma taky podezrelou licenci, kod je dost zpraseny a navic
> je to v Cecku, tedy velka chybovost, nizka bezpecnost, draha udrzba.

	Chyby jsou vzdycky vec programatora a je na nem aby si vybral takovy 
jazyk v jakem dokaze psat slusne. Neschopny programator napise program 
prasacky v jakemkoliv jazyku, schopny programator znaly jazyka ho napise 
slusne i v tom cecku - a pokud dany problem v C rozumne resit neumi, tak 
si ho pro reseni nevybere.

	Svadet chyby v kodu na programovaci jazyk je v kazdem pripade vymluva 
neschopneho programatora. Nicmene, o tom se tady asi hadat nechceme a 
nebudeme. A ani o licenci ne.

	Co se tyce djbdns-brand programu, moje zkusenost je, ze jejich 
programator je velmi schopny programator, lec ponekud sverazny. Kdysi 
jsem se s nim utkal na tema qmail a non-RFC compliant SMTP protokol a 
DJB mel v zasade jasny postoj - odchylky od RFC si je vedom. Podle nej 
je chybne prislusne RFC a spravne melo byt napsano tak, jak on kod 
implementoval. Opraven tedy nema byt jeho program, ale prislusne RFC. 
Nepripoustel na toto tema zadnou diskusi.

	Nevim, zda v pripade djbdns jde ci nejde o podobny pripad, ale kdyby 
slo, s ohledem na vyse ucinenou osobni zkusenost by me to neprekvapilo.

	Ja k tomu muzu rict jen tolik, ze jeho postoj chapu, ma plne pravo 
napsat svuj software jak uzna za vhodne a to, co je vysledkem vedome 
uvahy by nemelo byt vykladano jako chyba a jeho neschopnost (natozpak 
chyba programovaciho jazyka). Na druhou stranu, ja mam pravo programy 
psane s touto filosofii, ktera mi nevyhovuje, nepouzivat - coz take 
cinim. Vybral jsem si proste implementace jinych autoru jejichz postoj 
vuci vseobecne prijimanym doporucenim je vstricnejsi.

	Doporucuji ti zvazit totez.

						Dan



More information about the Users-l mailing list