DNSSEC .hu?

Linux-haladó

Használ valaki DNSSSEC-et?
Egyik (alig használt) domainemen tesztre beállítottam, működni látszik. Igaz, hogy a .hu nem ad DS-t, emiatt ugye varningolnak az online teszterek, de az egy dolog.
Használ valaki ilyesmit élesben? Mik a tapasztalatok?

  • 3858 megtekintés

( n.balazs v | 2015. 08. 29., szo – 11:40 )

Én terveztem bevezetni egy domainnél élesben. Ott azt mondta a szolgáltató, hogy várjak vele, mert állítólag most szeptemberben lezárul a tesztidőszak és élesben fog működni a .hu zónában. A szolgáltató leveléből látható volt, hogy nem szerezték meg még a DNSSEC-kel kapcsolatos szakmai ismereteket, tapasztalatokat. Így egyelőre a bevezetése elmaradt, de mihamarabb szeretném megvalósítani.

Szerintem ne várj a szolgáltatódra, ha van két független tartományba eső fix IP-d, ami legalább 99%-ban elérhető, akkor csinálj saját DNS-t (vagy egy IP-nél legyen a Tiéd a master, szolgáltató meg legyen slave - bár a slave oldalon is be kell ehhez kapcsolni 1-2 opciót, de ha elárulják, hogy mit használnak, még Te is kiguglizhatod nekik).
Ha már Nálad a zóna master konfigja, és a slave szépen követi, akkor már nem szolgáltatófüggő, hogy bevezesd.
A DNS-t amúgy ahhoz viszed át, akihez akarod, és van választék (egyik rosszabb, mint a másik, de van) :)
--
PtY - www.onlinedemo.hu, www.westeros.hu

Én ezekről nem tudok (a teszt időszakról meg főként nem). Az ISZT tartott 2015. május 27-én egy DNSSEC tanfolyamot a regisztrátoroknak (bár nekem sajnos nem sikerült résztvennem rajta), így DNSSEC irányból lemaradásban vagyok, de elvileg a rendszer már él és működik, a regcheck-et is módosították már ennek megfelelően

// Happy debugging, suckers
#define true (rand() > 10)

( PtY | 2015. 08. 29., szo – 12:25 )

Ok, akkor pontosítok.
csardij linkje megvolt. Csak épp hajnalban nem sikerült kifejeznem magam rendesen :)

Tehát: vannak dns zónáim, spf-fel, dkim-mel, dmarc-kal, ezek mögé tervezem a dnssec bevezetését.
A kérdés főleg az, hogy amíg nem kérem a regsupportnál, hogy a zóná(i)mat tegyék a dnssec alá, és/vagy amíg ez az áthelyezés nem történik meg, addig származik-e bármilyen hátrányom abból, hogy az adott zónán be van engedélyezve/konfigurálva a dnssec, csak épp a .hu nincs mögötte?

Illetve fordítva, ha még lokálisan nincs beállítva, de már a .hu alatt elvileg működhetne?

Tehát a lényeg az, hogy érdemes nekiállni a bevezetésnek, úgy, hogy felkonfigurálok mindent, hogy pl. mint a regcheck le tudják ellenőrizni a beállításokat, és utána helyezik át, vagy előbb kell áthelyeztetni, és utána kell beállítani?

És a legfőbb kérdés az, hogy amíg a zónán be van állítva, a .hu-n meg nincs (vagy fordítva), abból származik-e hátránya bárkinek?
--
PtY - www.onlinedemo.hu, www.westeros.hu

Helló,

Ez, hogy gondot okozhat e, képlékeny. Elvileg igen, mert ha van DNSSEC rajta, de nem valid, akkor ha ezt ellenőrzi valami, nem fogja elfogadni. Azonban (sajnos) ez az egész DNSSEC annyira nincs sehol használva, hogy ihaj, kb úgy van (sőt, talán még annyira se) mint az IPv6.

MikroVPS

