Re: Bind9 vragen
Hallo Wouter en anderen,
Bedankt voor je opmerkingen.
Ik zal na de tekst van Wouter reageren:
Op 13-07-18 om 15:17 schreef Wouter Verhelst:
> On Wed, Jun 27, 2018 at 02:04:37PM +0200, Paul van der Vlis wrote:
>> Hoi,
>>
>> Ik ben bezig met het implementeren van DNSsec en rndc op bind9 voor een
>> authoritatieve nameserver.
>
> Jeuj.
>
>> Rndc is een tool van bind om domeinen toe te voegen (eerder gebruikte ik
>> hiervoor eigen scriptjes).
>
> Neen.
>
> rndc is een tool om bind te beheren. Je kan daar inderdaad vanalles mee
> doen, zoals domeinen toevoegen, maar niet alleen dat.
Het kan inderdaad meer, maar tot nu toe gebruik ik het alleen voor het
toevoegen en verwijderen van domeinen.
>> Ik zie dat bind dingen opslaat in /var/cache/bind/ , bij een "cache"
>> denk ik aan een duplicatie van informatie, het origineel staat dan
>> ergens anders. Misschien is dat ook zo.
>>
>> De manuals die ik vind op internet over Bind zijn vaak oud of van
>> slechte kwaliteit. Degene die ik nog het beste vond is van Digital Ocean
>> en is van 2014. Wat me daar opvalt is dat ze bijvoorbeeld keys opslaan
>> in de root van /var/cache/bind/ , dat lijkt me een rare plek.
>
> De échte manual van bind is de "Administrator's Reference Manual":
>
> https://www.isc.org/downloads/bind/doc/
>
> Daar staat ook een "BIND DNSSEC Guide", die je wil lezen.
Ik had de officiële documentatie ondertussen ook gevonden.
Vreemd inderdaad dat ik daar in eerste instantie niet zocht, ik denk dan
vaak dat dat meer naslag is dan iets leesbaars.
>> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
>>
>> Wat lijkt jullie een goede plek om keys en zones neer te zetten, zelf
>> denk ik over /etc/bind/zones/ en /etc/bind/keys/ .
>
> Dat is ook (ongeveer) wat ik doe.
>
>> Voor de keys wil ik graag een aparte map, want ik overweeg ze ergens
>> anders neer te zetten zodat ze offline zijn, maar wel te mounten.
>
> Sure.
>
>> Vernieuwen jullie de KSK en de ZSK regelmatig of niet?
>
> Dat moet je doen voor de veiligheid.
Heb jij al bepaald hoe vaak je het gaat doen? En zet je ook harde
einddatums in de keys? Op het moment heb ik geen einddatums in de keys,
en ook niet in de RRSIG. Vooral dat laatste lijkt me fout.
>> En wat voor strategie hebben jullie voor online of offline bewaren?
>
> Persoonlijk doe ik dat laatste niet.
Op zich heb je die KSK key eigenlijk niet meer nodig, alleen als je een
nieuwe ZSK key wilt maken, of hem wilt intrekken.
>> Hoe vaak vernieuwen jullie de RRSIG, als er geen wijzigingen zijn?
>
> Dat kan je aan bind overlaten (en dat raad ik je heel erg aan):
>
> zone "dyn-cust.nixsys.be" {
> type master;
> update-policy {
> grant local-ddns zonesub any;
> grant wouter@GREP.BE zonesub any;
> grant cgi zonesub any;
> };
> allow-transfer { !notslaves; key latin; };
> file "/etc/bind/zones/dyn-cust.nixsys.be";
> key-directory "/etc/bind/keys";
> auto-dnssec maintain;
> };
>
> De belangrijkste lijnen hierboven zijn die met "key-directory" en
> "auto-dnssec". De eerste configureert waar je je keys dropt (die je van
> tijd tot tijd moet genereren met "dnssec-keygen", waarbij je ook tijden
> moet opgeven -- de manpage is daar redelijk duidelijk over).
Ik neem aan tijden waarna ze verlopen? Wat voor tijden hou jij aan?
> BIND zal
> die keys dan automatisch inladen, en de RRSIGs automatisch roteren. De
> KSKs worden ook automatisch vervangen op basis van de tijden die je aan
> dnssec-keygen meegegeven hebt. Alleen de glue van je ZSKs moet je nog
> handmatig updaten (want daar heeft BIND geen toegang toe).
De ZSK wordt door de KSK ondertekend en daaruit haalt hij/zij zijn
waarde. Ik neem dus aan dat je de KSK bedoeld met "glue"?
> Bovenstaande is een directe kopie uit mijn live configuratie van een
> domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
> klant draait een cronjob die gewoon een wget doet naar een CGI-script;
> dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
> aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
> :-)
Is dat vergelijkbaar met dyndns?
>> Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu
>> precies doet.
>
> Dat heeft te maken met de glue van je DNSSEC, en is redelijk belangrijk.
>
> DNSSEC werkt als volgt:
>
> - In de root zone zit er een aantal DS records voor de naam "be" met
> daarin de fingerprints van de KSKs van het domein "be"
> - In de "be" zone zitten er DNSKEY records voor die KSKs. Deze KSKs
> tekenen de RRs van de DNSKEY records van de ZSKs.
> - De ZSKs van de "be" zone tekenen dan alle andere RRs in die zone,
> inclusief het DS record voor "nixsys.be"
>
> Het zelfde verhaal wordt dan herhaald door "nixsys.be" dat DS records
> bevat voor "dyn-cust.nixsys.be", enzovoort.
>
> Het "dsset" bestand bevat simpelweg de DS records die je aan je parent
> zone moet doorgeven.
Dat is inderdaad gebruikelijk, maar niet bij .nl domeinen. Daar moet je
namelijk je pubkey uploaden en de DS records genereren ze zelf.
Dus vandaar mijn verwarring waarvoor dat dsset bestand nodig is.
"Door uit die DNSKEY records zelf de DS records te genereren houdt SIDN
controle over het daarbij gebruikte hash-algoritme."
Wat ik nog niet helemaal begrijp is het volgende: stel iemand kan de
nameserver manipuleren of de antwoorden vervalsen, dat is toch iets waar
dnssec tegen zou moeten beveiligen.
Maar dan kan hij toch ook antwoorden dat het domein geen dnssec heeft en
er dus ook niks te controleren valt. Hoe controleert een computer of een
programma dat?
>> Ik ben overigens aan het testen met het domein sociotech.nl. Mocht
>> iemand nog iets zien wat niet in orde is, dan hoor ik dat graag.
>
> Daarvoor is dnsviz.net nuttig:
>
> http://dnsviz.net/d/sociotech.nl/dnssec/
Ik ken het inderdaad. Jammer is wel dat je die pop-ups niet kunt
kopiëren. Ik zou liever een cli-commando hebben. Ik mis ook informatie,
zoals geldigheidsduur.
> Je ZSK en KSK zijn dubbel zo lang als aangeraden. Dit gaat
> performantie-issues veroorzaken, omdat de handtekening van je RRs
> daardoor niet meer binnen één DNS-pakket past.
Er is wel meer mis. Op het moment gebruik ik daar sleutels van het type
"7", die afgeraden worden maar nog wel geldig zijn.
Wat volgens mij ook niet juist is, is dat ik daar zowel de KSK key als
de ZSK key upload naar het .nl domein. Dit wordt vaak gedaan, maar
volgens mij wordt daardoor de KSK key zinloos en kun je net zo goed
alleen een ZSK key aanmaken. Kijk naar serieuze organisaties zoals
xs4all.nl, nlnet.nl, sidn.nl, daar is het nooit zo dat ze beide keys
uploaden. Maar het wordt wel heel veel gedaan.
Ik experimenteer ondertussen met een ander domein waar ik sleutels van
het type "13" gebruik, die een stuk veiliger en korter zijn (ECDSA Curve
P-256 with SHA-256), verder upload ik alleen de KSK key:
http://dnsviz.net/d/paulvandervlis.nl/dnssec/
Ik zag ook dat er nog een nieuw type "14" bestaat, daar weet ik nog wat
weinig van.
Het verbaasd me overigens dat google.com dnssec niet op orde heeft:
http://dnsviz.net/d/google.com/dnssec/
Ook apple.com en facebook.com hebben de boel niet op orde, ik dacht dat
ik laat was met dnssec, maar dat valt dus wellicht wel mee ;-)
En waarom dnsviz.net geen https heeft, dat zou je toch verwachten.
Wat me nog niet helemaal duidelijk is, is welke keys ik in het zonefile
moet zetten. Op het moment zet ik hier zowel de KSK key als de ZSK key
neer, maar ik weet niet zeker of ze er beide in moeten.
Mijn ZSK ondertekent zichzelf. Of dat nu een goede zaak is?
En heb ik nu wel of geen NSEC3, en NSEC3PARAM?
Groeten,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply to: