DNS - 2. část

tentokrát o větách RR a negativním cachingu

Věty RR

Informace o doménových jménech a jejich IP adresách, stejně jako všechny ostatní informace DNS záznamu jsou uloženy v paměti DNS serverů ve tvaru zdrojových vět (Resource Records - RR).
Name server naplňuje svou paměť několika způsoby:

• autoritativní data načítá ze souborů na disku, nebo je získá dotazem "zone transfer" z paměti jiného serveru
• neautoritativní data získává postupně z paměti jiných serverů (vyřízením jednotlivých dotazů)

Resolver při získávání dat požaduje po name serveru věty RR dle zadaných požadavků (klient např. může chtít po serveru věty RR typu A, které obsahují IP adresy pro danou doménu).

Jednotlivá pole vět RR obsahují:

• NAME - doménové jméno
• TYPE - typ věty
• CLASS - třída věty
• TTL - time to live - 32bitové číslo udávající dobu, po kterou může být tento RR udržován v cache serveru jako platný. Po vypršení doby je věta považována za neplatnou. Hodnota 0 znemožňuje neatoritativ. ser. uložit RR do cache.
• RDLENGTH - 16bitové číslo specifikující délku pole RDATA
• RDATA - vlastní data ve tvaru řetězce proměnné délky. Formát závisí na typu a třídě RR

Struktura věty RR
NAME - TYPE - CLASS - TTL - RDLENGTH - RDATA
       věta typu A => IP-adresa
       věta typu TXT => Textový řetězec
       věta typu NS, CNAME a PTR => Doménové jméno (NAME)
       věta typu MX => Doménové jméno (NAME)

Nejčastější typy vět RR

Typ	Anglický výraz	Význam pole RDATA
A	A host name	32bitová IP adresa
NS	Authoritative name server	Doménové jméno NS, který je autoritou domény
CNAME	Canonical name for an alias	Doménové jméno spec. synonymum k NAME
SOA	Start of authority	Právě jedna věta SOA uvozuje každou zónu (7 polí)
PTR	Domain name pointer	Doménové jméno (používá se pro reverzní překlad)
HINFO	Host information	Popis SW a HW používaného na PC NAME
MX	Mail Exchange	Preference a doménové jméno mail serveru
TXT	Text string	Textový řetězec s popisem
AAAA	IP6 adress	128bitová IP adresa (IP verze 6)

Protokol DNS

U dotazů na překlad (žádosti o RR záznam) je dána přednost protokolu UDP. V případě, kdy je DNS odpověď delší než 512 B, vloží se do odpovědi pouze část informací nepřesahující danou hodnotu a záhlaví je nastaven bit TC specifikující, že se jedná o neúplnou odpověď. Klient si poté může kompletní odpověď vyžádat protokolem TCP.

Pro přenos zón např. mezi primárním a sekundárním name serverem se používá protokol TCP. Name server standartně očekává dotazy jak na portu 53/udp, tak také 53/tcp.
Dotaz i odpověď jsou přenášeny vždy shodným protokolem.

Komprese

Komprese je využívána k redukci velikosti DNS paketu. V DNS paketu se může doménové jméno vyskytnout opakovaně, komprese toto opakující se jméno uvede pouze jednou a každý další výskyt je nahrazen ukazatelem na první výskyt.

Inverzní dotaz

Nezaměňovat s reverním dotazem. Při inverzním dotazu se také např. překládá IP adresa opět na jméno, ale k vyhledávání se použijí věty typu A, nikoliv PTR. Inverzní dotazy nemusí být name serverem podporovány.

DNS Update

... umožňuje dynamicky opravovat záznamy v DNS databázi (přidání/vyjmutí jedné či více vět RR). Záznamy již nemusí staticky opravovat správce serveru, ale je možné záznamy v NS databázi opravit dynamicky na dálku pomocí příslušného klienta a protokolu DNS. Data v zóně lze pomocí DNS Update opravovat pouze na primary master serveru. Pokud DNS Update dotaz obdrží slave server, pak je tento forwardován primary master serveru. DNS Update neumožňuje vytváření nových zón, umožňuje pouze opravovat zóny již existující. Pomocí DNS Update tedy nelze přidávat/rušit SOA větu, pouze upravit. Jedním DNS Update dotazem lze opravit jednu nebo několik vět v jedné zóně. Opravu lze provést za určitých podmínek (existence či absence určitých RR vět). Podmínky jsou vyhodnoceny jako celek (není-li splněna jedna == nevyhovující). V DNS paketu jsou zvlášť uvedeny podmínky za kterých jsou provedeny opravy zvlášť RR věty, které se mají do zónového souboru přidat, nebo zrušit. Paket DNS Update obsahuje:

