LPS:DNSSEC - Provozní dokumentace

Z HelpDesk
Verze z 10. 10. 2019, 15:13, kterou vytvořil Valtri (diskuse | příspěvky) (→‎NSEC: - tady je lepčí termín "doména")

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

Nástroje

OpenDNSSEC:

ISC bind:

  • dnssec-signzone (nahrazeno OpenDNSSECem), dnssec-keygen

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ž:

  • *.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa: MUNI 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 domé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.

OpenDNSSEC

Popis stavů viz [1].

Každý z těchto objektů má nezávisle vlastní stav:

  • DS resource record
  • DNSKEY resource record
  • RRSIG pro DNSKEY
  • RRSIG všeho ostatního

Popis stavů:

  • Hidden: The associated resource records are never published or are unpublised long enough that the enforcer knows no validator will try to use this resource record for validation.
  • Rumoured: This record is being published but might not be accessible for all validators yet. After some time (including the TTL of record set) the state will move to omnipresent.
  • Omnipresent: The record is fully published and available for everyone. No caches contain any old key with an unexpired TTL.
  • Unretentive: The signer is instructed no longer to publish this record but it might exist in some caches still. After some time the state will move to hidden.

OpenDNSSEC-states.png

DS v rodičovské zóně má ještě pod-stavy:

  • UNSUBMITTED: The DS record does not need to be published.
  • SUBMIT: The Enforcer wants this DS to be uploaded to the parent. It either waits for the user confirming the upload, or when the DelegationSignerSubmitCommand in the KASP is set, executes that command. In both cases it will proceed to the next state.
  • SUBMITTED: The Enforcer knows this DS is to be published soon. It might or might not be visible to the world yet. In the key list this will show as waiting for ds-seen. An external entity should initiate this ds-seen, be it a user or for example a cron job that polls the parent.
  • SEEN: The DS available for everyone. It will stay in this state until the KSK must make place for a new KSK. In which case it will move to the next state automatically.
  • RETRACT: Similar to SUBMIT it will wait for user input or, if available, execute the DelegationSignerRetractCommand. Then moves to the next state.
  • RETRACTED: The key is waiting for a ds-gone. Once given the DS state will go back to UNSUBMITTED.

Problémy:

  • běží to jako démoni a nejraději by to samo měnilo serial v SOA (ale to má dělat Sauron)
    • => ods-signer démon pouštěný pouze během generování konfigurací
    • => TODO: filter do karkinos
  • drobný bug: ZSK to dělá by default metodou dvojího podpisu
    • => volba <ZskRollType>ZskPrePublication</ZskRollType>
  • chce to pravidelný resign zón
    • => snížena perioda + neběží jako démon

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)

Přidání zóny

  1. vybrat vhodnou politiku podle #Podepisovací politiky zón
  2. přidání do OpenDNSSEC (nahradit "zcu.cz" a "nic" za správné hodnoty): 
    zone=zcu.cz
policy=nic

ods-enforcer zone add --zone $zone --policy $policy --input /var/sauron/dns9-final/zcu/zones/${zone}.zone --output /opt/opendnssec/var/opendnssec/signed/${zone}.zone
ods-enforcer update all
  3. vyrobení klíčů přes bind a import pomocí '/opt/opendnssec/import-key.sh, viz #Počáteční vyrobení klíčů (TODO: vygenerovat přímo v OpenDNSEC?)

Podepisovací politiky zón

Tabulka nakonfigurovaných podepisovacích politik zón pro OpenDNSSEC (první dva sloupce):

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 (muni6) 1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa 7200 7200 - 7200
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 172800 3600
243.128.78.in-addr.arpa ripe4 78.in-addr.arpa 3600 172800 172800 3600
3.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
caduv.cz nic cz 3600 3600 900
eduskop.com gtld com 900 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.

Odstranění zóny

Problematické kvuli několika bugům v OpenDNSSEC [2].

Přibližný postup (nahradit $zone za zónu): 

ods-enforcer zone delete --zone $zone
ods-signer clear $zone
ods-signer update --all

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.

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=54947“