LPS:DNSSEC - Provozní dokumentace

Z HelpDesk
Verze z 6. 2. 2023, 15:18, kterou vytvořil Valtri (diskuse | příspěvky) (tip kolem algoritmů v kasp)
(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)

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

Informace

Nástroje

OpenDNSSEC:

Dříve také ISC Bind (dnssec-signzone, dnssec-keygen).

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
  • ==> musí běžet OpenDNSSEC nástroje a propagace z OpenDNSSEC (ods-signer) do DNS

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.

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).

Vyrábění klíčů

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

Nastavuje se v podepisovacích politikách OpenDNSSEC.

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)

DNS servery si pak automaticky stahují nové klíče z root zóny (do /var/cache/named).

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. vyrobit nebo 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-copy/zcu/zones/${zone}.zone
ods-enforcer update all

    Poznámka: zde se automaticky vyrobí nový klíč (toto se řídí volbou Enforcer/ManualKeyGeneration) v conf.xml. Jinak by se vyrobil příkazem ods-enforcer key generate --policy $policy

  3. úprava na primárním DNS - je potřeba použít zónový soubor s koncovkou .signed
    • master zóny jsou zde: /var/sauron/dns9-additive/zcu/named.conf.local-in-master
  4. počkat na propagaci zóny (zapnutí DNSSEC v nadřazené zóně musí být, až když jsou aktualizované cache)
    • OpenDNSSEC pošle notifikaci
    • anebo sledovat stav klíče (příkaz ods-enforcer key list --zone $zone a stav "waiting for ds-seen")
    • raději počkat ještě i čas mezi 2. a 3. (ale není striktně potřeba - v podepisovacích politikách OpenDNS máme hodinovou rezervu)
  5. poslat otisky klíčů do nadřazené zóny ($zone nahradit za zónu):

    Nutno nastavit u registrátora.

    Otisk klíče: 

    ods-enforcer key export --zone $zone --keystate publish --keytype KSK --ds

    Ale pozor: registrátor může chtít plný klíč (aka DNSKEY) místo otisku (DS). V jeho nadřazené zóně ale musí skončit otisk (DS záznam). 

    ods-enforcer key export --zone $zone --keystate publish --keytype KSK
  6. kontrola + potvrzení DS - finální krok (nahradit $zone a $tag): 
    # kontrola záznamu v nadřazené zóně
# 1) jaké má být DS
ods-enforcer key export --zone $zone --keystate ready --keytype KSK --ds
# 2) co je v nadřazené zóně
dig -t DS $zone

# zjištění si key tag
ods-enforcer key list --zone $zone --keytype KSK -v

# potvrzení, že DS záznam je zaregistrovaný - "byl viděn"
ods-enforcer key ds-seen --zone $zone --keytag $tag
  7. zvážit přidání do monitoringu:
    • monitorování: Icinga Director -> Hosts -> "dns.zcu.cz" -> dnssec_domains
    • kritické věci: Bussiness Process -> "HelpDesk" -> "Síťové služby"

Úprava podepisovací politiky

Upravit /etc/opendnssec/kasp.xml přes cfengine, viz #Podepisovací politiky zón.

Cfengine automaticky zavolá příkazy: 

ods-enforcer policy import
ods-enforcer enforce

Přidání podepisovací politiky

Upravit /etc/opendnssec/kasp.xml přes cfengine, viz #Podepisovací politiky zón.

Cfengine automaticky zavolá příkaz: 

ods-enforcer policy import

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
changingourstory.eu eu eu. 86400 86400 (86400?) 600
caduv.cz

dnyvedy.cz
eduskop.cz
zameknectiny.cz
zcu.cz

nic cz 3600 3600 3600 900
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 86400 900
1.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa

2.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa
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
228.147.in-addr.arpa ripe4-147 147.in-addr.arpa 86400 86400 10800 10800
242.128.78.in-addr.arpa

243.128.78.in-addr.arpa

ripe4-78 78.in-addr.arpa 3600 172800 172800 3600
eduskop.com com com 900 172800 86400
eduskop.org org org 900 86400 86400
pilsen.university university university. 86400 86400 86400 86400
fek.zcu.cz

fpe.zcu.cz

zcu zcu.cz 86400 86400 86400 3600

Časování v politikách vychází ze SOA a TTL zóny a rodičovské zóny.

Zrušení podepisování

Základem je nechat podepisování funkční a odstranit nejprve DS záznam z nadřazené zóny. Dále počkat předepsaný čas, a pak teprve lze podepisování zrušit.

Zde postup pro zrušení DNSSEC pro všechny zóny v politice (body 3-6 jsou pak pro každou zónu zvlášť):

  1. editace politiky v kasp.xml: odstranění sekcí <ZSK></ZSK> a <KSK></KSK>
  2. update politik 
    ods-enforcer policy import
  3. počkat na "waiting for ds-gone" z OpenDNSSEC (email, nebo ve výpisu ods-enforcer key list) - mělo by být hned
  4. odstranit DS záznamy z nadřazené zóny
  5. po dokončení potvrdit OpenDNSSECu (nahradit $zone a $keytag za správné hodnoty): 
    #zone=228.147.in-addr.arpa
#keytag=21051
ods-enforcer key ds-gone --zone=$zone --keytag=$keytag
  6. počkat na dokončení

Další možnost je vyrobit totožnou politiku, jen bez sekce <ZSK></ZSK> a <KSK></KSK> a do ní zónu přesunout (pomocí ods-enforcer zonelist export, editace a ods-enforcer zonelist export).

Odstranění zóny

Bacha! Pokud je pro zónu zapnuté DNSSEC, postupovat nejprve podle postupu #Zrušení podeposování.

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

Také se zrušením propagace skrz OpenDNSSEC se mění formát serial v SOA, takže se zóna hned správně nevypropaguje. Ale nemělo by to být kritické.

  1. úprava na primárním DNS - je potřeba přestat používat zónový soubor s koncovkou .signed, tj. odstranit koncovku
  2. odstranění z OpenDNSSEC (nahradit $zone za zónu): 
    ods-enforcer zone delete --zone $zone
ods-signer clear $zone
ods-signer update --all
  3. čistky (není kritické, nahradit $zone za název zóny)
    • na primárním DNS: zmazat /etc/bind/zones/$zone.signed
    • na sekundárech (kvuli serial v SOA):
    rndc retransfer $zone in internal-civ-lps-in
rndc retransfer $zone in internal-in

Pročištění zóny

Zrušení a znovuvygenerování všech podpisů.

Čas od času mohou zůstat viset některé DNSSEC záznamy, které OpenDNSSEC neodstraní, ale zároveň zůstává neudržovaný expirovaný RRSIG. Např. drobný bug při přidání delegace do podzóny (změna A záznamu na glue).

Postup ($z je refreshovaná zóna): 

ods-signer zones
z=zcu.cz

ods-signer clean $z
ods-signer sign $z

Výměna klíče

Týká se Key Signing Key (Zone Signing Key rotujeme automagicky).

  1. kontrola a případně update časování v #Podepisovací politiky zón
  2. událost způsobující key rollover - editace podepisovací politiky (/etc/opendnssec/kasp.xml přes cfegine) nebo ruční rollover (např. ods-enforcer key rollover --zone $zone --keytype KSK)
  3. počkat na "Submit" a "Retract" emaily
  4. změnit klíč v nadřazené zóně u registrátora
  5. kontrola + potvrzení změn 
    # zjištění aktuálního stavu
dig -t DS $zone

# zjištění si stavů klíčů a key tagy
ods-enforcer key list --zone $zone --keytype KSK -v

# potvrzení, že DS záznam je zaregistrovaný - "byl viděn"
ods-enforcer key ds-seen --zone $zone --keytag $tag1

# potvrzení, že DS záznam je zrušen - "zmizelý"
ods-enforcer key ds-gone --zone $zone --keytag $tag2
  6. očekávaný výsledek: původní DS bude "unretentive" a nový DS "rumoured" (časem se přepne na "omnipresent" a původní podpisy zmizí) 
    ods-enforcer key list --zone $zone --keytype KSK -d

Repozitář s klíči

SoftHsm2 poskytuje modul pro rozhraní PKCS11, se kterým lze pracovat standardními nástroji. 

 apt-get install opensc

Kontrola (zobrazení seznamu objektů): 

pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --label OpenDNSSEC --login --pin $pin --list-objects

Změna user PIN: 

pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --label OpenDNSSEC --login --pin $pin --change-pin --new-pin $newpin
chown -R opendnssec. /var/lib/softhsm/tokens/*

Pokud se nepoužívá Security Officer PIN (=je stejný), změnit také ten.

Dále viz #Po změně PIN.

Změna SO PIN: 

pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --label OpenDNSSEC --login --login-type so --so-pin $pin --change-pin --new-pin $newpin
chown -R opendnssec. /var/lib/softhsm/tokens/*

Reset user PIN pomocí SO PIN: 

pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --label OpenDNSSEC --login --login-type so --so-pin $pin --new-pin $newpin
chown -R opendnssec. /var/lib/softhsm/tokens/*

Dále viz #Po změně PIN.

Po změně PIN

Po nastavení nebo změně PIN je potřeba aktualizovat konfiguraci. Ta je řízena přes cfengine.

Postup na cfengine master serveru (nahradit $fqhost za hostname, root-XXX.pub za odpovídající public klíč): 

read pin
mkdir -p /var/cfengine/masterfiles_private/$fqhost/etc/opendnssec
echo -n "$pin" | cf-keycrypt -e /var/cfengine/ppkeys/root-XXX.pub -i - -o /var/cfengine/masterfiles_private/$fqhost/etc/opendnssec/cfengine.pin.crypt

cfengine

Práce s cfengine a službou OpenDNSSEC.

  1. shození cfengine a zrušení automatického nahazování: 
    service cfengine3 stop
vim /etc/cron.d/cfengine3
  2. editace: 
    cd ~/cf
git pull
# vim templates/etc/opendnssec/...
  3. aplikace změn lokálně (odlehčená varianta, co změní jen službu opendnssec): 
    cf-agent -KIf ./promises.cf -C -D SERVICE_opendnssec
  4. kontrola: 
    pgrep -a ods
less /var/log/syslog
  5. commit (publikace změn): 
    git commit -a
#git pull --rebase
git push
cf-merge
  6. počkat a nahodit cfengine: 
    sleep 600
service cfengine3 start

Cesty

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

/etc/opendnssec/kasp.xml

Podepisovací politiky, viz #Podepisovací politiky zón.

Změny: ručně administrátory přes cfengine

/usr/local/lib/opendnssec/mailer.sh

Notifikační mailovací skript.

/var/lib/opendnssec/signed

Podepsané zóny. Vyzobává si z toho data skript /var/sauron/notify-zone.sh automaticky volaný z OpenDNSSEC.

Změny: automaticky z OpenDNSSEC

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.

Klient systemd-resolved

Nikdy nepoužívat. :-) Je tam plno chyb, které zamezuje používání (stav ke 2022: zpracování drobně chybných domén s chybějícím SOA, panikaří a vypíná DNSSEC nebo rezoluci, neumí správně pracovat s NSEC a NSEC3, ...).

Zapnutí explicitní validace na straně klienta: https://wiki.archlinux.org/title/Systemd-resolved#DNSSEC

/etc/systemd/resolved.conf.d/dnssec.conf: 

 [Resolve]
 DNSSEC=true

Test: 

 resolvectl query sigfail.verteiltesysteme.net
 resolvectl query sigok.verteiltesysteme.net

OpenDNSSEC kasp.xml

Syntaxe vyžaduje u algoritmu vždy vyplněn počet bitů (>0), ale pro ECDSA a Edward se hodnota nepoužívá.

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

Troubleshooting

dig

Získání informací pomocí dig ($rr nahradit za doménu, $z za zónu): 

#rr=www.rhybar.cz
dig +cd +dnssec +trace -t A $rr

#z=rhybar.cz
dig +cd +dnssec -t DNSKEY $z
dig +cd +dnssec -t SOA $z

Dobré porovnat s informacemi z autoritativního serveru dané zóny.

dnsviz

Dobré porovnat výsledky s rekurzivním DNS s nacachovanými daty (např. -s 147.228.52.11) a s autoritativními DNS (-A): 

#z=rhybar.cz
dnsviz probe -a . -s dns.zcu.cz ${z} | tee ${z}-cached.json | dnsviz graph -Thtml > ${z}-cached.html
dnsviz probe -a . -A ${z} | tee ${z}.json | dnsviz graph -Thtml > ${z}.html

Odkazy

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