Szerintem egyre több helyen használják, pont emiatt szeretnék "váltani" :)
Ha mindenhez úgy állunk, hogy kevesen használják, és ezért mi sem, akkor nem is fogják - sajnos, az IT-ban a security related dolgokkal pont ezt művelik a legtöbben: sz@rnak rá.
Pedig pont az IT felelőssége az, hogy erőltesse ezeket a dolgokat az ügyfelei irányába is.
Ez persze magánvélemény, lehet vele vitatkozni, sajnos ezt látom mindenhol. Letojják az SSL-t, a jelszópolicy-t, a vpn-t, és még sorolhatnám.
Ott van pl. a HTTPS. Annak ellenére, hogy egyre többen használják, olyan is... Az oldalak egy része önaláírt (igaz, ebből egyre kevesebb van), egy része a tanúsítványoknak nem tartalmaz alt-name-et, így csak a www.valami-re működik, amúgy tanúsítványhibát ad, a szolgáltatók egy része nem képes SNI-t kezelni (és ebben nem a meglévő eszközpart és szoftverek okozzák a korlátot), ahol meg látszólag minden rendben van, ott az adott oldal egy Qualys SSL teszten olyan gyatra eredményt produkál, hogy akkor már jobb lenne, ha plaintext - és ez alól még egy-két hazai bank oldala sem kivétel (lásd: OTP - és mellécseszheti a Symanteces EV certjét, attól még extrafos)
--
PtY - www.onlinedemo.hu, www.westeros.hu

( f0xhu v | 2015. 08. 30., v – 20:43 )

még nem használunk, de a HUNGUARD miatt muszáj lesz. Most dolgozunk rajta. A hálózatosok és szerintünk is elég nagy szopóág lesz... ha érdekel a gyakorlati tapasztalat, akkor majd megírom.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( dotroll | 2015. 10. 16., p – 13:13 )

A .hu alatt most már élesben is használhatod. A domain.hu regcheken le tudod ellenőrizni, hogy helyesek-e a beállításaid. Ha lefut a DNSSEC-es regcheck a domainedre és névszerveredre akkor szólj a regisztrátorodnak, hogy frissítse az ISZTnél a beállításaid.

( LiRul | 2017. 01. 03., k – 13:58 )

Amúgy mi az oka annak, hogy gyakorlatilag világszinten a nagyok sem használják? Random megnéztem pár nagynevű domaint, mint pl. google.com, amazon.com, ebay.com, yahoo.com, facebook.com, wikipedia.org, egyik sem használja. Kereskedelmi cégek közül egyetlen egyet találtam, a paypal.com-nak van RRSIG-je. FOSS világból a debian.org-nak van, de már az ubuntu.com-nak nincs. Magyar domainek közül egyet sem találtam (Alexa toplistát nézegettem), de még az olyan nevek mint az iszt.hu, domain.hu, nic.hu, otpbank.hu sem vezették be.

Na pont ez a „több haszonnal nem jár” dolog érdekelne, mert azért azt gondolom, hogy tudás és erőforrás is minden fent felsorolt domain mögött álló szervezetben meg lenne. Az Akamai átélt elég jelentős DDoS támadást, ahol is a támadó a olyan lekérdezéseket küldött, amire a válasz az áldozat felé ment és mivel a DNSSEC response többszöröse méretben egy sima DNS válaszhoz képest, el is érték vele a céljukat. De valóban ez van a háttérben mint terjedési gát?!

( Darkfish | 2017. 01. 03., k – 14:39 )

Bocsánat, de lehet hogy elképesztő lámaságot kérdezek, de ennek elvileg az a célja, hogy ha valaki a DNS-t eltéríti egy másik szerverre akkor az kiderüljön. Na most ha én rá tudom venni az áldozatot, hogy az én DNS szerverőmről olvassa be az adatokat, akkor én ott simán nem állítom be a DNSsec-t a meghamisítandó domain-ra és kész...

Ha meg ilyen könnyű átverni akkor meg mi az értelme?

Vagy miben tévedek?

Ez OK, de pont a nameserver-t fogom hamisítani... magyarán abban nem valós adat lesz hanem amit én beírok.
Az, hogy a domain eredetileg DNSSEC-es meg nem fog kiderülni soha.
Még ha a weboldal cert-jébe lenne beleírva az se sokat javítana, mert az elterelt forgalomban már olyan cert-et adok vissza amilyet akarok. (Ez utóbbi nyilván sarkítás)

Szóval ez így elsőre teljesen értelmetlennek látszik.

Ezért kell a szülő zónával aláíratni a gyerek zónákat.

A root zóna publikus kulcsai publikusak (jé :) ), nagyon ritkán változnak (és akkor is hosszú idő alatt) és a DNS klienseknek tudniuk kell (ti. az a trust anchor). 


bash-4.2$ cat /etc/trusted-key.key 
. 3600 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

