Miért lehet probléma egyes helyeken a DNS-sel május 5-én és hogyan nem

Címkék

Az elmúlt napokban több cikk is megjelent arról, hogy május 5-én egyes vállalatoknál, szervezeteknél, fel nem készült szolgáltatóknál probléma lehet a DNS-sel. Az ok: az illetékes szerv befejezi a Domain Name System Security Extensions (DNSSEC) bevezetésének első fázisát a root DNS szervereken. A DNSSEC-től nagyobb biztonságot várnak a szakemberek, de ha a bevezetését nem körültekintően követik le, akkor akár nem várt mellékhatásokkal is számolni kell.

A standard DNS kérésre általában egy darab, 512 byte-nál kisebb méretű csomag érkezik. Május 5-től, a DNSSEC miatt azonban a DNS válasz jóval nagyobb, akár 2 kilobyte méretű és fragmentált is lehet.

Vannak olyan régebbi hálózati eszközök, amelyek gyárilag blokkolják az ilyen csomagokat, feltételezve, hogy azok valamilyen anomália eredményeképpen érkeztek. További okok itt.

Bruce Tonkin, az ICANN igazgatóságának tagja fél attól, hogy noha a DNSSEC bevezetésének témája régóta napirenden van, vannak olyan hálózati adminisztrátorok, akik még mindig nem ellenőrizték le a hálózati eszközeiket annak érdekében, hogy meggyőződjenek, azok képesek megfelelően kezelni a közelgő változtatást.

Feltehetően az ISP-k felkészülve várják a váltást, így az otthoni internet felhasználók és a stub (a szolgáltató DNS szervereit használó) resolver-t használó szervezetek, vállalatok nem ütköznek majd problémába.

Problémájuk azoknak lehet, akik nem használnak forwarder-(eke)t, hanem közvetlenül a root DNS szervereket kérdezik le és régi/rosszul konfigurált eszközzel, tűzfallal rendelkeznek.

A Domain Name System Operations Analysis and Research Center (DNS-OARC) épített egy DNS válaszméret tesztszervert, amellyel a hálózati adminisztrátorok le tudják ellenőrizni az eszközeiket/beállításaikat.

Részletek:
Warning: Why your Internet might fail on May 5
Will DNSSEC kill your internet?
DNSSec — and Why the Internet Probably Won’t Break Today

Hozzászólások

# dig +short rs.dns-oarc.net txt

rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"Tested at 2010-05-03 07:14:16 UTC"
"193.224.177.1 DNS reply size limit is at least 3843"
"193.224.177.1 sent EDNS buffer size 4096"

ez most akkor jo vagy nem? azt irjak min. 4000 kene legyen, de a hibas eseteknel meg 1500 alattiakrol van szo.

A'rpi

egy vanilla dnscache eredmenye:

dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"1.2.3.4 DNS reply size limit is at least 490"
"1.2.3.4 lacks EDNS, defaults to 512"
"Tested at 2010-05-03 07:56:28 UTC"

mondjuk nem is tamogatja a dnssec-et...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

az 1. iras szerint: all the DNS root servers will respond with signed DNSSEC answers.

Nem talaltam (eddig) hivatkozast arra, hogy kepesek-e a root dns-ek visszavaltani 'compatibility mode'-ba, ha a rezolver eleve nem is tamogatja a dnssec-et. A dnssec a bind 'valasza' pl. a dns cache poisoning tamadasra (http://www.dnssec.net/). Az otlet biztos jo, csak kerdes, mi van akkor, ha egy masik termek mashogy oldja meg ezeket a biztonsagi problemakat, es nem tamogatja a dnssec-et.

Addig is vegzek 1-2 tesztet....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

"A dnssec a bind 'valasza' pl. a dns cache poisoning tamadasra"

De inkabb az IETF-e.

"Az otlet biztos jo, csak kerdes, mi van akkor, ha egy masik termek mashogy oldja meg ezeket a biztonsagi problemakat, es nem tamogatja a dnssec-et"

Csodalkozas, ugyanis mas megoldast meg ennyire sem tamogat a jelenlegi dns infrastruktura.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

De inkabb az IETF-e.

Amennyire en tudom, a dnssec-et az isc (=bind) nyomta. Az ietf pecsetje nem valtoztat ezen...

Csodalkozas,

Ha 'a jelenlegi dns infrastruktura' != 'bind', akkor pl. http://cr.yp.to/djbdns/forgery.html
ill. (nem neztem meg meg jobban): http://dnscurve.org/index.html

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

rovid valasz: "The root servers will continue to send a reply [to queries by dnscache]"

hosszabb valasz:

Q: Gentlemen, I would like to know whether dns servers running dnscache will be
functional as of 5th, May when all root nameservers will respond with dnssec.
Thank you!

A: dnscache is not written by ISC, so I cannot answer that question for you.
You can find information on dnscache at http://cr.yp.to/djbdns/dnscache.html

Q: thanks for the answer, however it's not about dnscache, but the root dns
servers. So I would like to know what will happen if the root nameserver
is asked by a resolver which does not support dnssec.
In other words: will the root nameservers provide a valid answer or reply
with an error or simply discard the request?

A: The root servers will continue to send a reply.
You can test this yourself, by comparing the output of these two commands:

dig . ns @f.root-servers.net
dig +dnssec . ns @f.root-servers.net

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Tesóméknál teszteltem (Pantel vagy hogy hijak most) ott ugyan ez.

Nálunk(T-Onlány):
rst.x996.rs.dns-oarc.net.
rst.x1241.x996.rs.dns-oarc.net.
rst.x1294.x1241.x996.rs.dns-oarc.net.
"Tested at 2010-05-03 08:04:02 UTC"
"2001:4c48:1::1:3 sent EDNS buffer size 4096"
"2001:4c48:1::1:3 DNS reply size limit is at least 1294"

Bár nekünk van egy köcsög PIX szerintem az lehet a ludas.

dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"213.46.246.53 DNS reply size limit is at least 490"
"213.46.246.53 lacks EDNS, defaults to 512"
"Tested at 2010-05-03 07:43:16 UTC"

Ez UPC-s hálózatban van, ha jól értelmezem akkor ez szívás, két napja van UPC-nek hogy átálljon....

DNSSEC-es válasz egyelőre csak a root szerverekről érkezik majd. Ha te nem a root szervert magát kérdezed le, hanem a szolgáltatód DNS szerverét használod, akkor nem fog érkezni hozzád 512 byte-nál nagyobb csomag. Tehát, hogy közted és a szolgáltatód DNS szervere közt mi van, jelenleg nem érdekes.

--
trey @ gépház