Re: Bind9 vragen
On Wed, Jul 18, 2018 at 11:10:44AM +0200, Paul van der Vlis wrote: > Op 17-07-18 om 12:19 schreef Wouter Verhelst: > > On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote: > > > > >> 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. > > > > Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24 > > uur, "because we can"; geen idee of dat nog het geval is (Belgacom is > > een bende incompetente idioten, dus daar ben ik geen klant van ;-) > > > > Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in > > principe enkel als je een MAC-adres verandert, of een machine meer dan > > een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is, > > of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP > > cache gecleared wordt, of dat soort dingen. > > Hier in NL heb je aardig wat providers waar je een vast IP krijgt. > Alleen als je dienst veranderd (bijvoorbeeld als je van ADSL naar VDSL > gaat) krijg je een ander IP. > > > Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief > > aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC > > ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor. > > Dat eerste kan hij; maar dat tweede niet zonder de key van de parent > > nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen > > RRSIG record is of dat de handtekening daarvan niet correct is, en > > gewoon die nameserver overslaan; hetzij door naar de tweede nameserver > > in zijn lijst met geconfigureerde nameservers te gaan, of door een root > > query te doen en zelf een cache op te bouwen. > > Hmm, ik begrijp het niet helemaal. Ben ook wat traag soms, ahum. > > servfail.nl is een test-domein waar de dnssec validitatie niet in orde > is. All bets are off, dan. Als het domein niet valideert voor DNSSEC, dan loopt alles fout, of het nu juiste of foute informatie is. > Als ik dnssec-validation uit zet op ns2.sociotech.nl en dan doe: > host servfail.nl ns2.sociotech.nl > > Dan krijg ik keurig een IP-nummer terug (alleen IPv6 overigens). > > Als ns2.sociotech.nl nu ook zou zeggen authoritatief te zijn voor > servfail.nl dan kan hij een verkeerd IP-nummer teruggeven. > Of vergis ik me? Nee, dat klopt. Maar DNSSEC kan daar uiteraard ook niks aan doen. > Wellicht moet ik iets omzetten op mijn laptop wat dnssec-validatie eist, > en wat anders een waarschuwing geeft? > > >> Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die > >> gewoon niet aan DNSsec doet. > > > > DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en > > DNSKEY records zijn ook gewoon records. Er is een manier om een > > nameserver om records te vragen waar die nameserver zelf niet van op de > > hoogte is. > > Daar heb je gelijk. > > > Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook > > alle DNS queries naar overal behalve die slechte nameserver blokkeren, > > maar dat valt wel op. > > Zou ik mijn firewall moeten instellen om DNS queries naar een bepaalde > nameserver te blokkeren? Dan zou ik toch eerst al moeten weten dat die > nameserver fout is? Je begrijpt me verkeerd :-) Als je in je voorgestelde koffiehuis zit, en de router van dat koffiehuis firewallt alle DNS requests weg tenzij die naar de nameserver die in het DHCP response zit, én die nameserver in het DHCP response blokkeert requests naar DNSSEC-related RRs, dan kan een eindgebruiker inderdaad geen DNSSEC doen. Maar dat valt dus wel op :-) [...] > > [1] met dien verstande dat NSEC3 hashing met een beetje GPU computing > > redelijk snel te breken is. > > Dat is volgens mij de reden dat het goed is om de ZSK key vaak te > verwisselen. Maar de details ken ik niet. Onder andere, ja. Maar er zijn nog andere redenen. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Bind9 vragen
Op 17-07-18 om 12:19 schreef Wouter Verhelst: > On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote: >> 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. > > Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24 > uur, "because we can"; geen idee of dat nog het geval is (Belgacom is > een bende incompetente idioten, dus daar ben ik geen klant van ;-) > > Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in > principe enkel als je een MAC-adres verandert, of een machine meer dan > een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is, > of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP > cache gecleared wordt, of dat soort dingen. Hier in NL heb je aardig wat providers waar je een vast IP krijgt. Alleen als je dienst veranderd (bijvoorbeeld als je van ADSL naar VDSL gaat) krijg je een ander IP. > Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief > aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC > ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor. > Dat eerste kan hij; maar dat tweede niet zonder de key van de parent > nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen > RRSIG record is of dat de handtekening daarvan niet correct is, en > gewoon die nameserver overslaan; hetzij door naar de tweede nameserver > in zijn lijst met geconfigureerde nameservers te gaan, of door een root > query te doen en zelf een cache op te bouwen. Hmm, ik begrijp het niet helemaal. Ben ook wat traag soms, ahum. servfail.nl is een test-domein waar de dnssec validitatie niet in orde is. Als ik dnssec-validation uit zet op ns2.sociotech.nl en dan doe: host servfail.nl ns2.sociotech.nl Dan krijg ik keurig een IP-nummer terug (alleen IPv6 overigens). Als ns2.sociotech.nl nu ook zou zeggen authoritatief te zijn voor servfail.nl dan kan hij een verkeerd IP-nummer teruggeven. Of vergis ik me? Wellicht moet ik iets omzetten op mijn laptop wat dnssec-validatie eist, en wat anders een waarschuwing geeft? >> Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die >> gewoon niet aan DNSsec doet. > > DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en > DNSKEY records zijn ook gewoon records. Er is een manier om een > nameserver om records te vragen waar die nameserver zelf niet van op de > hoogte is. Daar heb je gelijk. > Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook > alle DNS queries naar overal behalve die slechte nameserver blokkeren, > maar dat valt wel op. Zou ik mijn firewall moeten instellen om DNS queries naar een bepaalde nameserver te blokkeren? Dan zou ik toch eerst al moeten weten dat die nameserver fout is? > Inderdaad. Ben gisteren ook toevallig overgestapt naar backports bind > ;-) Ik nu ook. Bedankt voor je uitgebreide verhaal over NSEC3, ik ben de materie nog aan het bestuderen. > [1] met dien verstande dat NSEC3 hashing met een beetje GPU computing > redelijk snel te breken is. Dat is volgens mij de reden dat het goed is om de ZSK key vaak te verwisselen. Maar de details ken ik niet. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Bind9 vragen
On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote: > 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. Interesting; dat wist ik nog niet. > 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. Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24 uur, "because we can"; geen idee of dat nog het geval is (Belgacom is een bende incompetente idioten, dus daar ben ik geen klant van ;-) Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in principe enkel als je een MAC-adres verandert, of een machine meer dan een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is, of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP cache gecleared wordt, of dat soort dingen. [...] > >> 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. Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor. Dat eerste kan hij; maar dat tweede niet zonder de key van de parent nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen RRSIG record is of dat de handtekening daarvan niet correct is, en gewoon die nameserver overslaan; hetzij door naar de tweede nameserver in zijn lijst met geconfigureerde nameservers te gaan, of door een root query te doen en zelf een cache op te bouwen. > Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die > gewoon niet aan DNSsec doet. DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en DNSKEY records zijn ook gewoon records. Er is een manier om een nameserver om records te vragen waar die nameserver zelf niet van op de hoogte is. Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook alle DNS queries naar overal behalve die slechte nameserver blokkeren, maar dat valt wel op. > 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. Toch wel. > Ook een ISP zou je in principe verkeerde gegevens kunnen geven. Volgens > mij heel simpel via "split DNS". Niet met DNSSEC. > 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. Dat is inderdaad zo: wie de root key heeft kan foutieve NS, DS, en DNSKEY records de wereld insturen. Daar kan niks aan gedaan worden, en dat is inderdaad een probleem. De veiligheid van DNSSEC is gebaseerd op het axioma
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
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 wou...@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,
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 wou...@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
Re: Bind9 vragen
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.
> 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.
> 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.
> En wat voor strategie hebben jullie voor online of offline bewaren?
Persoonlijk doe ik dat laatste niet.
> 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 wou...@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). 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).
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
:-)
> 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.
> 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/
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.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Re: Bind9 vragen
Op 27-06-18 om 14:04 schreef Paul van der Vlis: > 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. Ik kan iedereen dit aanraden: https://www.sidn.nl/a/dnssec/dnssec-ondertekening-op-bind-named Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Bind9 vragen
Hoi, Ik ben bezig met het implementeren van DNSsec en rndc op bind9 voor een authoritatieve nameserver. Rndc is een tool van bind om domeinen toe te voegen (eerder gebruikte ik hiervoor eigen scriptjes). 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. 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/ . 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. Vernieuwen jullie de KSK en de ZSK regelmatig of niet? En wat voor strategie hebben jullie voor online of offline bewaren? Hoe vaak vernieuwen jullie de RRSIG, als er geen wijzigingen zijn? Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu precies doet. 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. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
