LPS:DNSSEC - Provozní dokumentace

Z HelpDesk
Verze z 6. 10. 2019, 21:57, kterou vytvořil Valtri (diskuse | příspěvky) (Podepisovací politiky)

V tomto dokumentu jsou technické informace týkající se DNSSEC.

Informace

Testovací DNSSEC servery:

  1. erosek.zcu.cz: primární + rekurzivní DNS (autoritativní DNS)
  2. orisek.zcu.cz: slave DNS (totožný s ostatními slave DNS servery, jen s povoleným DNSSEC)

Rozdíly erosek.zcu.cz oproti produkčnímu DNS:

  • povolené DNSSEC
  • modifikovaná data zón - NS záznamy nahrazené za erosek.zcu.cz
  • podepsané zóny

Harmonogram

Dvě nezávislé části:

  • rekurzivní dotazy ven (DNSSEC na DNS slave serverech)
  • DNS dotazy dovnitř (podepisování zón ZČU na DNS primáru)

Zapnutí na univerzitních DNS (validace ven)

1. oddělený rekurzivní resolver pro 1. segment s povoleným DNSSEC (orisek.zcu.cz)

==> (DONE) server orisek.zcu.cz nachystaný
==> (DONE) přepnout DNS server pro LPS segment v DHCP

2. povolit DNSSEC na všech univerzitních rekurzivních resolverech (ori, ori-backup, fennel.fek, ezop.fpe, erebos)

==> (DONE) ověřování DNSSEC povoleno

Kontrola (mít lokálně pouze validující DNS resolvery - tj. orisek.zcu.cz):

Podepisování zón ZČU (validace dovnitř)

1. krok: testování na nezávislém primárním DNS serveru s lokálním "ostrovem důvěry"

==> (DONE) server erosek.zcu.cz
==> (DONE) sonda do nagiosu check_dnssec.pl (s lokálním "ostrovem důvěry")

2. krok: nasazení DNSSEC v zónách ZČU (bez delegace a pak s delegací klíčů)

  • možno začít malými zónami - zameknecntiny.cz, caduv.cz, eduskop.cz, ...
  • pokračovat hlavními zónami - zcu.cz, fek.zcu.cz, fpe.zcu.cz, 228.147.in-addr.arpa
  • nutno dodržet správný postup (napřed začít podepisovat, počkat > 1 den, pak dát vědět nadřazené zóně)

Poznámka: na tyto zóny se zatím vykašlemež:

  • 1.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa: CESNET nepodepisuje
  • 1.0.8.1.8.1.7.0.1.0.0.2.ip6.arpa: CESNET nepodepisuje
  • 3.6.7.7.3.0.2.4.e164.arpa: statická (ale můžem přesunout do Saurona a přegenerovávat)
  • 9.0.5.9.0.2.4.e164.arpa: statická (ale můžem přesunout do Saurona a přegenerovávat)
  • delegované (pool.zcu.cz, voip.zcu.cz, enum.zcu.cz, subdomény 228.147.in-addr.arpa pro telefonii)

Teorie

Čas

Ověřování DNSSEC závisí na správně nastaveném čase.

V případě použití NTP je potřeba použít IP adresy místo DNS jména, aby se zamezilo problému "slepice-vejce". Na DNS serverech ZČU to není potřeba - pro domény clock1.zcu.cz a clock2.zcu.cz jsou univerzitní DNS servery (vč. slavů) autoritativní a DNSSEC se neuplatňuje.

Co se může rozbít

Expirace podpisů:

  • default pro RRSIG záznamy je 30 dní, zóny je třeba včas přegenerovat
  • TODO: raději přidat explicitní přegenerování do kronu (není striktně potřeba)

Expirace klíčů:

  • default je nikdy, takže cajk ;-)
  • v DNS IMHO nikde není - spíš by se týkalo automatických nástrojů vč. nástrojů ISC Bind
  • do best-practices patří pravidelné výměny klíčů

Monitoring:

NAT64:

  • týká se všech sítí s IPv4-only adresami používajících DNSSEC a cizích klientů na síti s NAT64
  • používá se DNS64, které "lže" místním klientům o IPv4-only adresách ==> problém pro stub-resolvery se zapnutou validací
  • asi nejde vyřešit a neřešme
  • částečné řešení:
    1. stub-resolvery běžně sami nevalidují
    2. na straně resolverů: implementace by měla vědět o NAT64 prefixech (64:ff9b::/96, resolvování AAAA ipv4only.arpa)
    3. na straně ZČU: poskytovat všude IPv6 a není problém ;-)

Konfigurační chyby:

  • bacha na cachování DNS
  • nesoulad DS v nadřazené zóně a DNSKEY ve vnořené zóně
  • lokální chyby (většinu věcí zachytí už utilita dnssec-signzone a naše kontroly)

Zapnutí validace

Validace DNSSEC bude fungovat pouze, pokud bude zapnutá na každém nakonfigurovaném DNS (z pohledu klienta).

Klienti (nevalidující stub-resolver) při selhání vyhodnocování DNS zkouší postupně všechny nakonfigurované DNS servery. Neprovádí-li jeden z nich validaci DNSSEC, projde nakonec dotaz i na nevalidní doménu vždy.

Typy záznamů

DNSKEY

Zónové klíče (ZSK - Zone Singing Key) a "klíčové" klíče (KSK - Key Signing Key).

  1. zónový klíč (ZSK):
    • bývá menší, aby byly kratší podpisy (v případě RSA je default 1024 bitů, oproti 2048 u KSK)
    • podpis jednotlivých RR
  2. klíčový klíč (KSK):
    • podpis ZSK
    • vstupní bod důvěry pro zónu (SEP) - otisk patří do nadřazené zóny

Klíč může být jeden a poskytovat obě role: ZSK (podepisování zón) i KSK (podepisování klíčů - vstupní bod důvěry.

KSK i ZSK může být několik (kvuli rotacím). Na funkci DNSSEC musí být alespoň jeden platný řetěz.

Formát:

DOMAIN. IN DNSKEY FLAGS PROTOCOL ALG DATA

FLAGS:

  • 256 - zone (ZSK)
  • 257 - zone + SEP (KSK)

PROTOCOL:

  • 3 - vžycky, jinak je DNSKEY invalid

ALG DNS Security Algorithm Numbers:

  • 5 - RSASHA1 (default) - abclinuxu.cz ibesip.cz isc.org o2.cz pilsfree.cz root.cz t-mobile.cz
  • 7 - NSEC3RSASHA1 - aktualne.cz muni.cz
  • 8 - RSASHA256 - . debian.org freebsd.org iana.org
  • 10 - RSASHA512 - cz cesnet.cz metacentrum.cz
  • 13 - ECDSAP256SHA256 - 4chan.org auto.cz cloudflare.com cvut.cz dnssec.cz e15.cz
  • 14 - ECDSAP384SHA384

(SHA1 obsolete, RSASHA1 jen NSEC)

DS

Otisk klíče. Používá se v delegaci - zabezpečená informace v nadřazené zóně o "klíčovém" klíči (KSK) vnořené zóny.

Formát:

DOMAIN. IN DS KEY_ID ALG DIGEST DATA

ALG DNS Security Algorithm Numbers:

  • 10 - RSASHA512
  • 13 - ECDSAP256SHA256
  • 14 - ECDSAP384SHA384

DIGEST Digest Algorithms:

  • (0 - rezerovováno)
  • 1 - SHA-1
  • 2 - SHA-256

NSEC

Negativní informace - důkaz neexistence záznamu. Dělá se přes odkaz na další RR.

Je např. potřeba mít zabezpečenou informaci v nadřazené zóně typu "u téhle zóny nemám DS".

NSEC3

Kvuli odkazům mezi RR lze pomocí NSEC projít celou zónu. NSEC3 je bezpečnější varianta NSEC, kde se použitím hashování skryje informace o skutečném záznamu, co následuje.

Formát:

DOMAIN_HASH.ZONE. TTL_RR IN NSEC3 HASH_ALG FLAGS ITERATIONS SALT ( DATA RR_TYPE )

HASH_ALG DNSSEC NSEC3 Hash Algorithms

  • (0 - reserved)
  • 1 - SHA-1

FLAGS DNSSEC NSEC3 Flags

  • 1 - opt-out (něco s delegacemi a záznamy bez podpisů)

ITERATIONS - počet iterací hashovacího algoritmu (typicky 10)

SALT - sůl pro hashování

NSEC3PARAM

Jeden záznam pro zónu. Parametry obsažené v každém NSEC3 záznamu jsou vyzobnuté do tohoto extra záznamu.

Formát:

ZONE. 0 IN NSEC3PARAM HASH_ALG FLAGS ITERATIONS SALT

Význam jako u #NSEC3, TTL je vždy 0.

RRSIG

Podpis DNS záznamu (RR).

Formát (příklad "A" záznam):

TTL_RR RRSIG A ALG LABELS TTL_RRSIG ( VALID_TO VALID_FROM ZSK_ID ZONE. DATA )

ALG DNS Security Algorithm Numbers

  • 10 - RSASHA512
  • 13 - ECDSAP256SHA256
  • 14 - ECDSAP384SHA384

LABELS - počet domén (labelů) ve jméně

Všechny RR jsou podepsané (SOA, A, PTR, ... a také NSEC3, DNSKEY, DS, ...).

Rotace klíčů

Dva způsoby rotace:

  • předem vystavit nový klíč (pro ZSK)
  • používat starý i nový paralelně (pro KSK)

Pokud zóny, pro které jste konfigurovali trust-anchors, změní své klíče, budete muset znovu nakonfigurovat také trust-anchors.

Pozor na KSK - nutná i změna v delegaci. Viz #KSK.

ZSK

Metoda předpublikace:

  1. vystavíme nový klíč
  2. počkáme, až se rozšíří
  3. začneme podepisovat novým klíčem
  4. počkáme až zmizí staré podpisy
  5. vymažeme starý klíč

Máme vždy jednu sadu podpisů. Používá se u ZSK (pokud bychom použili u KSK, vyžadovalo by dvojí změnu v nadřazené zóně).

KSK

Metoda dvojího podpisu:

  1. vystavíme nový klíč, podepíšeme oběma
  2. počkáme, až se rozšíří
  3. vyměníme DS záznam v nadřazené zóně
  4. počkáme, až se změna DS rozšíří
  5. odstraníme starý klíč a staré podpisy

Jediná komunikace s nadřazenou zónou. Používá se u KSK (u ZSK by enormě narostl objem dat).

KSK+ZSK

Není běžně potřeba. Metoda dvojího podpisu pro KSK a metoda předpublikace pro ZSK.

KSK+ZSK+algoritmus

Není běžně potřeba. Změna šifrovacího algoritmu je náročnější - dvojice KSK i ZSK musí používat stejný algoritmus, a tak je třeba vyměnit oba klíče a kontrolní nástroje varují před použitím šifrovacího algoritmu pouze mimo RRSIG (problém nastává při podepsání klíčů oběma KSK a podepsáním zóny jedním ZSK). Při podepisování nástrojem dnssec-signzone přeskočit kontroly volbou -P, případně zvolit bezpečnější metodu dvojího podpisu pro oba dva klíče.

Postupy

Test doménového záznamu

Pro analýzu lepší používat delv místo dig. delv je doporučovaný pro dělání plné validace DNSSEC (tu lze vypnout volbami +noroot a +novld).

1) delv 

delv +multi -t DS cesnet.cz

delv +multi -t NS zcu.cz +root=zcu.cz

(+multi je na hezčejší výstup u klíčů do více řádek)

(+noroot vypne DNSSEC validaci za použití root anchors)

(+novld vypne DNSSEC validaci za použití dosluhujícího VLD)

(+cd žádost serverům o data bez ověřování, získávat i neplatná data - pro ladění chyb v DNSSEC)

2) dig

V případě použití dig koukat na flagy:

  • AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)
  • AA = Authoritative Answer

Při AA nemá ověřování smysl, flag AD může vrátit pouze rekurzivní resolver.

V dotazu lze serveru poslat flag CD = Checking Disabled. 

dig +multi +dnssec -t NS zcu.cz

(+multi je na hezčejší výstup u klíčů do více řádek)

(+dnssec ukáže i záznamy specifické pro DNSSEC, u delv je to default)

(+cd žádost serverům o data bez ověřování, získávat i neplatná data - pro ladění chyb v DNSSEC)

Zabezpečení sekundárního DNS

Volitelné zabezpečení podepisováním přenášených zón mezi primárním DNS a sekundárem symetrickou šifrou. Zabezpečuje se v podstatě stejný kanál, kterým komunikují s DNS klientské stanice, a tak to (možná) není tak důležité z hlediska bezpečnosti. I tak se doporučuje přenos podepisovat kvuli výpadkům nebo SW chybám.

Obecně lze takto zabezpečit i komunikaci jakéhokoliv pokročilejšího klienta s DNS serverem (dig a parametry -k nebo -y).

