Re: Bind9 vragen
Hoi Wouter en anderen,
Op 15-07-18 om 12:29 schreef Wouter Verhelst:
> 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).
Ook dat kan tegenwoordig automatisch als er een eerste geldige key op
staat, kan deze worden vervangen. Kijk eens naar RFC 7344 en 8078.
Zelf heb ik ook het uploaden van de eerste keer nu geautomatiseerd, met
de API van de registrar (ik gebruik opendomainregistry.net, mensen die
interesse hebben kunnen de scripts krijgen).
>>> 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.
O, leuk. Hier in NL heb je wat vaker een vast IP-adres dan in België
denk ik. Maar hier rukt het dynamische gebeuren ook op, ahum.
>>>> 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 ;-)
Maar hoe weet je dat de parent een DS record heeft? Dat vraag je neem ik
aan aan de nameserver. Als die nameserver niet te vertrouwen is, dan
werkt dit dus niet.
Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die
gewoon niet aan DNSsec doet.
Denk bijvoorbeeld aan een situatie bij het koffietentje op de hoek. Je
logt in op de wifi, en je krijgt via DHCP een nameserver toegewezen. Les
uit bovenstaande is volgens mij dat dit niet OK is, ook niet met dnssec.
Ook een ISP zou je in principe verkeerde gegevens kunnen geven. Volgens
mij heel simpel via "split DNS".
Eigenlijk lijkt het mij daarom het beste qua security om op b.v. een
laptop zelf een nameserver te draaien, dat heb je zelf in de hand.
Wat ook nog een security aspect is als ik me niet vergis, is dat de
root-keys geheel in handen zijn van de Amerikanen. Het lijkt me dat ze
de boel kunnen vervalsen. Volgens mij hebben de Amerikanen de
ontwikkeling ook voor een belangrijk deel betaald (zoals de Bind
implementatie), net als wel meer kritische zaken (denk aan TOR).
>>>> 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.
Ah. Ik werk nu nog met Bind 9.10, maar overweeg ook over te stappen op
Bind 9.11 (het zit in Debian Backports en heeft lange support).
>>> 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 :)
Populaire hosting tools zoals Directadmin en Plesk doen dit volgens mij.
>> 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.
Ik ben niet helemaal zeker, en zou het graag willen controleren.
De geldigheid van de ZSK blijkt uit de geldigheid van de KSK key.
>> Mijn ZSK ondertekent zichzelf. Of dat nu een goede zaak is?
>
> Dat is ook nodig, ja.
Volgens mij is dat laatste niet nodig. Xs4all, SIDN, en NLnet doen het niet.
>> 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).
Oh?
> 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.
Ja, daar staat het inderdaad expliciet aan. Maar mijn vraag is meer of
het aan staat bij paulvandervlis.nl (dat gebruik ik op het moment om te
testen), en dat lijkt niet zo te zijn.
Betekent dit niet dat nu niet aan te tonen is dat een subdomein niet
bestaat? Is een wildcard eventueel nog een idee? (dan bestaat een
subdomein altijd).
Groeten,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply to: