DNS

Hlavička

Hlavička zprávy je stejná jak pro požadavek, tak pro odpověď. Jsou však některá pole, která jsou platná pouze pro odpověď nebo požadavek.

Hlaviča DNS zprávy obsahuje následující informace:

QR

Zda se jedná o požadavek (0) nebo odpověď (1)

OPCODE

Zda se jedná o dotaz (0), inverzní dotaz (1) nebo dotaz na status serveru (2)

AA

Zda je zpráva autoritativní (Pouze u odpovědi)

TC

Zda byla zpráva zkrácena z důvodu překročení limitu přenosového protokolu (Pouze u odpovědi)

RD

Zda si klient přeje provézt rekurzivní požadavek. U odpovědi je hodnota příznaku stejná jako u požadavku.

RA

Zda server poskytuje rekurzivní překlad

AD

Zda je odpověď validována DNSSEC

DO

Zda si klient přeje validovat DNSSEC

RCODE

Stavový kód odpovědi (Pouze u odpovědi)

QDCOUNT; ANCOUNT; NSCOUNT; ARCOUNT

Uvádí počet záznamů v jednotlivých sekcích

Sekce

Zpráva v protokolu DNS má následující sekce:

Question

Dotaz/y na překlad doménového jména, požadovaný typ záznamu a třídu záznamu (např. IN = Internet)

Answer

Odpověď/i na dotaz

Authority

Záznamy ukazující na autoritativní jmenný server

Additional space

Záznamy poskytující doplňující informace k dotazu, ale nejsou odpovědí na dotaz samotný

Sekce Answer, Authority a Additional space využívají stejný formát záznamu a to:

Name

Přeložené doménové jméno

Type

Typ záznamu

Class

Třídu záznamu

TTL

Jak dlouho může být tato odpověď uchována a používána. Pokud je uvedena 0, tak je tato odpověď validní pouze pro tento samostatný dotaz. Jedná se 32bitové nezáporné číslo.

RDLENGTH; RDATA

Dvojice specifikující délku dat odpovědi a data odpovědi. Formát odpovědi je závislý na typu záznamu a třídě záznamu. Délka záznamu je 16bitové nezáporné číslo uvádějící počet bytů.

UDP

Původním transportním protokolem pro přenos DNS zpráv je protokol UDP (User Datagram Protocol). Pro DNS server je vyhrazen UDP port 53. Bez využití extenzí jsou podporovány zprávy do velikosti 512 bytů. Pro zasílání delších zpráv je zapotřebí podpora pro EDNS (Extension mechanisms for DNS). I když se stále jedná o nejvyužívanější transportní protokol, začíná být nahrazován alternativnímy protokoly, které podporují např. šifrování/spolehlivé doručení/delší zprávy.

TCP

DNS přes TCP (Transmission Control Protocol), definováno RFC 1123, funguje na stejném principu jako DNS přes UDP. Je zde rezervován i stejný port 53. Výhodou použití protokolu TCP je schopnost přenosu delších zpráv a spolehlivé doručení. Zprávy jsou zde stále zasílány v clear-text podobě. Hlavním důvodem pro podporu protokolu TCP bylo umožnění přenosů zón mezi DNS servery, jejichž velikost přesahuje možnosti protokolu UDP.

TLS

RFC 7858 specifikuje přenos DNS zpráv protokolem TCP za využití TLS (Transport Layer Security). TLS šifruje celý TCP přenos a je definována podpora pro volitelnou autentizaci serverů za pomoci certifikátů. Autentizace však není povinná.

HTTPS

Přenos DNS zpráv protokolem HTTPS má mnoho výhod. Navržen primárně pro mobilní zařízení, umožňuje přesnos přes HTTPS, komunikaci klienta s DNS serverem i v sítích se striktním filtrováním provozu, kde protokoly HTTP a HTTPS jsou často jediné povolené protokoly. To také napomáha s řešením protokolové osifikace v některých sítích. Dálší výhodou použití HTTPS je šifrování spojení TLS a využití HTTP/2 pro lepší utilizaci navázaného spojení. Pro přenos DNS přes HTTPS je použit standardní HTTPS port 443. Za zmínku dále stojí DNS přes QUICK — využití HTTP/3.

Autoritativní jménné servery

Autoritativní jmenné servery fungují v rolích primární (master) a sekundární (slave). Primární jmenné servery mají přímo uložené znalosti o dané zóně a fungují jako source-of-truth pro danou zónu. Primárních serverů může být pro danou zónu i více, ale všechny by měli odpovídat identickými informacemi (výjma Split DNS). Sekundární server nemá přímo uložené informace o zóně, ale stahuje si tyto informace z primárního jménného serveru skrze Zone Update a periodicky z něj pollují změny nebo jsou notifikovány mechanizmem NOTIFY. Odpovědi sekundárního serveru jsou stále autoritativní.