Ha a kliens, amelyiket te át akarsz verni, használ DNSSec-et, akkor ettől a Trust Anchortól nem tudja "lefelé" végig hitelesíteni a kéréseket (nem tudsz hamisítani a root zóna kulcsával aláírt olyan választ, hogy a hu. zóna ne támogatná a DNSSec-et, hasonlóan annak a kulcsával aláírtat, hogy a pelda.hu. ne támogatná...) - lásd 

dig +sigchage iana.org

. Na persze pl. a Windows-os DNS kliens ilyennel nem nagyon foglalkozik :(

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A DNSSEC-es kliensek tehát alapból elvárják a root zóna támogatását? Akkor is ha az én DNS szerveremhez kapcsolódnak elsőnek?

Magyarán ha jól értem, a biztonságot elvileg az adná, hogy a root zóna TTLje rettentő magas, és ha én elsőnek nem egy hamisított DNShez kapcsolódom, akkor a root zóna változásból kiderül a hiba?

És ha jól értem, ennek előbb minden kliens gépen el kéne terjednie, hogy értelme legyen? És kb ott is beépített root zónákkal?

A DNSSEC-es kliensek tehát alapból elvárják a root zóna támogatását?

A kliensnek mindenféle kell _valami_ trust anchor. Ez lehet az, hogy a root zóna kulcsa a fenti módon ott van telepítéskor a gépen, vagy az, hogy megbízik abban a szerverben, aminek átadja a kérést.

A fenti példádra (SSL) visszatérve, ott a trust anchor az összes megbízhatónak jelölt CA publikus certje. Itt a különbség annyi, hogy mivel a DNS amúgy is faszerkezetű, egyszerűen megvalósítható úgy, hogy az egyetlen gyökérhez tartozik a TA, és a lentebbi szinteket mindig a felsőbb szintek hitelesítik.

Magyarán ha jól értem, a biztonságot elvileg az adná, hogy a root zóna TTLje rettentő magas, és ha én elsőnek nem egy hamisított DNShez kapcsolódom, akkor a root zóna változásból kiderül a hiba?

Nem, a biztonságot az adja, hogy a trust anchor biztonságosan elér a gépedre. Jöjjön az egy gyárilag írt OS telepítő lemezről, egy pl. GPG-vel/certtel/akármivel aláírt telepítőről/csomagról (pl. a dns-utils csomag a kedvenc disztródból), vagy onnan, hogy letöltöd innen: https://data.iana.org/root-anchors/root-anchors.xml

Szintén az SSL-es PKI-hez hasonlítva: a megbízható CA certjét legelső alkalommal hogy juttatod el a gépre? A Windows eléggé PKI centrikus, úgyhogy azzal példázva: A Windows telepítő CD-n alapból ott van jó néhány CA certje. Pl. a youtube-ot aláíró cert root-ja a GeoTrust 2002 májusi, úgyhogy ha felteszel egy Win2k-t, akkor alapból figyelmeztetni fog, hogy ismeretlen az aláíró (2000-ben nem lehetett ott a 2002-ben létrehozott cert). Aztán "heti egyszer" (ill. most már 24 óránként) a Windows körülnéz, hogy vannak-e a Windows Update-en/WSUS-on frissített certek és azokat is letölti, innentől be fog jönni a youtube - viszont ott a csomag az MS aláírásával fog rendelkezni, az amihez tartozó tanúsítvány rootja ott volt a telepítő CD-n.

És persze van olyan, hogy megszakad ez a mechanizmus. Tippre ha felraksz egy elég régi disztrót, ami már nem találja meg a frissítéseit ott, ahol keresnéd, elég sok oldal dobná az ismeretlen kibocsátó hibákat.

És ha jól értem, ennek előbb minden kliens gépen el kéne terjednie, hogy értelme legyen?

Valami trust anchornak lennie kell; ha nincs TA, akkor az lehet, mint a self signed certeknél/ssh host kulcsoknál: amikor a kliens először találkozik velük, megkérdezi a usert, hogy "te, ez így oké"? És ezzel a művelettel létrejön egy megbízhatósági viszony.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Van két rekord típus (NSEC és NSEC3), amik arra valók, hogy aláírtan le tudja tagadni egy név létezését a legközelebbi szülő. Ugye azt a kliens tudja, hogy a root zóna alá van írva, így _elvárja_, hogy ha megkérdezi valamelyik TLD DS rekordját, akkor azt kapja vissza, vagy egy _aláírt_ "nincs ilyen" választ.
Lásd: 

dig +dnssec -t DS ai.

(az ai. zóna egyelőre nem DNSSec-képes) vs. egy 

dig +dnssec -t DS hu.

.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)