Postup (sekundární DNS): 

cd /etc/bind
tsig-keygen -a hmac-sha512 `hostname -f` > named.conf.keys
cat >> named.conf.keys <<EOF

server 147.228.10.10 {
        keys `hostname -f`;
};

server 2001:718:1801:1010::1:10 {
        keys `hostname -f`;
};
EOF

chmod -v 0640 named.conf.keys
chown -v root:bind named.conf.keys

Přidat ekvivalentní konfiguraci (named.conf.keys s IP adresami sekundáru) i na primární DNS server (root@hera:/etc/bind/named.conf.keys).

Všechny soubory /etc/bind/named.conf.keys jsou uloženy pouze lokálně na DNS serverech.

Ruční ověření delegace

Získání DS z DNSKEY (příklad s KSK z root zóny): 

cat << EOF > root1.key
.			90378	IN	DNSKEY	257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=
EOF
dnssec-dsfromkey -2 root1.key

Pak porovnat získaný DS se záznamem v nadřazené zóně (v případě root zóny s trust anchors na iana.org/dnssec).

Počáteční vyrobení klíčů

Z algoritmů bych volil buď ten použitý v CZ NIC (RSA512, v ČR 4. nejpoužívanější) nebo eliptickou šifru (ECDSAP256SHA256, v ČR 3. nejpoužívanější). První dva nejpoužívanější algoritmy využívají dosluhující hashovací algoritmus SHA-1 (i když v ISC bind je to stále default ;-)). Default algoritmus navíc neumí NSEC3.

Rychlotest na zóně 228.147.in-addr.arpa:

time size
RSASHA512 0m6.164s 1,3M -> 16M
ECDSAP256SHA256 0m57.554s 1,3M -> 12M

Best-practices:

  • klíče se vyrábí vždy pár pro každou zónu (zónový se vymění snadněji, může být menší, ...)
  • jiný pár pro každou zónu (teoreticky jde o jen kosmetickou věc - rotace klíčů pak lze dělat postupně apod., prakticky jde i o omezení utilitek bindu, které lze řešit ručním poeditováním klíčů)
  • KSK i ZSK musí mít stejný algoritmus

Postup (nahradit zcu.cz za správnou zónu):

1. Zónový (ZSK): 

dnssec-keygen -3 -r/dev/random -a RSASHA512 -b 1024 -n ZONE zcu.cz
#dnssec-keygen -3 -r/dev/random -a ECDSAP256SHA256 -n ZONE zcu.cz

2. Klíčový (KSK): 

dnssec-keygen -3 -r/dev/random -f KSK -a RSASHA512 -b 2048 -n ZONE zcu.cz
#dnssec-keygen -3 -r/dev/random -f KSK -a ECDSAP256SHA256 -n ZONE zcu.cz

3. import do OpenDNSSEC - po vyrobení zóny 

/opt/opendnssec/import-key.sh FILE.key

Aktualizace bind.keys

Návrh postupu na výměnu root klíčů:

  1. vzít soubor /etc/bind/bind.keys z podepsaného balíku aktuálního OS
  2. ověřit klíče na základě postupu #Ruční ověření delegace s root anchors na https://iana.org/dnssec
  3. (doplnit vlastní klíče, pokud jsou)

Teoreticky není potřeba - DNS servery si mají automaticky stahovat nové klíče z root zóny (do var/cache/named). Ale nechť máme "pevný bod" rovnou v /etc/bind.

Výjimky

Možnost přidání výjimky pro jedinou zónu při vyhodnocování DNSSEC je v plánu v ISC BIND 9.11 - negative trust-anchors: https://lists.isc.org/pipermail/bind-users/2015-January/094388.html

Workaround už teď krz disable-algorithms pro zónu:

Pro konfiguraci negative trust anchors platí několik best-practice:

  • měla by být časově omezená
  • neměla by se používat pro testovací zóny, kde má DNSSEC selhávat schválně (dnssec-failed.org, rhybar.cz)

Cesty

Výběr důležitých souborů a adresářů pro správu DNSSEC, vše na volupta.zcu.cz.

/var/sauron/keys

Adresář s klíči pro DNSSEC. Používá se pro podepisování (privátní části) a pro vkládání do podepisovaných zón (veřejné části).

Změny: ručně administrátory

/var/sauron/sign.sh

Hlavní podepisovací skript. Identifikátory používaných klíčů jsou přímo v něm.

