Názory k článku DNSSEC s BIND 9.9 snadno a rychle
-
Díky za pěkný návod, je to hezky shrnuto. Dovolím si tady položit dotaz, který se možná netýká jenom mě. Asi před rokem jsem nad inline-signingem také bádal. Rád bych již také zavedl DNSSEC na naši firemní doménu, ale je to komplikováno takovou nepěknou historickou věcí - split horizon DNS. Je to prostě tak, že kdysi v hluboké minulosti jsme se rozhodli, pro použití stejného doménového jména uvnitř fy i vně směrem do Internetu. Prasárna je, že některé služby mají v interní síti jméno s RFC1918 interní adresou a vně pak totéž jméno s externí adresou (provoz jde například přes web rev proxy apod.) Problémy vznikají samozřejmě ve chvílích, kdy si někdo při přechodu mezi interní sítí a Internetem zaklapne/uspí notebook a přejde na druhou stranu (fyzicky) nebo si zapne VPN. Notebook si chvíli drží v DNS cache nevhodný záznam z druhé strany. Je to samozřejmě špatně a jednak by se služby veřejně přístupné měly pokud možno umisťovat do DMZ a druhak by se vnitřní DNS mělo zřejmě dávat do subdomény, např. int.example.com nebo lan.example.com apod, ale už to tak je a teď s tím asi těžko něco udělám. Záznamů je moc a asi nepřipadá v úvahu nějak rychle tohle změnit (ano to možná nepůjde snadno ani v horizontu let).
No a teď tedy jak na tohle nejlépe nasadit DNSSEC? Vnější a vnitřní DNS leží na fyzicky oddělených name-serverech. Mě se to jeví tak, že bude nejlépe zřídit dalši "hidden" master, kde se budou všechny zóny udržovat a podepisovat a současné name-servery si budou zóny stahovat z tohoto hidden mastera. DNS views se při zone transferu na slave rozliší pomocí TSIG klíče (to mám již vyzkoušeno). Pokud se použije takto pouze jeden klíč ZSK, tak by mohl podepsat shodně zóny pro různé pohledy zone views - tedy podpisy shodných záznamů budou shodné také ve vnitřním i vnějším DNS. Nějaká jiná cesta nebo zádrhele tohoto řešení?
-
Taky možnost, ale motivace k tomu jednomu masteru je mít všechny data na jednom místě a jednou asi přejdeme na systém, že zóny generujeme z databáze a proč řešit distribuci těch DNS dat, když to samo DNS má vyřešené. Ještě to rozvážím čím začít. Snížit TTL u těch měňavých záznamů - to je správná poznámka - to musím zkontrolovat.
-
M. (neregistrovaný)
Ano, podepisovat obě verze zóny stejným klíčem je řešení, pokud je to na různých fyzických serverech, tak ten hidden master je asi nejvhodnější řešení a rozlišení dle TSIG pro AXFR funguje (používáme taktéž).
Jinak problém s tím, že někteří debilní klienti neflushnou DNS cache při přechodu vnitřek/vnějšek řešíme tak, že servery, které mají veřejnou IP adresu ve veřejném DNS, tak jsou i ve vnitřním DNS na stejné veřejné adrese a vnitřní DNS je bohatší tak o to, co je jen uvnitř na neveřejných adresách. Od té doby je s tímto přechodem klid. -
Njn, vono použít tu veřejnou adresy vždy nejde. Protože mě třeba napadá jedna nejmenovaná aplikace, která má doménovou autentizaci (Active Directory) přes tu neveřejnou adresu a přes tu veřejnou adresu se lidi hlásí jménem heslem a tak podobně :-/. Taky to má trochu nižší dostupnost, protože kdyby nedejbože padl cluster firewallu... tak přes vnitřní adresy by mohla nějaká důležitá aplikace jet dál, kdežto pád firewallu ji znepřístupní na veřejné adrese. No ano, asi dost nepravděpodobný scénář doufám ;-).
-
H0axZlatý podporovatelPodle http://www.root.cz/clanky/moderni-dnssec-elipticke-krivky-a-nevinne-lzi/ jsou tyto P* nebezpečné. Je to i tak nejlepší řešení?
-
Ondřej CaletkaZlatý podporovatelTo je otázka spíš pro někoho, kdo se vyzná v šifrách. Nemyslím si ale, že by tyto NIST křivky představovaly nějaké bezprostřední ohrožení v tuto dobu.
Jediná další eliptická křivka, která je standardizována v DNSSECu, je ruská ECC-GOST, o které se toho moc neví a jejíž implementace lze spočítat na prstech jedné ruky po intenzivní práci na cirkulárce.
-
djarck (neregistrovaný)
Vdaka za skvely clanok!
Mal by som par otazok, ak viete niekto poradit.
Nejaku dobu spat sa doporucoval tusim powerdns ako autoritativny
nameserver (myslim, ze prave autor clanku ho doporucoval)
a myslim, ze to bolo prave z dovodu inline signingu.
Rozumiem tomu spravne, ze v tejto chvili sa vlastnosti bindu
a powerdns "vyrovnali" z pohladu DNSsecu a signingu?Ina vec vec bola v oblasti rekurzivneho nameservera, tam
bol tusim powerdns recurzor z pohladu DNSsecu nie velmi
dobre a doporucoval sa tusim knot (alebo to bol djdns?).Ked to zhrniem, zaujimalo by ma, ake je v tejto chvili doporucenie,
ze ktory nameserver sa z pohladu DNSsecu hodi najlepsie na nasadenie
ako autoritativneho NS a ktory ako rekurzivneho? -
Ondřej CaletkaZlatý podporovatel
Začnu rekurzivními servery. Z těch FOSS umí DNSSEC jen dva - BIND a Unbound, oba zhruba stejně dobře, o jiných tak nemá cenu uvažovat. Tedy do chvíle, než CZ.NIC Labs prohlásí Knot DNS Resolver alias kresd za stabilní.
U autoritativních serverů je situace složitější. Obecně se nedá nic zkazit použitím DNS serverů, které jsou používány pro kořenové DNS servery. Tam se z OSS používá BIND, NSD a Knot DNS.
PowerDNS jsem pokud vím nikdy nedoporučoval, už jen z toho důvodu, že jsem to nikdy ani neinstaloval. Ale slyšel jsem, že podpora online podepisování je tam na velmi dobré úrovni a pro menší nasazení, kde nejsou extrémní požadavky na počet odpovědí za sekundu to nejspíš může vyhovovat.
Rozhodně bych se doporučoval vyhnout softwaru Tinydnssec, což je fork djbdns. Jeden velký český hoster ho nasadil a pak zplakal (resp. spíše komunita zplakala) nad nevalidními daty, které to v jistých okrajových případech (neexistující jméno pokryté žolíkem) generuje.
-
djarck (neregistrovaný)
Mate pravdu, bol to unbound (a nie knot ani djdns) pre dnssec rekurzor, dakujem.
Mozno ten PowerDNS ste nie ze doporucoval, ale v podstate ste tusim (v tom case)
pisali, ze je to jediny autoritativny NS, co vie podpisovat on-the-fly, ale tak uz
to asi nie je dolezite teraz. Asi to bolo spomenute niekde na Installfeste 2014.Este by som sa chcel spytat na doporucenie resp. skusenost.
Zvazujem, ze presuniem konfiguraciu DNS do nejakej DB, ci uz SQL alebo LDAP.
Co som pozeral, tak LDAP vie jedine PowerDNS, ale nie je uz oficialne
supportovany. Ostava teda SQL backend pre BIND alebo PowerDNS.Mate nejaku skusenost alebo informacie o tom, ako funguje on-the-fly podpisovanie
s DB backendami? -
Ondřej CaletkaZlatý podporovatel
Zkušenosti s použitím databáze nemám. Osobně bych doporučoval se takovému přístupu spíše vyhýbat, právě kvůli vazbě takového řešení na jeden konkrétní software. Pokud je vám jedno, jestli to bude LDAP, nebo SQL, tak nepoužívejte ani jedno a místo toho zvolte jako databázi obyčejné DNS s dynamickými updaty. Opět je možné nabrat inspiraci u doménových registrů, kde je část spravována periodickým generováním zónových souborů (tohle dělá třeba FRED od CZ.NIC), část dynamickými updaty (tak se to používá třeba v RIPE NCC pro reverzní delegace).
-
Ondřej CaletkaZlatý podporovatel
Pokud se nepletu, tak PSQL je backend pro Freda, registrační systém. Z něj se každou půlhodinu vygeneruje obyčejný zónový soubor, ten se pomocí dalších nástrojů podepíše DNSSECem a vystaví na obyčejný master server, odkud si ho přeberou slave servery.
-
Chalupa (neregistrovaný)
Dobrý den,
zdědil jsem dns server kde je cca 250 domén, chtěl bych je podepsat, momentálně se používá debian Jessie, bind a webmin modul pro správu dns.
Je možné tyto domény podepisovat hromadně ideálně s jedním dnssec keysetem? Nenašel jsem na k tomu dost informací díky za nakopnutí -
Ondřej CaletkaZlatý podporovatel
Neznám webmin, ale pokud nedělá nějaké divoké věci, můžete použít postup uvedený v článku. Jen pozor, utility kolem BIND nejsou primárně připraveny na sdílení klíčů, proto tohle budete muset zařídit ručně – pro každou doménu zkopírovat soubory s klíči (veřejným i privátním) do nového souboru a v názvech i obsahu souboru nahradit jméno domény (nejlépe to nějak naskriptovat). Tím se zajistí, že všechny domény budou podepsány stejným klíčem a můžete k nim tedy přiřadit stejný keyset.
-
Zkusil jsem podepsat prvních pár domén a dostavila se menší nepříjemnost.
Na nameserveru (Debian Jessie) jsem dal podepsat doménu a mám aktivní views, tedy všechny zóny jsou uvedené ve dvou views (byť jsou třeba shodné), protože AFAIK to jinak nelze. Mám view internal a public. Většina domén se neliší a měl jsem prostě uveden v obou views shodný soubor.
Bind si po aktivaci zanadává do logu, protože v jednom pohledu zónu podepíše a pak je udiven, že se mu změnil serial když se to snaží udělat v druhém view.
Mar 30 12:17:35 ns named[21496]: malformed transaction: master/zona.cz.signed.jnl last serial 2015091609 != transaction first serial 2015091601 Mar 30 12:17:35 ns named[21496]: zone zona.cz/IN/public (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
Restart serveru to prozatím na chvíli vyřeší, ale to musím holt nějak rozdělit, 2 symlinky možná místo jednoho teď do /etc a napsat různá jména do pohledů :-/. Tak ono je to logické, ale nějak mě to netrklo. :-)
-
No jediné co mě napadá, by mohly být dynamické updaty DNS. To mám všude vypnuté. Používám zóny staticky, takže mě to nikdy zatím nevadilo.
Prostě jsem měl naincludovaný soubor se shodnými zonami do obou views a nenapadlo mě, že to jsou dvě instance, které se začnou lišit, když do toho začne bind hrabat...
-
Narazil jsem se $subj. První věc co mě zarazila, že naši bratři Slováci zřejmě ještě nemaj podepsanou národní doménu. Jak se tam domény registrují radši nebudu rozvádět :). Blbé ovšem je, když mě napadlo to zkusit dát do https://dlv.isc.org/, tak mi to na klíč nadávalo, že špatný formát. Pak jsem zabrousil do https://dlv.isc.org/help a tam je vysvětlení k hlášce Unsupported Algorithm
The key type of this DNSKEY is not currently supported by the DLV Registry. Currently supported types include RSASHA1, DSA, RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1.
nemluvě o tom, že se to už stejně chystaj vypnout...
Takže s sk doménami asi smolík zatím. -
Díky, skvělý návod.
Řešil někdo jak automaticky přidat CDNSKEY záznam? Bind 9.9.5 to asi neumí. Napadá někoho nějaká finta? Nebo budu muset zkompilovat 9.11 , ta zatím v balících debianu není. Nebo jak jinak rozumně předat registrátorovi klíč?
A pak také netuším proč mi validátory hlásí "Algorithm number 13 is unassigned", je to nepodporované šifrování, nebo to jen nepodporuje validátor?
-
Ondřej CaletkaZlatý podporovatel
Co se týče otázky CDNSKEY záznamu, tam by neměl problém vložit ho do zóny ručně. Je to obyčený záznam, není kolem žádná magie. Nová verze BINDu ho jen umí genetovat automaticky.
Které validátory hlásí problém s algorimem 13? DNSviz s tím rozhodně mít problém nebude. Nejspíš půjde o nějaké zastaralé, co se zasekly u RSA.
-
Můžete mi tedy prosím dát návod jak ten CDNSKEY vytvořit nebo dát příklad? Nebo je to prostě jen záznam pro kořen dané domény? Takže pro doménu mojedomena.cz bude záznam vypadat:
mojedomena.cz IN A IP.AD.RE.SA
mojedomena.cz IN CDNSKEY --a-radek-v-souboru-s-verejnym-klicem-- ?
a ostatní záznamy
www IN IP.AD.RE.SA
již bez CDNSKEY záznamuA to stačí přidat do nepodepsaného souboru zóny a dál si s tím bind 9.9.5 poradí?
A k těm validátorům, zkoušel jsem jak https://dnscheck.labs.nic.cz/ tak i http://dnscheck.pingdom.com
ale oba hlásí pro algoritmus chybu, nebo to špatně chápu-Algorithm number 13 is unassigned.
-DNSSEC signature RRSIG(skvelynet.cz/IN/DNSKEY/9418) fails to validate the RR set: key 1:Algoritm 13 has not yet been implemented -
Ondřej CaletkaZlatý podporovatel
Ano, vložte do zónového souboru obsah soubor s veřejným klíčem a jen zaměňte typ záznamu DNSKEY za CDNSKEY.
Tester DNSCheck je zastaralý a instalace od CZ.NIC má v hlavičcce velký červený text:
ECDSA algoritmy nejsou v tuto chvíli podporovány, chyby vztahující se na alg 13 a 14 jsou způsobeny na straně testovacího serveru.
Tester u pingdom je jen jinak naskinovaný DNSCheck, má tedy zřejmě stejné problémy. Použijte raději Zonemaster, což je následník DNSChecku: https://zonemaster.ripe.net https://zonemaster.iis.se https://www.zonemaster.fr
-
Tester - zonemaster - díky.
Co se týká CDNSKEY tak mám další problém, bind 9.9.5 (debian jessie) nezná typ záznamu CDNSKEY
Zkouším to obejít přes zápis
mojedomena.cz IN TYPE60 zápis a pak hodnoty 257 3 13 VEREJNYKLIC..
jenže nedaří se mi to zapsat ve tvaru pochopitelném bindem..
Dívám se i na rfc3597 a zkouším příjít na správný zápis, ale zatím nic ani nefunguje
mojedomena.cz CLASS1 TYPE60 ...Budu ještě pátrat jak to vnutit té mé verzi binda a nebo zkompiluji novější.
-
Tak už to mám, byl to boj...
Záznam
skvelynet.cz. IN CDNSKEY 257 3 13 0tV4xYibabQuOLi+705xOJiNaruWCbQmg6lof1MZshazZRRn8YuFP01I RjYJjumRmV7S/bdHwhUMIwY8AsKcbg==se zapíše
skvelynet.cz. IN TYPE60 \# 92 (01 01 03 0D 30 74 56 34 78 59 69 62 61 62 51 75 4f 4c 69 2b 37 30 35 78 4f 4a 69 4e 61 72 75 57 43 62 51 6d 67 36 6c 6f 66 31 4d 5a 73 68 61 7a 5a 52 52 6e 38 59 75 46 50 30 31 49 52 6a 59 4a 6a 75 6d 52 6d 56 37 53 2f 62 64 48 77 68 55 4d 49 77 59 38 41 73 4b 63 62 67 3d 3d )
Type60 = CDNSKEY
\# = bude následovat hexa vstup
92 = délka řetězce v bytech
0101 = je v hexa 257
03 = 3
0D = 13
a pak klíč bez mezer převedený do hexa (u mě má délku 88 znaků) -
Tak až teď to mám - zápis jak přinutit BIND 9.9.5 akceptovat záznam s CDNSKEY
(vznik ověřován na porovnání odpovědí zachycených tcpdumpem a analýzou wiresharkem)záznam
#dig TYPE48 skvelynet.cz
;; ANSWER SECTION:
skvelynet.cz. 3600 IN DNSKEY 257 3 13 0tV4xYibabQuOLi+705xOJiNaruWCbQmg6lof1MZshazZRRn8YuFP01I RjYJjumRmV7S/bdHwhUMIwY8AsKcbg==se přepíše do root.zone souboru bindu následovně - pro CDNSKEY
skvelynet.cz. IN TYPE60 \# 68 ( 01 01 03 0D d2 d5 78 c5 88 9b 69 b4 2e 38 b8 be ef 4e 71 38 98 8d 6a bb 96 09 b4 26 83 a9 68 7f 53 19 b2 16 b3 65 14 67 f1 8b 85 3f 4d 48 46 36 09 8e e9 91 99 5e d2 fd b7 47 c2 15 0c 23 06 3c 02 c2 9c 6e )
kde délka je fixní = 68 byte
0101 = 257
03 = 3
0D = 13
d2d5..... to je již 64B klíč.. Klíč je však uložen v BASE64, je nutné převést do hexa http://www.asciitohex.com/
-- v podstatě stačí vzít ten řetězec 0tV4....== a copy+pastenásledně stačí reloadovat bind..
a dig vrátí pro dotaz na type60
#dig TYPE60 skvelynet.cz
;; ANSWER SECTION:
skvelynet.cz. 3600 IN TYPE60 \# 68 0101030DD2D578C5889B69B42E38B8BEEF4E7138988D6ABB9609B426 83A9687F5319B216B3651467F18B853F4D484636098EE991995ED2FD B747C2150C23063C02C29C6Ejestli jsem vše udělal dobře, tak stačí teď počkat 7 dní a díky skenování ze strany cz.nic by mělo dojít k zanesení klíče do nadřazeného dns.. viz: https://www.root.cz/clanky/druha-faze-automatizovane-spravy-dnssec-klicu/
Dám pak vědět..
-
Skript pro generování CDNSKEY záznamů do bindu který "CDNSKEY" ještě nezná.
Skript je tupej a předpokládá inteligentní vstup - vygenerovanou veřejnou část klíeč dle postupu v tomto článku. Řádek se pak přidá do souboru se záznamy zóny.
====
#!/bin/bash
#
# Vygeneruje CDNSKEY ZAZNAM pro bind 9.9.5 ktery jej nezna
# Vstup je soubor s verejnym klicem - algorithm number 13/(ECDSA Curve P-256 with SHA-256)
#if [ -z $1 ] ; then
echo "Pouziti: $0 <soubor-s-verejnym-klicem>"
exit 1;
fidomain=`grep DNSKEY $1 | cut -f 1 -d" "`
grep "DNSKEY 257 3 13" $1 | cut -f 7- -d" " | while read radek ; do
echo -n "$domain IN TYPE60 \# 68 ( 01 01 03 0D "
echo $radek | base64 -d -i | hexdump -v -e '/1 "%02x " '
echo ")"
done -
Zdravím,
využil jsem vašich poznatků jak přesvědčit bind 9.9.5, který je v debianu a snažím se to replikovat na redhat, který má dokonce bind 9.9.4.
Co tedy všechno musí být v zónovém souboru za záznamy když využívám ECDSA šifru a inline-signing?Mám tam DNSKEY, z něj udělanej "CDNSKEY" přes TYPE60 a HEXa zápis podle vás, pak taky DS, ale ten se mi z venku nepřekládá jako vám na skvelynet.cz, je to tím že ještě nemám řetězec důvěry? Ten CDNSKEY jsem tam zadal teprve včera cca v 18:00, tak nevím jestli mi přijde email o nálezu nebo mám něco špatně :D Za jak dlouho vám přišel?
Zajímavé je taky co se děje s Serial číslem, v zónovém souboru mám např.:2018030113, ale log napíše:
named[10032]: zone dns-sec.cz/IN (signed): sending notifies (serial 2018030116)
named[10032]: zone dns-sec.cz/IN (signed): reconfiguring zone keys
Musím tedy hlídat až do jakého čísla se povýšil podepsaný Serial abych neměl nižší číslo než aktuální?
zone dns-sec.cz/IN (signed): reconfiguring zone keys
Po změně serialu a rndc reload log píše toto:
named[10032]: zone dns-sec.cz/IN (unsigned): loaded serial 2018030201
named[10032]: zone dns-sec.cz/IN (signed): next key event: 02-Mar-2018 10:12:25.089
named[10032]: zone dns-sec.cz/IN (signed): serial 2018030201 (unsigned 2018030201)
Asi nechápu co to všechno znamená.
První řádek - že má nepodepsanou zónu?
Druhý řádek - že ji podepíše až v 10:12?
Třetí řádek - zóna s tímto serialem podepsaná a potom v závorce že je nepodepsaná?
Moc děkuji za všechny poznatky a odpovědi na možná stupidní otázky... -
Lubos (neregistrovaný)
Pokud uz klic existuje, tak muzeme sync jednoduse pridat bez nutnosti vymeny klice pomoci
dnssec-settime -P sync now(neplest jen s-P now, coz je jen publikace zaznamu, nikoliv publikace sync CDNSKEY!):napr.:
dnssec-settime -P sync now Kexample.com.+ALG+NUMBER.keyv adresari s klici
