TXT RR

[Dan Lukes]

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