Resolvery

Resolvery mají za úkol samotný překlad doménových jmen. Toho můžou docílit různými způsoby: nerekuzrivně, rekurzivně a iterativně.

Příklad nerekurzivního DNS serveru je typický autoritativní server. Tento autoritativní server odpovídá pouze na dotazy pro zónu pro kterou je autoritativní, na ostatní dotazy vrací neúplnou odpověď — nezamítá ani nepotvrzuje jejich exitenci. Další příklad nerekurzivního chování je dotaz na lokální cache, z té buďto chceme úplnou odpověď nebo žádnou.

Rekurzivní chování nastává ve chvíli, kdy daný server odpověď nezná, ale má nakonfigurovaný server, kterého se na ni má zeptat. Příklad takového chování je např. bězná domácí síť, kde toto chování může být Latpop → Domácí Router → ISP DNS server. Laptop se dotáže domácího routeru, s příznakem Recurison Desired, který sice odpověď nemá, ale dotáže se na ni DNS serveru poskytovatele internetu. To pomáhá snížit provoz na síti, místo toho aby se všichni dotazovali autoritativního DNS serveru, tak se dotazují ISP DNS serveru, nároky na autoritativní DNS server a snížit latenci dotazu. Při rekurzivním překladu by měl být omezen počet míst, odkud smí chodit dotazy na rekurzivní překlad, jinak jsme vytvořili Open Relay, které jsou často využívány pro DDOS útoky skrze traffic amplification.

Iterativní chování je použito, pokud odpověď není v mezipaměti a není resolver, kterého bychom se mohli rekurzivně dotázat. Doménové jméno dotazu je v takovém případě překládáno postupně od kořenové domény přes jednotlivé labely — jednotlivé části doménového jména oddělené tečkou. Stojí za povšimnutí způsob, kterým jsou překládány jmenné servery pro subdomény tohoto dotazu. Jmenné servery pro danou doménu jsou uvedené formou doménového jména, vzniká zde tedy kruhová závyslost. Ta je zlomena tím, že při poskytování informace o adrese jmeného serveru pro danou doménu je v části Additional data zaslána i IP adresa daného serveru.

Validujici resolver

Validující DNS resolver je takový resolver, který při získání odpovědi na dotaz kontroluje podpis, a pokud se podpis neshoduje, tak je vrácena chyba SERVFAIL.

Níže je uveden jednoduchá minimální konfigurace:

options {
  // pracovní adresář pro relativní cesty
  directory "/etc/bind";

  // z důvodu bezpečnosti neprozrazujeme cestu
  version "not currently available";

  // povolení dotazů z IP adresy v CIDR notaci, např. 192.168.0.1/24, nebo any pro všechny
  allow-query { any; }; 

  // vypne rekurzivní režim překladu, default yes
  recursion no;

  // povolí DNSSEC validaci
  dnssec-validation auto;
};

// Není vyloženě nutný, ale je dobrá praxe ho uvést
// Může sloužit pro účeli kdy na klientovy neexistuje /etc/hosts
zone "localhost" {
  type primary;
  file "db.local";
  notify no;
};

// Reverzní záznam pro loopback 127.0.0.0/8
// nutné uvést mapování pro localhost
zone "127.in-addr.arpa" {
  type primary;
  file "db.127";
  notify no;
};

// Adresy kořenových name serverů
// Pokud neuvedem využijí se zakompilované adresy
// Dostupné na: https://www.iana.org/domains/root/files
zone "." {
        type hint;
        file "named.root";
};

Příklad konfigurace primární jmenného serveru pro example.com:

// Příklad konfigurace primárního serveru pro zónu example.com
zone "example.com" {
  // Jedná se o primární server
  type primary;
  // Kde jsou záznamy uloženy
  file "db.example";
  // Bude notifikovat sekundární servery při změně zóny
  // Notifikuje servery uvedené v SOA kromě primárního
  notify yes;
  // Jaké IP smí provádět zone transfer
  allow-transfer {
    192.168.200.1;
  };
  // Při změně zóny pošle NOTIFY i na následující adresy
  also-notify {
    192.168.200.1;
  }
}

Příklad konfigurace sekundárního jmenného serveru pro secondary.example.com:

// Příklad konfigurace primárního serveru pro zónu secondary.example.com
zone "secondary.example.com" {
  // Jedná se o sekundární server
  type secondary;
  // Do tohoto souboru se budou ukládat záznamy stažené přes zone transfer
  // Je to užitečné, např. aby mohl server odpovídat hned po spuštění
  // a nemusel čekat na dokončení zone transfer
  file "/var/cache/example.com.saved";
  // IP adresa primárního serveru
  primaries { 192.168.254.2; };
};

Příklad forwardovací konfigurace pro forward.example.com:

// Příklad forwardovací konfigurace pro forward.example.com
// Pozor: neplést s dopředným překladem
zone "forward.example.com" {
  // Jedná se o forwardovací server
  type forward;
  // Na následující IP adresy se budou forwardovad dotazy
  forwarders {
    192.168.250.3;
    192.168.230.27;
  };
  // Dotazy na tuto zónu se smí pouze forwardovat
  forward only;
};

Příklad DNSSEC konfigurace pro sec.example.com:

Nejdříve vytvoříme adresář kam budem ukládat klíče: /etc/bind/keys. Poté vygenerujeme KSK.

$ mkdir -p /etc/bind/keys
$ cd /etc/bind/keys
$ dnssec-keygen -f KSK -a RSASHA256 -b 4096 -n ZONE secure.example.com # Vytvoří KSK

dnssec-policy "secure-example-com" {
    keys {
        // KSK se vezme z /etc/bind/keys
        ksk key-directory lifetime unlimited algorithm 8;
        // ZSK se generuje automaticky a je měněn každých 60 dní
        zsk lifetime 60d algorithm ecdsap384sha384;
    };
    // Použít NSEC3 -- bezpečnější než NSEC
    nsec3param;
};

// Příklad DNSSEC konfigurace pro sec.example.com
zone "sec.example.com" {
  // Jedná se o primární server
  type primary;
  // Kde jsou záznamy uloženy
  file "db.secure.example";
  // Kde jsou uloženy klíče
  key-directory "keys";
  // Název dnssec-policy
  dnssec-policy "secure-example-com";
  // Povolit transparentní vytváření podepsaných zón
  inline-signing yes;
};

Více ke konfiguraci DNSSEC na: https://bind9.readthedocs.io/en/v9.18.13/chapter5.html#dnssec-kasp

Potom co máme hlavní konfigurační soubor hotový musíme vytvořit zónové soubory:

$TTL 2d  ; Výchozí TTL pro všechny záznamy pokud není uvedeno jinak
; První doména MNAME, primární jmenný server
; Druhá doména RNAME, je emailová adresa administrátora, první label je název účtu, takže hostmaster@example.com
@     IN      SOA   ns1.example.com. hostmaster.example.com. ( 
                                        2003080800 ; Sériové čislo, při každé úpravě by mělo být zvýšeno o 1
                                        3h         ; Refresh interval, jak často má sekundární server pollovat primární
                                        15m        ; Update retry, jak dlouho má sekundární server čekat pokud primární neodpoví
                                        3w         ; Expiry, jak dlouho se může sekundární server považovat za autoritativní pokud si nemohl obnovit data
                                        3h         ; nx = nxdomain ttl, jak dlouho se mají cachovat negativní odpovědi
                                        )
; jmenný server, uvedený doménovým jménem -- bude použit glue record
           IN      NS      ns1.example.com.
; adresa jmenného serveru
ns1        IN      A       192.168.254.2
; @ -- uvádí výchozí doménu této zóny
@          IN      A       192.168.254.2
           IN      A       192.168.254.3 ; tyto dvě IP budou postupně rotovány pro každý dotaz
alias      IN      CNAME   example.net. ; nutné uvézt . na konci, jinak bude relativní k zóně

Příklad reverzní konfigurace pro 127.0.0.0/8 z výchozí distribuce bind9 pro Debian:

; Stejné jako u forward zóny
$TTL	604800
@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
; Jmenný server pro 127.0.0.0/8 je localhost
@	IN	NS	localhost.
; Příklad reverzního PTR záznamu, IPv4 oktety jsou v opačném pořadí
1.0.0	IN	PTR	localhost.

Pro konfiguraci DNS resolveru existuje mnoho způsobů, které závisejí na dáne platformě/distribuci/nainstalovaných balíčcích.
Nejjednoduším způsobem je přímo úprava souboru /etc/resolv.conf, kde uvedeme jednotlivé jmenné servery direktivou nameserver:

search pv090.fi.muni.cz
nameserver 10.0.0.1
nameserver fd00:dead:beef::1

Při úpravě /etc/resolv.conf si musíme dát pozor, jelikož je tento soubor často používán růzýnmi démony, zodpovědnými za konfiguraci sítě, pokud tedy nějaký takový démon používáme, neměli bychom do tohoto souboru zasahovat.
Např. při použití balíku ifupdown bychom, tyto jmenné servery, měli uvést při konfiguraci rozhraní:

iface eth0 inet static
    address 10.0.0.50/24
    gateway 10.0.0.1
    # DNS jmenný server
    dns-nameservers 10.0.0.1
    # jakou doménu použít při vyhledávání pouze pomocí posledního labelu
    dns-search pv090.fi.muni.cz