Prvotní myšlenka identifikace počítačů v síti pomocí alfanumerických jmen vznikla už v dobách ARPAnetu. Když počet připojených strojů začal expandovat, přestalo být možné pamatovat si všechny číselné adresy. Bylo tedy potřeba vytvořit systém převádějící zapamatovatelnější jména na odpovídající adresy a zpět.
Na počítače tedy začal být (po FTP) distribuován soubor s číselnou adresou a jí odpovídajícím jménem . Na unixových strojích je to soubor /etc/hosts a používá se ve speciálních případech dodnes. Může vypadat například takhle:
127.0.0.1 localhost 10.0.0.70 proto07 proto07.lab.fi.muni.cz
Topologie DNS je postavena na stromovém modelu doménových jmen (hostnames). Doménu je možné označit jako jmenný prostor, kde je možné pojmenovávat bez ohledu na obsah ostatních domén (např. blabla.cz může být úplně nezávislé na blabla.sk a mohou spolu koexistovat). Na nejvyšší úrovni je tzv. top level doména - označována tečkou. Na druhé úrovni jsou domény státní (cz, sk, de,...) nebo speciální (com, name, biz, info,...). Domény jsou nezávisle na top level doméně nebo jiných doménách spravovány a delegovány, mohou v nich vznikat další subdomény. Tím je udržována potřebná distributivita celého procesu správy doménových jmen.
DNS transparentně pro uživatele překládá zapamatovatelné doménové jméno na IP adresu a zpět. Tím zajišťuje možnost komunikace pomocí alfanumerických jmen, bez znalosti IP adres. Mimo IP adresy (záznam typu A) DNS může poskytovat i záznamy jiných typů, např. MX záznam pro poštovní server domény, DNSKEY pro veřejný klíč DNSSEC (viz níže), CNAME pro kanonické jméno záznamu, AAAA pro IPv6 adresu.
Méně časté jsou dotazy pro zjištění hostname k zadané IP adrese - tzv. reverzní. Při těchto dotazech se obrací pořadí bajtů v adrese. K obrácené adrese pak připojí doménu in-addr.arpa a výsledné ?jméno? pak vyhledává standardním postupem. Přesný postup získání záznamu popisuje pěkně referát odkaz v poslední sekci.
Každou DNS zónu obsluhuje DNS server (běží na well-known portu 53), existují tyto typy:
Berkeley Internet Name Domain (named) - BIND je nejpoužívanějším DNS serverem internetu. Byl vyvinut na kalifornské univerzitě v Berkeley, dnes se o jeho vývoj stará Internet Systems Consortium. Nejnovější verze obsahuje podporu pro IPv6, DNSSEC, podepisování transakcí, ukládání zónových souborů do databáze... Obsahuje také utilitku rndc, která dovoluje BIND lokálně nebo vzdáleně spravovat.
Bind obsahuje několik mechanismů pro zajištění bezpečnosti: umí běžet v chroot prostředí, umožňuje volbu uživatele a skupiny, pod kterými poběží. Ukládá konfiguraci v souboru /etc/named.conf
djbdns - populární "lehký" DNS server. Obsahuje několik nástrojů - pro resolvování, pro databázi, pro blacklisting.. unixový přístup dělení úkolů na samostatné programy.
unbound, nsd, ...Jednoduchý příklad zónového konfiguračního souboru:
$TTL 3600 ; 1 hour default TTL
example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ; Negative Reponse TTL
)
; DNS Servers
IN NS ns1.example.org.
IN NS ns2.example.org.
; MX Records
IN MX 10 mx.example.org.
IN MX 20 mail.example.org.
IN A 192.168.1.1
; Machine Names
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5
; Aliases
www IN CNAME example.org.
;prevzato z http://www.freebsd.org/doc/en/books/handbook/network-dns.html
Spatřily světlo světa v roce 2005 jako soubor tří RFC. Cílem DNSSEC je poskytovat ověřené informace z DNS. Využívá struktury veřejných a privátních klíčů pro podepisování záznamů. Privátní klíč je držen v tajnosti, jemu odpovídající veřejný klíč, je uložen v zónovém souboru domény pomocí záznamu DNSKEY. V takové doméně potom podepisujeme záznamy a jejich typy.
V zónovém souboru nadřazené domény je uložen jeho otisk, pokud důvěřujeme nadřazené doméně, můžeme se spolehnout na informace s poddomény.
Doména .CZ je podepsaná, podpis kořenové zóny DNS bude zveřejněn 1. července 2010.
Další info: http://www.nic.cz/dnssec/
DNSSEC umí bind, unbound a nsd.
Je typ útoku na DNS, kdy dojde na cashing-only serveru k podvržení záznamu. Může se to stát chybou v DNS software a nedokonalou validací původu informace o záznamu. Ten potom ukazuje na útočníkem ovládanou IP adresu, kde se často skrývá např. malware. Řešením je DNSSEC, kontrola relevance záznamu v kontextu, kontrola koncového bodu (SSH) apod.