Re: Bind9 vragen
On Fri, Jul 13, 2018 at 09:24:44PM +0200, Paul van der Vlis wrote:
> 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:
> > 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.
Heh, in dit geval niet echt :-)
> >> 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.
KSK wordt aangeraden om jaarlijks te vernieuwen.
ZSK hangt af van de grootte van je domein. Eens per drie maand is
voldoende voor een gemiddeld domein.
> >> 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.
ACK.
> >> 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?
Zie boven :-)
> > 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"?
Ik had me in bovenstaande paragraaf inderdaad vergist. De glue is voor
de KSK, niet voor de ZSK. De ZSK kan je automatisch laten vervangen, de
KSK niet (daarvoor moet je de glue idd updaten).
> > 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?
Sortof. Alleen draai je het zelf en heeft dyndns geen DNSSEC, VZIW.
> >> 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.
Het parent domein heeft een DS-record nodig. Dat DS-record kan je
inderdaad makkelijk genereren vanuit je pubkey (het is uiteindelijk
gewoon een hash). Hoe het parent domein aan dat DS record geraakt, is
minder belangrijk.
Als je zelf het parent domein beheert, dan kan je via dat dsset
bestand--of via het bind-commando 'dnssec-dsfromkey'--het DS record zelf
genereren. Dit is in jouw geval niet van toepassing.
> 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."
Juist.
> 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.
Dat is de raison d'être van DNSSEC, ja.
> Maar dan kan hij toch ook antwoorden dat het domein geen dnssec heeft en
> er dus ook niks te controleren valt.
Neen.
> Hoe controleert een computer of een programma dat?
DNSSEC is alleen veilig als er een ononderbroken keten van DS en DNSKEY
records is van een trust anchor (meestal de root key) tot het domein.
Als er ergens een onderbreking is, dan kan een aanvaller inderdaad valse
antwoorden voor die onderbreking genereren en claimen dat er voor child
domeinen geen DNSSEC aanwezig is.
Als een parent domein een DS record heeft voor een child domein, dan
MOET dat child domein een overeenkomstige DNSKEY record hebben. Is dat
niet het geval, dan wordt het domein als ongeldig gezien en genegeerd.
Als er een ononderbroken keten van DS en DNSKEY records bestaat van het
trust anchor tot het domein, dan kan een aanvaller alleen de afwezigheid
van DNSSEC faken door eerst een private key te kraken.
(Als dat gebeurt, dan is er uiteraard een probleem ;-)
> >> 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.
Die geldigheidsduur staat niet in DNS (buiten dan de TTL-waarden die op
de DNSKEYs staan), dus dat kan dnsviz.net ook niet tonen.
BIND 9.11 heeft ook een cli verificatietool voor aanwezige keys:
dnssec-coverage.
> > 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.
Mja, dat gebruikt SHA1, wat een broken algoritme is. Je wilt écht
overschakelen op ten minste SHA256.
> Wat volgens mij ook niet juist is, is dat ik daar zowel de KSK key als
> de ZSK key upload naar het .nl domein.
Dat doe je inderdaad beter niet. Alleen de KSK moet je naar het parent
domein sturen.
> Dit wordt vaak gedaan, maar
> volgens mij wordt daardoor de KSK key zinloos en kun je net zo goed
> alleen een ZSK key aanmaken.
idd
> 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.
En dat is dom :)
> 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.
Ja, ze moeten er zeker allebei in, anders is je domein ongeldig.
> Mijn ZSK ondertekent zichzelf. Of dat nu een goede zaak is?
Dat is ook nodig, ja.
> En heb ik nu wel of geen NSEC3, en NSEC3PARAM?
NSEC3 is optioneel. Het is ook achterhaald, en niet echt zinvol meer
(kan omzeild worden op een GPU in redelijk korte tijd). Als je wel NSEC3
wilt gebruiken, dan is NSEC3PARAM vereist, anders kan je de NSEC3
records niet valideren. Als je dat niet hebt aanstaan, dan is NSEC3PARAM
nutteloze data (maar kan het ook geen kwaad).
Er is werk aan NSEC5 dat dat zou moeten oplossen; of je kan Cloudflare
nadoen en op afroep een NSEC record genereren dat net klein genoeg is om
te antwoorden dat een bepaald record niet bestaat, maar niet groot
genoeg om het hele domein te enumereren. Dat laatste kan je wel niet met
BIND, die heeft daar de nodige support niet voor.
"dig +dnssec bestaatniet.sociotech.nl" stuurt correct twee NSEC3 records
terug, dus je hebt het wel degelijk aan staan.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: