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 dat de root key te
vertrouwen is. Is dat niet het geval, dan valt het hele kaartenhuisje in
elkaar...
[...]
> > 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).
Inderdaad. Ben gisteren ook toevallig overgestapt naar backports bind
;-)
[...]
> >> 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.
En? Het is niet omdat ze "populair" zijn dat ze ook goed werken.
[...]
> >> 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.
Ja, maar in de parent staat alleen het DS record, niet de volledige key.
Zonder de key kan de zone niet gevalideerd worden, dus *moet* het DNSKEY
record van je KSK ook in de zonefile aanwezig zijn.
> >> 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.
Hmm. OK, misschien vergis ik me.
> >> 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?
NSEC3 is een recursieve hashing van de namen. Om niet bij elk NSEC3
record een header te moeten zetten met informatie over *hoe* de boel
juist gehashed wordt (welk algoritme, hoeveel herhalingen, etc), heeft
men besloten om die metadata in een apart record te steken. Dat is
NSEC3PARAM. Dat record bevat (naast de normale velden die in elk DNS RR
zitten) de volgende velden:
- Algorithm (welk hashing-algoritme gebruikt wordt)
- Flags (8-bit flags field, momenteel maar één vlag, "opt out")
- Iterations (hoeveel keer de velden in de zone gehashed zijn)
- Salt (om rainbow attacks etc tegen te gaan)
> > 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.
Inderdaad.
> 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).
Neen.
DNSSEC geeft een expliciete volgorde aan alle RRs: ze zijn geordend
volgens naam (a.example.com komt voor b.example.com) en daarna ook
volgens RR type (exacte volgorde weet ik daar niet, maar ik gok dat het
gewoon de nummer van het RR type is die van belang is).
Wanneer je in een domein example.com met records a.example.com en
c.example.com vraagt naar de domeinnaam b.example.com, dan krijg je een
antwoord dat dat niet bestaat, met NSEC erbij. Dat zal er dan als volgt
uitzien:
a.example.com <ttl> IN NSEC c.example.com A
(plus uiteraard de RRSIG)
Wat wil zeggen dat er een "A" record is voor a.example.com, en dat er
records bestaan voor c.example.com.
Als ik "dig +dnssec bestaatniet.paulvandervlis.nl" ingeef, dan ziet de
authority section er als volgt uit:
;; AUTHORITY SECTION:
autoconfig.paulvandervlis.nl. 10800 IN RRSIG NSEC 13 3 86400 20180810125547 20180711125547 583 paulvandervlis.nl. /cJm7j29VEM9g+pXGuR97Wks7Kw/PY+c/2bNAx3ei2Jp7eTSIovg4UN1 o1wMRiKdeZMwQ084HYxnvWoUwTSjXw==
autoconfig.paulvandervlis.nl. 10800 IN NSEC localhost.paulvandervlis.nl. CNAME RRSIG NSEC
paulvandervlis.nl. 10800 IN SOA ns1.sociotech.nl. paul.vandervlis.nl. 2018062904 14400 7200 2419200 86400
paulvandervlis.nl. 10800 IN RRSIG SOA 13 2 86400 20180810125547 20180711125547 583 paulvandervlis.nl. rVUrSCe3z5ne9RA2URUFA8Vgd6CXmRawaA9XeUJJmMY16/lZt13WG2Ui hkdn+OcoCkBBDjVcsHHuLRZvKuHPsg==
paulvandervlis.nl. 10800 IN RRSIG NSEC 13 2 86400 20180810125547 20180711125547 583 paulvandervlis.nl. ox3yVbDE82tOA9QkV6QjwT3gGOgIpVBvFmzllS4HKSuILRz2kK1VMBd8 +rh8yEsx7u5+sJZdSBXx7DqerHkFOw==
paulvandervlis.nl. 10800 IN NSEC autoconfig.paulvandervlis.nl. A NS SOA MX AAAA RRSIG NSEC DNSKEY
De eerste lijn is het RRSIG record voor de tweede lijn.
De tweede lijn is het NSEC record, wat aangeeft dat
autoconfig.paulvandervlis.nl een CNAME record is voor iets anders, en
dat er tussen autoconfig en "localhost.paulvandervlis.nl" geen andere
namen aanwezig zijn.
Dan volgt de SOA, en om de één of andere reden (is me niet helemaal
duidelijk waarom) een NSEC record voor de data tussen paulvandervlis.nl
en autoconfig.paulvandervlis.nl.
Hiermee weet ik dat:
- autoconfig.paulvandervlis.nl de (alfabetisch) eerste naam in jouw
domein is waar gegevens voor bestaan, en dat dat een CNAME is
- Er geen gegevens bestaan tussen autoconfig.paulvandervlis.nl en
localhost.paulvandervlis.nl
Als ik meer informatie wil, dan kan ik een domeinnaam zoeken die
alfabetisch na localhost komt; dan heb ik daar meteen ook de RR types
die beschikbaar zijn op "localhost". Enzovoort.
Omdat sommige TLD registries dit soort gegevens wettelijk niet mogen
beschikbaar maken, heeft men NSEC3 uitgevonden. Daarbij neemt men de
naam (in het voorbeeld is dat "a"), gooit de salt erachter (met "azerh"
als salt wordt dat "aazerh", en gooit dat door een hashing algoritme
(met SHA1 als hashing algoritme en 1 iteratie wordt het resultaat van
dat hashen dan 7ce67c3e683ea46ee155a8e391e2d0a5a6e4150a). De
gehashte namen worden dan gesorteerd, en NSEC3 records worden gemaakt op
dezelfde manier en met dezelfde gegevens als NSEC records, maar met de
gehashte namen ipv de cleartext namen.
Voor de naam "c" wordt met dezelfde parameters
da7384f6f8a9ea51afa85b66ceb0dd6574d725ee gegenereerd; voor de naam "b"
wordt d21a0637abf0124de99fcbd21b8226c89fc7ccf8 gegenereerd.
Wanneer ik nu een vraag doe naar "b.example.com", dan reageert een
example.com server met
da7384f6f8a9....example.com <ttl> NSEC3 7ce67c3e68.....example.com
(verkort voor de duidelijkheid). De client kan dan verifiëren dat
"b.example.com" met de parameters in NSEC3PARAM inderdaad tussen die
twee hashes sorteert, en er dus geen geldige naam bestaat voor "b"; maar
het verschil is dat mensen die het volledige domein willen kennen, dat
met NSEC3 niet[1] kunnen, maar met NSEC wel.
[1] met dien verstande dat NSEC3 hashing met een beetje GPU computing
redelijk snel te breken is.
--
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: