|
Rozmiar: 17510
Komentarz: + url14: bind + dnssec
|
← Wersja 18 z 2026-06-19 07:59:23 ⇥
Rozmiar: 17500
Komentarz: aktualizacja konfiguracji xml: conf.xml - notify, kasp.xml po wdrożeniu nsec/nsec3
|
| Usunięcia zostały oznaczone w ten sposób. | Dodatki zostały oznaczone w ten sposób. |
| Linia 78: | Linia 78: |
| W pliku konfiguracyjnym bardzo ważne ustawienie: '''NotifyCommand''': zapewnia, że serwer ''nsd'' będzie świadom zmian oraz aktualizacji strefy. | |
| Linia 84: | Linia 85: |
| <PIN>*****</PIN> | <PIN>992404</PIN> |
| Linia 104: | Linia 105: |
| <NotifyCommand>/usr/local/sbin/nsd-control reload %zone</NotifyCommand> | |
| Linia 106: | Linia 108: |
| Linia 117: | Linia 118: |
| <?xml version="1.0" encoding="UTF-8"?> | |
| Linia 133: | Linia 135: |
| <!-- <NSEC3> <Resalt>P190D</Resalt> <Hash> <Algorithm>1</Algorithm> <Iterations>0</Iterations> <Salt length="0"/> </Hash> </NSEC3> --> |
|
| Linia 156: | Linia 148: |
| <Lifetime>P380D</Lifetime> | <Lifetime>P465D</Lifetime> |
Wydrukuj tę dokumentację Pokaż jako slajdy
Spis Treści
Konfiguracja DNSSEC w nsd
DNSSEC to rozszerzenie w konfiguracji strefy DNS zapewniające podpisanie każdego rekordu strefy w celu zapewnienia autentyczności odpowiedzi z serwerów DNS. DNSSEC bazuje na dwóch kluczach:
Zone Signing Key - klucz podpisujący strefę (jego czas życia powinien być relatywnie krótki - np. 3 miesiące
Key Signing Key - klucz podpisujący klucz ZSK. Czas życia KSK powinien być długi (przez analogię do certyfikatów): 1 rok, może 2-3 lata
Delegation Signer - rekord w DNSie (wprowadzany w panelu rejestratora), który zawiera informację o KSK (por. wikipedia:DNSSEC)
Zgodnie z zaleceniami DNSSEC, podpisywanie stref powinno się zmieniać co kilka dni (zmienny SALT), aby wykluczyć, że potencjalni atakujący odgadną klucz i będą w stanie odgadnąć, jak fałszować rekordy1
Instalacja oprogramowania
Za pomocą własnego repozytorium pakietów należy zainstalować niezbędne oprogramowanie:
pkg install -Uy nsd softhsm2 opendnssec2 bind-tools ldns
Konfiguracja NSD
Konfiguracja serwera nsd znajduje się w oddzielnym dokumencie. Drobne zmiany będą dotyczyły katalogu z plikami stref, ale będzie to zaznaczone w dalszym opisie.
Konfiguracja OpenDNSSEC
Konfiguracja OpenDNSSECa składa się z następujących składowych:
- Konfiguracja SoftHSM-a
- Konfiguracja samego OpenDNSSECa
Inicjalizacja SoftHSM
Pierwszym krokiem jest inicjalizacja SoftHSMa.
Przygotowania
mkdir -p /var/db/softhsm/tokens/
chmod 0700 /var/db/softhsm/
chmod 1777 /var/db/softhsm/tokens/
/usr/local/etc/softhsm2.conf
W pliku konfiguracyjnym konieczne jest poprawienie ścieżki na FreeBSD-ową
perl -pi -e 'next unless /directories.tokendir/; s/lib/db/' /usr/local/etc/softhsm2.conf
Inicjalizacja
softhsm2-util --init-token --slot 0 --label "OpenDNSSEC" --so-pin 1223456 --pin 123456
UWAGA Należy koniecznie zapamiętać PINy, o które jest pytanie w trakcie inicjalizacji. Będą później potrzebne do konfiguracji.
PINy mogą być dłuższe aniżeli 4 znaki.
Sprawdzenie SoftHSM
softhsm2-util --show-slots
Pliki konfiguracyjne opendnssec
Kolejnym krokiem jest utworzenie plików konfiguracyjnych opendnssec-a. Najłatwiej to wykonać poprzez kopię przykładowych konfiguracji a następnie modyfikacji2:
cd /usr/local/etc/opendnssec
cp addns.xml.sample addns.xml
cp conf.xml.sample conf.xml
cp kasp.xml.sample kasp.xml
cp zonelist.xml.sample zonelist.xml
addns.xml
UWAGA W przypadku podpisywania stref w plikach nie ma potrzeby tworzenie tego pliku konfiguracyjnego
<?xml version="1.0" encoding="UTF-8"?>
conf.xml
W pliku konfiguracyjnym bardzo ważne ustawienie: '''NotifyCommand''': zapewnia, że serwer ''nsd'' będzie świadom zmian oraz aktualizacji strefy.
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<RepositoryList>
<Repository name="SoftHSM">
<Module>/usr/local/lib/softhsm/libsofthsm2.so</Module>
<TokenLabel>OpenDNSSEC</TokenLabel>
<PIN>992404</PIN>
<SkipPublicKey/>
</Repository>
</RepositoryList>
<Common>
<Logging>
<Verbosity>3</Verbosity>
<Syslog><Facility>local0</Facility></Syslog>
</Logging>
<PolicyFile>/usr/local/etc/opendnssec/kasp.xml</PolicyFile>
<ZoneListFile>/usr/local/etc/opendnssec/zonelist.xml</ZoneListFile>
</Common>
<Enforcer>
<Datastore><SQLite>/usr/local/var/opendnssec/kasp.db</SQLite></Datastore>
<AutomaticKeyGenerationPeriod>P1097D</AutomaticKeyGenerationPeriod>
<WorkingDirectory>/usr/local/var/opendnssec/enforcer</WorkingDirectory>
</Enforcer>
<Signer>
<WorkingDirectory>/usr/local/var/opendnssec/tmp</WorkingDirectory>
<WorkerThreads>4</WorkerThreads>
<NotifyCommand>/usr/local/sbin/nsd-control reload %zone</NotifyCommand>
</Signer>
</Configuration>
kasp.xml
WAŻNE Musi być jedna polityka o nazwie default. Wtedy przy dodawaniu strefy do podpisywania nie ma konieczności podawania nazwy polityki (jeżeli byłaby więcej niż jedna).
WAŻNE Dla NSEC3 wartość Ieterations musi być zero. Zgodnie z narzędziem 8 wartość większa niż 0 jest błędna.
Po dogłębnej analizie, jak również sprawdzeniu prezentacji wartość dla Denial używany jest NSEC zamiast NSEC3
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<KASP>
<Policy name="default">
<Description>Polityka DNSSEC dla ns13.smb.waw.pl</Description>
<Signatures>
<Resign>PT2H</Resign>
<Refresh>P3D</Refresh>
<Validity>
<Default>P35D</Default>
<Denial>P35D</Denial>
</Validity>
<Jitter>PT12H</Jitter>
<InceptionOffset>PT3600S</InceptionOffset>
</Signatures>
<Denial>
<NSEC/>
</Denial>
<Keys>
<TTL>PT3600S</TTL>
<RetireSafety>PT3600S</RetireSafety>
<PublishSafety>PT3600S</PublishSafety>
<Purge>P25D</Purge>
<KSK>
<Algorithm length="2048">8</Algorithm>
<Lifetime>P2097D</Lifetime>
<Repository>SoftHSM</Repository>
</KSK>
<ZSK>
<Algorithm length="1024">8</Algorithm>
<Lifetime>P465D</Lifetime>
<Repository>SoftHSM</Repository>
</ZSK>
</Keys>
<Zone>
<PropagationDelay>PT43200S</PropagationDelay>
<SOA>
<TTL>PT3600S</TTL>
<Minimum>PT3600S</Minimum>
<Serial>datecounter</Serial>
</SOA>
</Zone>
<Parent>
<PropagationDelay>PT9999S</PropagationDelay>
<DS>
<TTL>PT3600S</TTL>
</DS>
<SOA>
<TTL>PT172800S</TTL>
<Minimum>PT10800S</Minimum>
</SOA>
</Parent>
</Policy>
</KASP>
zonelist.xml
Lista stref objętych podpisywaniem. Zasadniczo ods-enforcer korzysta z bazy danych. Natomiast można zrobić eksport listy stref w celu późniejszego importu (lub też aby mieć backup). Jest to też dobry mechanizm w celu poprawienia np. literówek w ścieżkach do plików.
WAŻNE Zmiana sposobu podpisywania danej strefy w pliku /usr/local/var/opendnssec/signconf/domena.xml nie powoduje zmiany polityki w momencie podpisywania. W celu aktualizacji konieczne jest wykonanie polecenia update all3
ods-enforcer zonelist export
ods-enforcer update all
ods-enforcer zone list
<?xml version="1.0" encoding="UTF-8"?>
<ZoneList>
<!--
********* Important changes to zonelist.xml in 2.0 ***************
In 2.0, the zonelist.xml file is no longer automatically updated when zones
are added or deleted via the command line by using the 'ods-enforcer zone add'
command. However, in 2.0 it is possible to force an update of the zonelist.xml
file by using the new 'xml' flag. This is in contrast to the behaviour in 1.4
where zonelist.xml was always updated, unless the 'no-xml' flag was used.
As a result in 2.0 the contents of the enforcer database should be considered
the 'master' for the list of currently configured zones, not the zonelist.xml
file as the file can easily become out of sync with the database.
The contents of the database can be listed using:
ods-enforcer zone list
and exported using the command
ods-enforcer zonelist export
The contents of the database can still be updated in bulk from the zonelist.xml
file by using the command:
ods-enforcer zonelist import (or ods-enforcer update zonelist)
-->
<Zone name="cdnx.pl">
<Policy>default</Policy>
<SignerConfiguration>/usr/local/var/opendnssec/signconf/cdnx.pl.xml</SignerConfiguration>
<Adapters>
<Input>
<Adapter type="File">/usr/local/etc/nsd/master/raw/pl/cdnx.pl.raw</Adapter>
</Input>
<Output>
<Adapter type="File">/usr/local/var/opendnssec/signed/pl/cdnx.pl.signed</Adapter>
</Output>
</Adapters>
</Zone>
</ZoneList>
Uruchomienie OpenDNSSEC
Po wykonanej konfiguracji można przejść do uruchamiania OpenDNSSECa.
ods-kaspcheck
Narzędzie pozwala sprawdzić poprawność konfiguracji plików ODS.
ods-enforcer-db-setup
Po sprawdzeniu konfiguracji można przejść do inicjalizacji bazy danych
ods-enforcer-db-setup
Uruchomienie demonów
Należy ustawić w plikach rc.conf możliwość uruchamiania całej usługi a następnie ją wystartować:
service opendnssec start
Zaimportowanie polityk
ods-enforcer policy import
# sprawdzenie:
ods-enforcer policy list
Podpisywanie strefy
Przygotowanie pliku
ods-enforcer korzysta z narzędzia ldns-read-zone do wczytania pliku strefy do podpisania. ldns-read-zone radzi sobie z uproszczoną składnią (czyli definicja $TTL, oraz uproszczone wpisy bez jawnego TTL - por. [ 8 ]), natomiast nie radzi sobie z parametrem $include. Rozwiązaniem problemu jest wykorzystanie narzędzia dig4:
dig axfr cdnx.pl @localhost > /usr/lcoal/etc/nsd/master/raw/cdnx.pl.raw
W konfiguracji NSD musi być dopuszczenie do AXFR z poziomu localhost (np. we definicji wzorca).
Skrypt pomocniczy
W celu rozwiązania problemu jest w repozytorium konfiguracji skrypt pomocniczy, który przygotowuje plik do podpisania. Użycie jest proste i przyspiesza przygotowanie konfiguracji do podpisywania.
cx.ldns-read-zone -f cdnx.pl.cf -t /usr/local/etc/nsd/master/raw/cdnx.pl.raw
Dodanie domeny do ODS
ods-enforcer zone add --zone cdnx.pl --input /usr/local/etc/nsd/master/raw/pl/cdnx.pl.raw --output /usr/local/var/opendnssec/signed/pl/cdnx.pl.signed
Wyświetlenie kluczy
Opcja -v jest potrzebna, aby poznać id klucza KSK. Można to też pominąć i po wklejeniu klucza w panelu rejestratora zostanie pokazany komunikat o właściwym (oczekiwanym) numerze klucza.
ods-enforcer key list -v --zone cdnx.pl
Wygenerowanie kluczy DS dla rejestratora
Po wygenerowaniu kluczy (co można sprawdzić w logach) można wygenerować rekordy DS dla rejestratora:
# wersja DIGEST
ods-enforcer key export --zone cdnx.pl --ds --keystate publish --keytype ksk
ods-enforcer key export --zone cdnx.pl --ds --keystate ready --keytype zsk
# wersja z pełnym kluczem SHA-1 (wymagane przez OVH)
ods-enforcer key export --zone cdnx.pl -s --keystate publish --keytype ksk
ods-enforcer key export --zone cdnx.pl -s --keystate ready --keytype zsk
W przypadku eksportu rekordów DS jest bardzo ważne, aby podać "status" oraz "typ" klucza (parametry --keystate oraz --keytype muszą być podane jednocześnie (por. [ 10 ]).
Strefa została podpisana, klucze zostały opublikowane u rejestratora. Ale w międzyczasie zostały zmienione serwery nazw (zmodyfikowane również wpisy w whois). Z jakiegoś powodu łańcuch podpisania został zerwany. Wylistowanie kluczy --keystate publish zwraca pustą listę (klucze formalnie są aktywne). Koniec końców konieczne było usunięcie kluczy DS z poziomu rejestratora i dodanie ich na nowo. Wszystko zaczęło się zgadzać.
Rejestrator
Za pomocą ponelu webowego rejestratora (np. OVH) należy dla danej domeny podać rekordy DS.
UWAGA OVH wymaga klucza SHA-1, a nie digest. Jeżeli nie zadziała manager, to można próbować przez API.
Konfiguracja NSD dla stref podpisanych
Najprościej jest wykorzystanie "wzorca" z konfiguracji NSD poprzez podanie innego źródła plików stref:
pattern:
name: master_zones_dnssec
zonefile: "/usr/local/var/opendnssec/signed/%z/%s.signed"
notify: NN.NN.NN.NN tsig_ns13
provide-xfr: NN.NN.NN.NN tsig_ns13
outgoing-interface: 10.2.2.36
provide-xfr: 10.2.2.0/24 NOKEY
Zaś w definicji strefy wykorzystać w/w wzorzec:
zone:
name: cdnx.pl
include-pattern: "master_zones_ns13_dnssec"
Zmiany w strefie
Ponowne podpisanie
Po wykonaniu zmian w pliku strefy (źródło) należy wykonać ponowne podpisanie strefy za pomocą narzędzia ods-signer:
ods-signer sign cdnx.pl
Przeładowanie pliku w serwerze nsd
Po ponownym podpisaniu nalezy wykonać aktualizację w samym serwerze nsd5:
nsd-control reload cdnx.pl
Źródła w sieci internet
https://nsrc.org/workshops/2017/nsrc-icann-dnssec-ma/labs/opendnssec-lab1.txt
https://wiki.opendnssec.org/display/DOCS20/Key+States+Explained
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html
Odnośniki do dokumentacji
(c) 2004 - 2026 BSD Serwis Krzysztof Stryjek. W przypadku błędów, poprawek proszę kontaktować się z administratorem wiki.
Trochę to dziwne. W dokumentacjach (patrz źródła) wygląda jak kopiowanie tego zalecenia z RFC?? Do wyjaśnienia. (1)
Jeżeli umieszczę pliki w repozytorium konfiguracji, to będzie trzeba poniższe zmodyfikować (2)
Chociaż jeszcze do potwierdzenia, czy na pewno. (3)
To zadziałało, ponieważ strefa była już działająca i wymagała tylko podpisania. Nadal pozostaje kłopot, jeżeli chcemy opublikować od razu strefę podpisaną. Zatem dig nie ma się do czego odwołać. Po drugie po wszelkich zmianach w pliku strefy (np. tym dołączanym ponownie trzeba utworzyć plik z uproszczoną składnią. (4)
Do wykonania odpowiednie skrypty i/lub zadania Makefile w celu automatyzacji procesu (5)