Změny: ručně administrátory

/var/sauron/dns9-additive/zcu/zones/db.dnssec.*

Soubor s aktuálně používanými klíči (aktivními i pasivními). Udržováno poloautomaticky podepisovacím skriptem.

Změny: (jen kosmetická věc) zkopírovat z dns9-copy při změně klíčů

/var/sauron/dns9-*/*/dsset-ZONA.

Automaticky generované soubory s DS záznamy pro použití v nadřazených zónách (dsset-fek.zcu.cz. a dsset-fpe.zcu.cz. se používají při podepisování zóny zcu.cz).

Změny: automaticky podepisovacím skriptem

Konfigurační tipy

Logování DNSSEC záležitostí

logging {
       channel dnssec_syslog {             // a DNSSEC log channel
               syslog daemon;
               print-time yes;        // timestamp the entries
               print-category yes;    // add category name to entries
               print-severity yes;    // add severity level to entries
               severity debug 3;      // print debug message <= 3 t
        }; 
  category dnssec  {dnssec_syslog;};
}

Trust-anchors

Ostrov důvěry (pouze pro rekurzivně vyhodnocované zóny - forwardeři, klienti, ...; není potřeba na DNS slavu zóny).

Do named.conf.options (nebo named.conf.keys, ...): 

trusted-keys {
        "1.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa." 257 3 10 "AwEAAbot1Db+UKP69a+JjKBH2U9JIU+jQpp5stBRCStLH+Ez3r81Vjkq lWb6ob79Ubh9k9jQPEqywoMCUP3SrtmOFwgQt8WTOUuPQhBQ4Ed91hla MgTrBkmHzias7hNYXvjtjYjkcCw6oW54pIcsM6oxcNWBaOiC+Opr8bv+ +iAoXlPMVpYvudLgePfjkxGAwT1o3UsEoQrOaM31kfbVqbEz6Z+4ygqA pTyugw7Zer+SaGu43lgCTtf70cXFTdfbVkOBM/M4dEHFt4Gwk0bM5+TH at5TyNSD6SEXqsBvNt6sxlGAB5EbbWReYQ5YiehDnIU861/HLGmGmDGB Z0GlC6wYyc0=";
        "1.0.8.1.8.1.7.0.1.0.0.2.ip6.arpa." 257 3 10 "AwEAAbBc9tNPIqDUqfr8NUtXIOMbkVBJ42EJgm7XfdIyhPYukigFV62I m6byxj6b3VVHIIQ4Vr7FJcCKg8bFs3ap9xdJcw0QliuHmnJV0EhGqhut zoIXnYNU8rELFUv3+T41L/du0F3ilLpLvjAFhfxzA4tLDoYKvhsaETT3 eLnIQQdkVasMmXd3v9pwweOd++fwFLXxf7+Z6nPuDgz4zVRBrcU3Sk8K 3JP+Z4jv0faxwNgHS1DoaCUqTRwaWQ9KXJxKhCi20dqU0h+yUiERHWnj sjIetbaRsckCJ+BWsChP8cYdzWOJ9jV1l0N1aZMX19LebZAn4VBJpQST LUq38qICgQM=";
        "228.147.in-addr.arpa." 257 3 10 "AwEAAaNLt237ui+3udocdxL+11AVpmGyx6Sx8Wrdssk8f8XN+NMUROGs jYie7AUMA8nFSBJfTFLMXy3cgVP+uklerHqILBI9zDTcIh7lMZ/EvhcY hZckj2JlVv/gcnhW7s7a7kJLINuVfgdk8Mo7rN4/8QyB2E49rfJRw2P5 hxSPLqBpG7FzTBtZOxSaxd0HkJ8R5CB419uEbnEgdqdXouKF6gbLG/MT 468Ttn75vA/WLeh7A2ekRIxalPRHUSYVSxZdA2EognFcztJV7EnFlg1u yOhXnxCsDpP+tZxosZBFz3taYopkkHuWwX/J1nZdL314WVHWcF71MisI UXG2ELRIn4c=";
        "zcu.cz." 257 3 10 "AwEAAbTw3jwU0kRFEKFzlsczlE8QJ4oqVcLBsi9UAgevejqBkrRsR0nPoJebGvR7IStQ/ytzQEnEDAsYJXBZmNhiesWqDeSSiRJHoTHrLcbVYGTIdPwFQWdm89yB8/QvEfTqnQ/bqO0md1MN/GweA+vLyyenonp45u5wtVxk6uOCRj/TztIDG5Dr3DJ1JDM/b4Gc30rJTVPySFJZME3Xtq8DYyYPBR54JrWQZzN09/xU15M0BrW3HKq+Dh3U45/DBiflvD6wtYR62ZC+XyUIfVRDNhTosG3RYvgkdTHwBoph7xqOa3Vgkd1dSeiTeW8nLNCFsK9cHkx0xak0dMiFv9NH2mM=";
};

Poznámka: pro validující forwarder by se zřejmě nemělo dávat do /etc/bind/bind.keys - ISC bind si a tohoto souboru vyzobne pouze sekci managed-keys, ale jinak se to neincluduje.

Podepisovací politiky zón

Tabulka podepisovacích politik zón pro OpenDNSSEC:

Zone Policy Parent zone Parent SOA TTL Parent NS TTL Parent DS TTL Parent minimum
1.0.8.1.8.1.7.0.1.0.0.2.ip6.arpa ripe6 8.1.7.0.1.0.0.2.ip6.arpa 86400 86400 900
1.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa muni6 1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa 7200 7200 7200
2.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa 8.1.7.0.1.0.0.2.ip6.arpa 900
228.147.in-addr.arpa ripe4 147.in-addr.arpa 86400 86400 10800
242.128.78.in-addr.arpa ripe4 78.in-addr.arpa 3600 172800 3600
243.128.78.in-addr.arpa ripe4 78.in-addr.arpa 3600 172800 3600
3.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa 8.1.7.0.1.0.0.2.ip6.arpa 900
caduv.cz nic cz 3600 3600 900
eduskop.com gtld com 172800 86400
eduskop.cz nic cz 3600 3600 900
zameknectiny.cz nic cz 3600 3600 900
zcu.cz nic cz 3600 3600 900

Časování v politikách vychází ze SOA a TTL zóny a rodičovské zóny. Některé jsou sloučené (s použitím maximálních časů) - např. ripe4.

Uživatelská dokumentace (návrh)

Na rekurzivních serverech DNS na ZČU je povoleno ověřování pomocí DNSSEC. V případě, že podle hierarchie DNS má být daná zóna ověřena pomocí DNSSEC a ověření selhalo, DNS dotaz selže na SERVFAIL. Otestovat si DNSSEC lze např. na stránkách http://nic.cz/dnssec.

DNSSEC se na univerzitních resolverech neuplatňuje pro doménová jména ze zón ZČU - tam se jedná o autoritativní data. Avšak ověřování si může navíc provádět i sám klient - např. lokální DNS forwarder, doplňky prohlížeče, speciální aplikace využívající DNS, ...

Pokročilejší příklady

Autorizovaná data

DNS servery na ZČU budou mít nastaven flag AA - autorizovaná data. V takovém případě se DNSSEC validace neprovádí. 

dig www.zcu.cz

Úspěšná validace

Proběhnutá a úspěšná validace je poznat v odpovědi pomocí nastaveného flagu AD. Týká se rekurzivně vyhodnocovaných zón (zón mimo ZČU) podepsaných pomocí DNSSEC. 

dig 4chan.org

Úspěch bez validace

Za úspěch je také považován případ, kdy daná zóna nemá DNSSEC povolené, ale existuje podepsaný "důkaz neexistence" DNSSEC zóny v nadřízené zóně. V takovém případě nebude v odpovědi žádný z flagů AD nebo AA, ale odpověď je úspěšně vrácena. 

dig pleiades.pool.zcu.cz

Podobně v případě nepodporovaného algoritmu klíče kdekoliv v hierarchii DNS - opět existuje podepsaný důkaz, že data nelze validovat (podepsaná informace o používaném algoritmu) a data jsou úspěšně vrácena, jen bez flagu AD.

Selhávající DNSSEC

Zóna podepsaná DNSSEC, ale s podvrženými nebo chybnými daty musí selhat na SERVFAIL. 

host rhybar.cz
dig rhybar.cz

Detaily lze analyzovat pokročilejšími nástroji, např. dig nebo delv s parametrem +cd (check disabled). 

dig rhybar.cz +cd +dnssec

Odkazy

Citováno z „https://helpdesk.zcu.cz/index.php?title=LPS:DNSSEC_-_Provozní_dokumentace&oldid=54924“