Richard Willmann napsal/wrote, On 11/19/09 06:31:
prosim, pravdepodobne iba hladam na nespravnom mieste ale ani po dlhsom
snazeni sa mi nepodarilo najst odpoved na otazku, ako velky moze byt TXT
RR a co moze obsahovat.
Zacneme delkou:
1) ----------------------------------------
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
2) ----------------------------------------
3.2.2. TYPE values
...
TXT 16 text strings
3) ----------------------------------------
<character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
4) ----------------------------------------
3.3.14. TXT RDATA format
+--+--+--+--+--+--+
| TXT-DATA |
+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
===========================================
Takze [1] rika, ze celkova delka ulozenych dat je az 2**16 a jde o [2,4]
jeden nebo vice retezcu pricemz retezec je [3] 1 byte delky nasledovany
udanym poctem byte retezce.
Delka je tedy specifikovana pomerne jasne - TXT obsahuje retezce
delimitovane udanou delkou ; delka jednoho retezce je max 256 znaku
(vcetne byte delky) a celkova velikost techto retezcu se musi vejit do
65535.
Jen na okraj - nestrukturovany obsah RDATA (raw data do delky 65535) ma
NULL RR
Osobne si myslim, ze "gramatika" je 8 bitova.
Ano, z hlediska protokolu jsou klic i hodnota v databazi RAW data.
DNS je opravdu genericka distribuovana databaze. Dokonce i v klici muze
vetsinou byt libovolny z 256 znaku (viz 3.1: "Although labels can
contain any 8 bit values in octets ...")
Pouze u nekterych klicu a typu zaznamu je definovan vyznam - a teprve
tato definice muze pripadne dal omezit mnozinu pripustnych znaku jak v
klici tak v hodnote.
V RFC 1035 nie je o limite ziadna zmienka
Ale je. V 3.2.1 mas jasne definovany format RR z nehoz plyne, ze delka
je promenliva, maximalni vsak je NAME+10+65535 pricemz na jinem miste se
zminuje, ze maximalni delka NAME je 255 - to mame, prostym poscitanim,
65800B na jeden RR
Dale mas ve [4.1] definovany tvar zpravy, kterou se poklada dotaz i
zasila odpoved. Ta ma 12B hlavicky nasledovane ctyrmi skupinami RR
jejichz pocet je vyjadren sestnactibitovym cislem.
Zadny limit na velikost teto zpravy (krome limitu daneho maximalni
velikosti RR a jejich maximalnim poctem v jedne zprave) konstatovan neni
- to znamena, ze odsud nam zadne omezeni na velikost jednoho RR neprichazi.
Pak uz zde mame jen:
-------------------
Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers). Longer messages are truncated and the TC bit is set in
the header.
-------------------
Zanedbame-li pozdejsi rozsireni protokolu, ktere umoznuji limit 512B
posunout na jine cislo nicmene existenci limitu o nejake velikosti
zachovavaji pak citovany odstavec znamena jen tolik, ze delsi zpravy
NEBUDOU prenaseny transportnim protokolem UDP. Jelikoz transportni
protokolu jsou definovane dva, zbude to na ten druhy - a to je TCP. To
nema zadne omezeni na velikost jedne prenasene zpravy (protoze neprenasi
zpravy ale stream) a tudiz i tech teoretickych 257kB (kdyby ve zprave
byl maximalni pocet RR o maximalni velikosti) zvladne.
Zaver ? Do TXT RR jde dat tolik retezcu (o delce max 255 B/retezec)
kolik se jich vejde do celkove velikosti 65535B.
=======================================================
=======================================================
Tak a ted zase trochu zpatky na zem. RFC1035 vzniklo pred dvaceti lety.
Napriklad RFC definujici to, jak prisny pozadavek je, kdyz se rekne, ze
se neco ma, musi nebo muze je o celych deset mladsi. Tim chci rict, ze
RFC1035 je RFC ze "stare doby" a nebylo vytvareno jako technicka norma.
A tudiz nelze cekat, ze ho za technickou normu nekdo povazoval. V te
dobe se za implicitni a nevyslovovanou podminku melo pouziti selskeho
rozumu. Nakonec - vsichni, kdoz byli schopni vytvorit neco, co by melo
na Internetu globalni dopad se znali nebo prinejmensim snadno znat
mohli. DNS, ac navrzen jako genericka databaze, nikdy nezacal byt siroce
pouzivan mimo oblast distribuce informaci k domenovym jmenum. S jen
trochou predvidavosti lze ocekavat, ze ruzne implementace jak na strane
serveru (autoritativnich i mezilehlych cacheujicich) tak na strane
resolveru budou mit vlastni omezeni, ktera nijak nenarusuji moznost
prenaset informace tykajici se domenovych jmen a zaznamu tech par bezne
pouzivanych typu. V horsim pripade bude "implemetacni omezeni" toho
typu, ze se na to programator uplne vykaslal a kod bude pri pruchodu
"neobvyklych zaznamu" primo padat.
Dobre je to videt na prikladu "nastup IPv6" - nektere nameservery
reaguji na dotaz po AAAA (pro ne neobvyklem typu) odpovedi, ktera
zpusobi, ze se resolver uz na A zaznam nezepta a IP (v4) adresa jmena,
prestoze existuje, tak neni jen proto, ze resolver zacal dotazem na IPv6
adresu vubec nalezena.
Pri ukladani binarnich dat do DNS se tedy muzes potkat s ruznymi
"nahodnymi problemy"
Dalsi prakticka potiz te potka v souvislosti s tou delkou. Mnoho
takyadministratoru si nepovsimlo, ze DNS ma jako transportni vrstvu
definovano nejen UDP, ale take TCP - a to pro dotazy jakehokoliv typu,
nejen AXFR. On taky dneska dela spravce site kdejaky stredoskolak, co
dokaze stahnout CD a mysi naklikat instalaci a konfiguraci Linuxu.
Neni az tak vyjimecne, ze pruchod TCP/DNS je firewallem blokovan
(protoze spravce nevi, ze tohle blokovat ale fakt nemuze). Pres takovy
firewall jakakoliv delsi (a tedy non-UDP) odpoved proste neprojde.
Take muzes narazit docela obycejne na to, ze ten konkretni DNS server,
ktery hodlas pouzit, ma nejake interni limity tykajici se delky jednoho
RR a/nebo jedne zpravy (dotaz/odpoved). Mam dojem, ze treba jeste BIND
8.2 mel limit neco okoli 2kB. Jestli devitka ma jiny nebo zadny - to nevim.
=======================================================
Odpoved na dotaz jsi dostal. Ale dostanes i nevyzadanou radu - at
premejslis nad cimkoliv, vykasli se na to a najdi jiny zpusob jak
binarni data distribuovat.
No, na to, ze jsme zde na hranici prijatelnosti tematu jsem se docela
rozkecal.
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