• záhlaví
• sekce zóny - definuje zónu, ke které se vztahují opravy
• sekce předpokladu - sada RR vět, které musí v zóně existovat
• sekce update - sada RR vět, které se mají opravit nebo zrušit
• sekce doplňkových informací - informace jež nejsou součástí update, ale jsou třeba k provedení

Negativní caching (DNS NCACHE)

Uložení informací v paměti serveru o tom, že neexistuje v DNS požadovaná RR věta nebo doménové jméno. Dnes užívané resolvery negenerují shodné odpovědi na stejný dotaz. Aby bylo možné negativní caching korektně používat, je třeba přesně definovat obsah negativní odpovědi a dobu, po kterou má být negativní odpověď udržována v paměti. Dle RFC1034 je negativní caching definován jako nepovinný. Některé implementace BINDu negativní caching podporují (např. BIND 4.9.2. a vyšší).

Negativní odpovědi ukládané do paměti

Povinné:

• Name error (NXDOMAIN) - Doménové jméno uvedené v QNAME dotazu neexistuje. RCODE je nastaveno na NXDOMAIN. Autoritativní sekce může obsahovat SOA větu a NS věty
• NOERROR_NODATA - RCODE nastaveno na NOERROR, ale sekce odpovědí neobsahuje žádný RR record. Autoritativí sekce může obsahovat SOA větu a NS věty

Ostatní typy jsou odpovědí jsou nepovinné, např.:

• Server failure - Server neposkytuje data o zóně z důvodu chybné konfigurace zóny, nebo nedostupnosti master serveru pro zónu.
• Dead / Unreachable server - Server neexistuje, nefunguje nebo není dostupný

Odpovědi nepovinné jsou udržovány v paměti po dobu max. 5 minut. Součástí ukládané informace musí být IP adresa serveru z odpovědi.

Délka udržení negativní odpovědi v paměti

Všechny věty RR uložené v paměti jsou považovány za platné, pokud mají TTL větší než 0. TTL je tedy rozhodující položka vzhledem k paměti. I negativní odpovědi, pokud mají být udržovány v paměti, musí mít definováno TTL (určení TTL pro negativní odpověď se řeší vložením SOA věty pro zónu do autoritativní sekce odpovědi).

Pole MINIMUM ve větě SOA

Interpretace:

• Minimum TTL pro všechny věty RR v zóně (nepoužíváno)
• Implicitní TTL pro všechny věty RR v zóně, které neobsahují TTL pole (možno pouze na primárním name serveru, po transferu TTL pole doplněno)
• TTL negativní odpvoědi pro zónu

Dále budeme uplatňovat pole MINIMUM ve větě SOA ve významu 3. TTL pro jednotlivé RR věty musí být definováno přímo v RR větách, nebo pomocí příkazu $TTL v zóně souboru.
Syntaxe:
$TTL ttl komentář => Všechny RR věty uvedené v souboru za příkazem $TTL, které nemají TTL uvedeno jej přebírají

Reálné TTL se určuje jako minimum z pole TTL obsaženého v SOA větě a z pole MINIMUM. TTL se u negativních odpovědí v paměti snižuje stejným způsobem jako u kladných odpovědí. Pokud je TTL u negativní odpovědi 0, je informace v paměti neplatná.

Pravidla ukládání negativních odpovědí

• ukládání negativních odpovědí je povinné (ukládá-li server odpovědi pak kladné i záporné)
• neautorizované negativní odpovědi nemohou být ukládány
• v paměti musí být uložena i věta SOA z autoritativní sekce odpovědi
• negativní odpověď bez věty SOA nesmí být ukládána
• věta SOA z paměti musí být přidávána do odpovědi
• odpověď NXDOMAIN musí být ukládána spolu s QNAME a QCLASS
• odpověď NOERROR_NODATA musí být ukldádána spolu s QNAME, QTYPE, QCLASS
• v master souboru musí být vložen příkat $TTL