Rozszerzenia zabezpieczeń systemu nazw domen — Domain Name System Security Extensions

Internetowe
protokoły bezpieczeństwa
Zarządzanie kluczami
Warstwa aplikacji
System nazw domen
Warstwa internetowa

DNSSEC ( DNSSEC ) to zestaw specyfikacji przedłużających przez Internet Engineering Task Force (IETF) do zabezpieczania danych wymienianych w Domain Name System (DNS) w Internet Protocol (IP) sieci. Protokół zapewnia uwierzytelnianie kryptograficzne danych, uwierzytelnioną odmowę istnienia i integralność danych, ale nie dostępność lub poufność.

Przegląd

Pierwotny projekt systemu nazw domen nie zawierał żadnych funkcji bezpieczeństwa. Został pomyślany tylko jako skalowalny system rozproszony. Rozszerzenia DNSSEC (Domain Name System Security Extensions) próbują zwiększyć bezpieczeństwo, zachowując przy tym wsteczną kompatybilność . Request for Comments 3833 dokumentuje niektóre ze znanych zagrożeń dla DNS i ich rozwiązania w DNSSEC.

DNSSEC został zaprojektowany w celu ochrony aplikacji korzystających z DNS przed akceptacją sfałszowanych lub zmanipulowanych danych DNS, takich jak te utworzone przez zatruwanie pamięci podręcznej DNS . Wszystkie odpowiedzi ze stref chronionych DNSSEC są podpisywane cyfrowo . Sprawdzając podpis cyfrowy, przelicznik DNS jest w stanie sprawdzić, czy informacje są identyczne (tj. niezmodyfikowane i kompletne) z informacjami opublikowanymi przez właściciela strefy i podanymi na autorytatywnym serwerze DNS. Podczas gdy ochrona adresów IP jest bezpośrednim problemem dla wielu użytkowników, DNSSEC może chronić wszelkie dane publikowane w DNS, w tym rekordy tekstowe (TXT) i rekordy wymiany poczty (MX) oraz mogą być używane do ładowania innych systemów bezpieczeństwa, które publikują odniesienia do kryptografii certyfikaty przechowywane w systemie DNS, takie jak Certificate Records ( CERT records , RFC 4398), odciski palców SSH ( SSHFP , RFC 4255), publiczne klucze IPSec (IPSECKEY, RFC 4025) i TLS Trust Anchors (TLSA, RFC 6698).

DNSSEC nie zapewnia poufności danych; w szczególności wszystkie odpowiedzi DNSSEC są uwierzytelniane, ale nie są szyfrowane. DNSSEC nie chroni bezpośrednio przed atakami DoS , choć pośrednio zapewnia pewne korzyści (ponieważ sprawdzanie sygnatur umożliwia korzystanie z potencjalnie niewiarygodnych stron).

Inne standardy (nie DNSSEC) służą do zabezpieczania danych masowych (takich jak transfer strefy DNS ) przesyłanych między serwerami DNS. Jak udokumentowano w dokumencie IETF RFC 4367, niektórzy użytkownicy i programiści przyjmują fałszywe założenia dotyczące nazw DNS, na przykład zakładają, że nazwa zwyczajowa firmy plus „.com” jest zawsze nazwą domeny. DNSSEC nie chroni przed fałszywymi założeniami; może tylko potwierdzić, że dane rzeczywiście pochodzą od właściciela domeny lub są niedostępne.

Specyfikacje DNSSEC (zwane DNSSEC-bis ) bardzo szczegółowo opisują obecny protokół DNSSEC. Zobacz RFC 4033, RFC 4034 i RFC 4035. Wraz z publikacją tych nowych specyfikacji RFC (marzec 2005), wcześniejszy RFC, RFC 2535, stał się przestarzały.

Powszechnie uważa się, że zabezpieczenie DNS ma kluczowe znaczenie dla zabezpieczenia Internetu jako całości, ale wdrożenie DNSSEC było szczególnie utrudnione (stan na 22 stycznia 2010 r.) przez kilka trudności:

  • Konieczność zaprojektowania standardu zgodnego z poprzednimi wersjami, który można skalować do rozmiaru Internetu
  • Zapobieganie „wyliczaniu stref” w razie potrzeby
  • Wdrażanie wdrożeń DNSSEC na szerokiej gamie serwerów DNS i resolwerów (klientów)
  • Spór wśród realizatorów co do tego, kto powinien posiadać klucze główne domeny najwyższego poziomu
  • Przezwyciężenie postrzeganej złożoności wdrażania DNSSEC i DNSSEC

Operacja

DNSSEC działa poprzez cyfrowe podpisywanie rekordów do wyszukiwania DNS przy użyciu kryptografii klucza publicznego . Prawidłowy rekord DNSKEY jest uwierzytelniany poprzez łańcuch zaufania , rozpoczynający się od zestawu zweryfikowanych kluczy publicznych dla strefy głównej DNS, która jest zaufaną stroną trzecią . Właściciele domen generują własne klucze i przesyłają je za pomocą panelu sterowania DNS u rejestratora nazw domen, który z kolei przesyła klucze przez secDNS do operatora strefy (np. Verisign dla .com), który podpisuje je i publikuje w DNS.

Rekordy zasobów

DNS jest zaimplementowany przy użyciu kilku rekordów zasobów. Aby wdrożyć DNSSEC, stworzono lub dostosowano kilka nowych typów rekordów DNS do użycia z DNSSEC:

RRSIG (podpis rekordu zasobu)
Zawiera podpis DNSSEC dla zestawu rekordów. Resolwery DNS weryfikują podpis za pomocą klucza publicznego przechowywanego w rekordzie DNSKEY.
Klucz DNS
Zawiera klucz publiczny używany przez program rozpoznawania nazw DNS do weryfikowania podpisów DNSSEC w rekordach RRSIG.
DS (podpisujący delegację)
Zawiera nazwę strefy delegowanej. Odwołuje się do rekordu DNSKEY w strefie delegowanej podrzędnie. Rekord DS jest umieszczany w strefie nadrzędnej wraz z delegującymi rekordami NS.
NSEC (kolejny bezpieczny rekord)
Zawiera łącze do nazwy następnego rekordu w strefie i zawiera listę typów rekordów, które istnieją dla nazwy rekordu. Programy rozpoznawania nazw DNS używają rekordów NSEC do weryfikacji nieistnienia nazwy i typu rekordu w ramach walidacji DNSSEC.
NSEC3 (następna wersja bezpiecznego rekordu 3)
Zawiera łącza do nazwy następnego rekordu w strefie (w kolejności sortowania nazw zaszyfrowanych) i zawiera listę typów rekordów, które istnieją dla nazwy objętej wartością skrótu w pierwszej etykiecie nazwy własnej rekordu NSEC3. Rekordy te mogą być używane przez programy rozpoznawania nazw do weryfikacji nieistnienia nazwy i typu rekordu w ramach walidacji DNSSEC. Rekordy NSEC3 są podobne do rekordów NSEC, ale NSEC3 używa kryptograficznie zaszyfrowanych nazw rekordów, aby uniknąć wyliczenia nazw rekordów w strefie.
NSEC3PARAM (kolejne parametry bezpiecznego zapisu w wersji 3)
Autorytatywne serwery DNS używają tego rekordu do obliczania i określania, które rekordy NSEC3 należy uwzględnić w odpowiedziach na żądania DNSSEC dotyczące nieistniejących nazw/typów.

Gdy używana jest usługa DNSSEC, każda odpowiedź na wyszukiwanie DNS zawiera rekord DNS RRSIG oprócz żądanego typu rekordu. Rekord RRSIG jest podpisem cyfrowym zestawu rekordów zasobów DNS odpowiedzi . Podpis cyfrowy jest weryfikowany przez zlokalizowanie prawidłowego klucza publicznego w rekordzie DNSKEY. Rekordy NSEC i NSEC3 służą do dostarczania kryptograficznych dowodów na nieistnienie jakiegokolwiek rekordu zasobów (RR). Rekord DS jest używany do uwierzytelniania kluczy DNSKEY w procedurze wyszukiwania przy użyciu łańcucha zaufania. Rekordy NSEC i NSEC3 służą do zapewnienia silnej odporności na podszywanie się.

Algorytmy

DNSSEC został zaprojektowany tak, aby był rozszerzalny, tak aby w miarę odkrywania ataków na istniejące algorytmy można było wprowadzać nowe w sposób zgodny z poprzednimi wersjami . Poniższa tabela określa, według stanu na kwiecień 2013 r., najczęściej używane algorytmy bezpieczeństwa:

Pole algorytmu Algorytm Źródło Podpisywanie DNSSEC Walidacja DNSSEC
1 RPA / MD5 Nie wolno wdrażać Nie wolno wdrażać
3 DSA / SHA-1 Nie wolno wdrażać Nie wolno wdrażać
5 RSA/SHA-1 RFC 3110 Niepolecane Wymagany
6 DSA-NSEC3-SHA1 Nie wolno wdrażać Nie wolno wdrażać
7 RASHA1-NSEC3-SHA1 RFC 5155 Niepolecane Wymagany
8 RPA/ SHA-256 RFC 5702 Wymagany Wymagany
10 RSA/ SHA-512 Niepolecane Wymagany
12 GOST R 34.10-2001 RFC 5933 Nie wolno wdrażać Opcjonalny
13 ECDSA / SHA-256 RFC 6605 Wymagany Wymagany
14 ECDSA/ SHA-384 Opcjonalny Zalecana
15 Ed25519 RFC 8080 Zalecana Zalecana
16 Ed448 Opcjonalny Zalecana
Pole skrótu strawić Źródło Stan wdrożenia
1 SHA-1 RFC 3658 Wymagany
2 SHA-256 RFC 4509 Wymagany
3 GOST R 34.10-2001 RFC 5933 Opcjonalny
4 SHA-384 RFC 6605 Opcjonalny

Procedura wyszukiwania

Na podstawie wyników wyszukiwania DNS, rozpoznający zabezpieczenia DNS może określić, czy autorytatywny serwer nazw dla odpytywanej domeny obsługuje DNSSEC, czy otrzymana odpowiedź jest bezpieczna i czy wystąpił jakiś błąd. Procedura wyszukiwania jest różna dla rekurencyjnych serwerów nazw , takich jak te od wielu dostawców usług internetowych , a przeliczniki króćcami takie jak te zawarte domyślnie w systemach operacyjnych głównego nurtu. Microsoft Windows korzysta z programu rozpoznawania skrótów, a zwłaszcza Windows Server 2008 R2 i Windows 7 używa niewalidującego, ale obsługującego rozszerzenia DNSSEC programu rozpoznawania nazw.

Rekurencyjne serwery nazw

Korzystając z modelu łańcucha zaufania , rekord osoby podpisującej delegację (DS) w domenie nadrzędnej ( strefie DNS ) może służyć do weryfikacji rekordu DNSKEY w subdomenie , który może następnie zawierać inne rekordy DS w celu weryfikacji dalszych subdomen. Załóżmy, że rekursywny resolver, taki jak serwer nazw usługodawcy internetowego, chce uzyskać adresy IP ( rekord A i/lub rekordy AAAA ) domeny „ www.przykład.com ”.

  1. Proces rozpoczyna się, gdy program rozpoznawania nazw uwzględniający zabezpieczenia ustawia bit flagi „DO” („DNSSEC OK”) w zapytaniu DNS. Ponieważ bit DO znajduje się w rozszerzonych bitach flagi zdefiniowanych przez mechanizmy rozszerzeń dla DNS (EDNS) , wszystkie transakcje DNSSEC muszą obsługiwać EDNS. Obsługa EDNS jest również potrzebna, aby umożliwić znacznie większe rozmiary pakietów, których wymagają transakcje DNSSEC.
  2. Kiedy przelicznik otrzyma odpowiedź w normalnym procesie wyszukiwania DNS, sprawdza, czy odpowiedź jest prawidłowa. Najlepiej byłoby, gdyby program rozpoznający zabezpieczenia zaczął od weryfikacji rekordów DS i DNSKEY w katalogu głównym DNS . Następnie użyje rekordów DS dla domeny najwyższego poziomu „com” znalezionej w katalogu głównym, aby zweryfikować rekordy DNSKEY w strefie „com”. Stamtąd sprawdzi, czy istnieje rekord DS dla poddomeny „example.com” w strefie „com”, a jeśli tak, użyje rekordu DS do zweryfikowania rekordu DNSKEY znalezionego w „example. com”. Na koniec zweryfikuje rekord RRSIG znaleziony w odpowiedzi dla rekordów A dla „www.example.com”.

Istnieje kilka wyjątków od powyższego przykładu.

Po pierwsze, jeśli adres „example.com” nie obsługuje DNSSEC, w odpowiedzi nie będzie rekordu RRSIG ani rekordu DS dla „example.com” w strefie „com”. Jeśli istnieje rekord DS dla „example.com”, ale w odpowiedzi nie ma rekordu RRSIG, coś jest nie tak i być może trwa atak pośrednika, który usuwa informacje DNSSEC i modyfikuje rekordy A. Lub może to być uszkodzony, nieświadomy bezpieczeństwa serwer nazw po drodze, który usunął bit flagi DO z zapytania lub rekord RRSIG z odpowiedzi. Lub może to być błąd konfiguracji.

Następnie może się zdarzyć, że nie ma nazwy domeny o nazwie „www.example.com”, w którym to przypadku zamiast zwracania rekordu RRSIG w odpowiedzi, pojawi się albo rekord NSEC, albo rekord NSEC3. Są to „następne bezpieczne” rekordy, które pozwalają przelicznikowi udowodnić, że nazwa domeny nie istnieje. Rekordy NSEC/NSEC3 posiadają rekordy RRSIG, które można zweryfikować jak powyżej.

Wreszcie może się zdarzyć, że strefa „example.com” implementuje DNSSEC, ale strefa „com” lub strefa główna nie, tworząc „wyspę bezpieczeństwa”, która musi zostać zweryfikowana w inny sposób. Z dniem 15 lipca 2010 r. wdrożenie DNSSEC do roota zostało zakończone. Domena .com została podpisana przy użyciu prawidłowych kluczy bezpieczeństwa, a bezpieczne delegowanie zostało dodane do strefy głównej 1 kwietnia 2011 r.

Rozwiązujące skróty

Przeliczniki skrótów to „minimalne programy rozpoznawania nazw DNS, które używają rekursywnego trybu kwerendy, aby przenieść większość pracy związanej z rozwiązywaniem DNS na rekurencyjny serwer nazw”. Przelicznik skrótowy po prostu prześle żądanie do rekurencyjnego serwera nazw i użyje bitu danych uwierzytelnionych (AD) w odpowiedzi jako „wskazówki, aby dowiedzieć się, czy rekurencyjny serwer nazw był w stanie zweryfikować podpisy dla wszystkich danych w Sekcje Odpowiedzi i Uprawnienia w odpowiedzi." Microsoft Windows używa programu rozpoznawania skrótów, a zwłaszcza Windows Server 2008 R2 i Windows 7 używa niewalidującego, ale obsługującego AD-bitowego programu rozpoznawania nazw.

Walidacji stub rezolwer mogą potencjalnie wykonywać swój sprawdzanie podpisu przez ustawienie sprawdzanie wyłączone (CD) trochę w swoich wiadomościach zapytania. Weryfikujący program przeliczeniowy kodu pośredniczącego używa bitu CD do wykonania własnego uwierzytelniania rekurencyjnego. Użycie takiego walidującego programu rozpoznawania nazw pośredniczących zapewnia klientowi kompleksowe zabezpieczenie DNS dla domen implementujących DNSSEC, nawet jeśli dostawca usług internetowych lub połączenie z nim nie jest zaufane.

Niesprawdzające procedury rozpoznawania kodu pośredniczącego muszą polegać na zewnętrznych usługach sprawdzania poprawności DNSSEC, takich jak te kontrolowane przez dostawcę usług internetowych użytkownika ) lub na publicznym rekurencyjnym serwerze nazw i kanałach komunikacji między nim a tymi serwerami nazw przy użyciu metod takich jak DNS over TLS .

Kotwice zaufania i łańcuchy uwierzytelniania

Aby móc udowodnić, że odpowiedź DNS jest poprawna, trzeba znać przynajmniej jeden poprawny klucz lub rekord DS ze źródeł innych niż DNS. Te punkty początkowe są znane jako kotwice zaufania i są zwykle uzyskiwane z systemem operacyjnym lub z innego zaufanego źródła. Kiedy pierwotnie projektowano DNSSEC, sądzono, że jedyną potrzebną kotwicą zaufania jest główny element DNS . Kotwy korzeniowe zostały po raz pierwszy opublikowane 15 lipca 2010 r.

Uwierzytelniania łańcuch to seria połączonych DS i zapisów DNSKEY, począwszy od kotwicy zaufania do autorytatywnego serwera nazw dla domeny w pytaniu. Bez pełnego łańcucha uwierzytelniania odpowiedź na wyszukiwanie DNS nie może być bezpiecznie uwierzytelniona.

Podpisy i podpisywanie stref

Aby ograniczyć ataki polegające na powtarzaniu, istnieją nie tylko normalne wartości TTL DNS do celów buforowania, ale także dodatkowe znaczniki czasu w rekordach RRSIG, które ograniczają ważność podpisu. W przeciwieństwie do wartości TTL, które odnoszą się do czasu wysłania rekordów, sygnatury czasowe są bezwzględne. Oznacza to, że wszystkie programy rozpoznawania nazw DNS uwzględniające zabezpieczenia muszą mieć zegary, które są dość ściśle zsynchronizowane, powiedzmy w ciągu kilku minut.

Te sygnatury czasowe oznaczają, że strefa musi być regularnie ponownie podpisana i ponownie dystrybuowana do serwerów pomocniczych, w przeciwnym razie podpisy zostaną odrzucone przez weryfikację programów rozpoznawania nazw.

Zarządzanie kluczami

DNSSEC obejmuje wiele różnych kluczy przechowywanych zarówno w rekordach DNSKEY, jak i z innych źródeł, tworząc kotwice zaufania .

Aby umożliwić wymianę kluczy, wymagany jest schemat nawracania kluczy . Zwykle wiąże się to najpierw z wprowadzeniem nowych kluczy w nowych rekordach DNSKEY oprócz istniejących starych kluczy. Następnie, gdy można bezpiecznie założyć, że czas życia wartości spowodował, że minęło buforowanie starych kluczy, można użyć tych nowych kluczy. Wreszcie, gdy można bezpiecznie założyć, że buforowanie rekordów przy użyciu starych kluczy wygasło, stare rekordy DNSKEY można usunąć. Ten proces jest bardziej skomplikowany w przypadku kluczy do kotwic zaufania, takich jak root, co może wymagać aktualizacji systemu operacyjnego.

Klucze w rekordach DNSKEY mogą być używane do dwóch różnych rzeczy i zazwyczaj do każdego z nich używane są różne rekordy DNSKEY. Po pierwsze, istnieją klucze podpisywania kluczy (KSK), które służą do podpisywania innych rekordów DNSKEY. Po drugie, istnieją klucze podpisywania stref (ZSK), które służą do podpisywania innych rekordów. Ponieważ ZSK są pod pełną kontrolą i są używane przez jedną konkretną strefę DNS , można je przełączać łatwiej i częściej. W rezultacie ZSK mogą być znacznie krótsze niż KSK i nadal oferują ten sam poziom ochrony przy jednoczesnym zmniejszeniu rozmiaru rekordów RRSIG/DNSKEY.

Po utworzeniu nowego KSK rekord DS musi zostać przeniesiony do strefy nadrzędnej i tam opublikowany. Rekordy DS używają skrótu wiadomości KSK zamiast pełnego klucza, aby zachować mały rozmiar rekordów. Jest to przydatne w przypadku bardzo dużych stref, takich jak domena .com . Procedura aktualizacji kluczy DS w strefie nadrzędnej jest również prostsza niż wcześniejsze wersje DNSSEC, które wymagały, aby rekordy DNSKEY znajdowały się w strefie nadrzędnej.

Grupa Robocza DANE

Oparte na DNS uwierzytelnianie nazwanych jednostek (DANE) to grupa robocza IETF, której celem jest opracowanie protokołów i technik, które umożliwiają aplikacjom internetowym nawiązywanie kryptograficznie zabezpieczonej komunikacji z TLS , DTLS , SMTP i S/MIME w oparciu o DNSSEC.

Nowe protokoły umożliwią dodatkowe gwarancje i ograniczenia dla tradycyjnego modelu opartego na infrastrukturze klucza publicznego . Umożliwią one również właścicielom domen samodzielne wystawianie certyfikatów bez odwoływania się do zewnętrznych urzędów certyfikacji .

Obsługa zszywanych certyfikatów DNSSEC została włączona w Google Chrome 14, ale później została usunięta. W przypadku przeglądarki Mozilla Firefox wsparcie zapewniał dodatek, podczas gdy natywne wsparcie oczekuje na kogoś, kto zacznie nad nim pracować.

Historia

DNS jest krytyczną i fundamentalną usługą internetową, jednak w 1990 roku Steve Bellovin odkrył w niej poważne luki w zabezpieczeniach. Badania nad jego zabezpieczeniem rozpoczęły się i posunęły dramatyczny postęp, gdy jego artykuł został upubliczniony w 1995 roku. Wstępny dokument RFC 2065 został opublikowany przez IETF w 1997 roku, a początkowe próby wdrożenia tej specyfikacji doprowadziły do ​​poprawionej (i uważanej za w pełni wykonalnej) specyfikacji w 1999 roku jako IETF RFC 2535. Planowano wdrożyć DNSSEC w oparciu o RFC 2535.

Niestety specyfikacja IETF RFC 2535 miała bardzo poważne problemy ze skalowaniem do pełnego Internetu; do 2001 roku stało się jasne, że ta specyfikacja nie nadaje się do użytku w dużych sieciach. Podczas normalnej pracy serwery DNS często nie są zsynchronizowane ze swoimi rodzicami. Zwykle nie stanowi to problemu, ale po włączeniu DNSSEC te niezsynchronizowane dane mogą skutkować poważną samoistną odmową usługi. Pierwotny DNSSEC wymagał złożonego protokołu składającego się z sześciu wiadomości i wielu transferów danych, aby dokonać kluczowych zmian dla dziecka (strefy podrzędne DNS musiały wysyłać wszystkie swoje dane do rodzica, kazać rodzicowi podpisywać każdy rekord, a następnie je wysyłać podpisy z powrotem do dziecka, aby dziecko mogło przechowywać w rekordzie SIG). Ponadto zmiany klucza publicznego mogą mieć absurdalne skutki; na przykład, jeśli strefa „.com” zmieniła swój klucz publiczny, musiałaby wysłać 22 miliony rekordów (ponieważ musiałaby zaktualizować wszystkie podpisy we wszystkich swoich dzieciach). W związku z tym DNSSEC zdefiniowany w RFC 2535 nie mógł skalować się do Internetu.

IETF zasadniczo zmodyfikował DNSSEC, który jest nazywany DNSSEC-bis, gdy jest to konieczne, aby odróżnić go od oryginalnego podejścia DNSSEC w RFC 2535. Ta nowa wersja używa „rekordów zasobów osoby podpisującej delegację (DS)”, aby zapewnić dodatkowy poziom pośredniości w punktach delegowania między strefa rodzica i dziecka. W nowym podejściu, kiedy zmienia się główny klucz publiczny dziecka, zamiast sześciu wiadomości dla każdego rekordu w dziecku, jest jedna prosta wiadomość: dziecko wysyła nowy klucz publiczny do swojego rodzica (oczywiście podpisany). Rodzice po prostu przechowują jeden główny klucz publiczny dla każdego dziecka; jest to o wiele bardziej praktyczne. Oznacza to, że do rodzica przesyłana jest niewielka ilość danych, zamiast wymiany ogromnych ilości danych między rodzicem a dziećmi. Oznacza to, że klienci muszą wykonać trochę więcej pracy podczas weryfikacji kluczy. Dokładniej, weryfikacja KEY RRset strefy DNS wymaga dwóch operacji weryfikacji podpisu zamiast jednej wymaganej przez RFC 2535 (nie ma wpływu na liczbę sygnatur weryfikowanych dla innych typów RRsetów). Większość postrzega to jako niewielką cenę do zapłacenia, ponieważ sprawia, że ​​wdrażanie DNSSEC jest bardziej praktyczne.

Uwierzytelnianie odpowiedzi NXDOMAIN i NSEC

Kryptograficzne udowodnienie braku domeny wymaga podpisania odpowiedzi na każde zapytanie dotyczące nieistniejącej domeny. Nie stanowi to problemu w przypadku serwerów podpisujących online, które udostępniają swoje klucze online. Jednak DNSSEC został zaprojektowany z myślą o używaniu komputerów w trybie offline do podpisywania rekordów, tak aby klucze podpisywania stref mogły być przechowywane w chłodni. Stanowi to problem podczas próby uwierzytelnienia odpowiedzi na zapytania dotyczące nieistniejących domen, ponieważ niemożliwe jest wstępne wygenerowanie odpowiedzi na każde możliwe zapytanie o nazwę hosta.

Pierwszym rozwiązaniem było utworzenie rekordów NSEC dla każdej pary domen w strefie. Zatem jeśli klient zapyta o rekord w nieistniejącym k.example.com, serwer odpowie rekordem NSEC stwierdzającym, że nic nie istnieje pomiędzy a.example.comi z.example.com. Jednak powoduje to wyciek większej ilości informacji o strefie niż tradycyjne nieuwierzytelnione błędy NXDOMAIN, ponieważ ujawnia istnienie prawdziwych domen.

Rekordy NSEC3 (RFC 5155) zostały utworzone jako alternatywa, która haszuje nazwę zamiast wymieniać je bezpośrednio. Z biegiem czasu postępy w mieszaniu przy użyciu procesorów graficznych i dedykowanego sprzętu sprawiły, że odpowiedzi NSEC3 można było tanio wymusić brutalnie za pomocą ataków słownikowych offline. Zaproponowano NSEC5 , aby umożliwić autorytatywnym serwerom podpisywanie odpowiedzi NSEC bez konieczności przechowywania klucza prywatnego, którego można użyć do modyfikacji strefy. Zatem kradzież klucza NSEC5KEY skutkowałaby jedynie możliwością łatwiejszego wyliczenia strefy.

Ze względu na niechlujną ewolucję protokołu i chęć zachowania kompatybilności wstecznej, serwery podpisywania DNSSEC online zwracają „białe kłamstwo” zamiast bezpośrednio uwierzytelniać odmowę istnienia. Technika przedstawiona w RFC 4470 zwraca rekord NSEC, w którym pary domen leksykalnie otaczają żądaną domenę. Na przykład żądanie o k.example.comspowoduje powstanie rekordu NSEC udowadniającego, że nic nie istnieje między (fikcyjnymi) domenami j.example.comi l.example.com. CloudFlare jest pionierem innego podejścia, w którym udowadnia, że ​​„rekord istnieje, ale żądany typ rekordu nie”, co ma tę zaletę, że znacznie zmniejszony jest rozmiar ładunku.

Rozlokowanie

Internet jest infrastrukturą krytyczną, jednak jego działanie zależy od fundamentalnie niezabezpieczonego DNS. Dlatego istnieje silna zachęta do zabezpieczania DNS, a wdrożenie DNSSEC jest ogólnie uważane za kluczową część tych wysiłków. Na przykład amerykańska Narodowa Strategia Zabezpieczenia Cyberprzestrzeni wyraźnie określiła potrzebę zabezpieczenia DNS. Wdrożenie DNSSEC na szeroką skalę może również rozwiązać wiele innych problemów związanych z bezpieczeństwem, takich jak bezpieczna dystrybucja kluczy dla adresów e-mail.

Wyzwaniem jest również wdrażanie DNSSEC w sieciach o dużej skali. Ozment i Schechter zauważają, że DNSSEC (i inne technologie) mają „problem z ładowaniem początkowym”: użytkownicy zazwyczaj wdrażają technologię tylko wtedy, gdy uzyskują natychmiastową korzyść, ale jeśli wymagany jest minimalny poziom wdrożenia, zanim jakikolwiek użytkownik otrzyma korzyści większe niż ich koszty (tak jak w przypadku DNSSEC) jest trudny do wdrożenia. DNSSEC można wdrożyć na dowolnym poziomie hierarchii DNS, ale musi być powszechnie dostępny w strefie, zanim wielu innych będzie chciało go zastosować. Serwery DNS należy zaktualizować przy użyciu oprogramowania obsługującego DNSSEC, a dane DNSSEC należy utworzyć i dodać do danych strefy DNS. Klient korzystający z protokołu TCP/IP musi mieć zaktualizowany program rozpoznawania nazw (klient) DNS, zanim będzie mógł korzystać z funkcji DNSSEC. Co więcej, każdy resolver musi mieć lub mieć sposób na uzyskanie przynajmniej jednego klucza publicznego, któremu może zaufać, zanim będzie mógł zacząć używać DNSSEC.

Implementacja DNSSEC może znacznie obciążyć niektóre serwery DNS. Typowe odpowiedzi podpisane przez DNSSEC są znacznie większe niż domyślny rozmiar UDP wynoszący 512 bajtów. Teoretycznie można to obsłużyć za pomocą wielu fragmentów adresów IP, ale wiele „środkowych skrzynek” w tej dziedzinie nie obsługuje ich poprawnie. Prowadzi to do użycia TCP zamiast. Jednak wiele obecnych implementacji TCP przechowuje dużą ilość danych dla każdego połączenia TCP; mocno obciążonym serwerom może zabraknąć zasobów po prostu próbując odpowiedzieć na większą liczbę (prawdopodobnie fałszywych) żądań DNSSEC. Niektóre rozszerzenia protokołu, takie jak TCP Cookie Transactions , zostały opracowane w celu zmniejszenia tego obciążenia. Aby sprostać tym wyzwaniom, podejmowane są znaczne wysiłki w celu wdrożenia DNSSEC, ponieważ Internet jest tak ważny dla tak wielu organizacji.

Wczesne wdrożenia

Wśród pierwszych użytkowników są Brazylia ( .br ), Bułgaria ( .bg ), Czechy ( .cz ), Namibia ( .na ) Portoryko ( .pr ) i Szwecja ( .se ), które używają DNSSEC jako najwyższego poziomu kodu kraju domeny ; RIPE NCC , którzy podpisali wszystkie rekordy wyszukiwania wstecznego (in-addr.arpa) delegowane do niego przez Internet Assigned Numbers Authority (IANA). ARIN podpisuje również swoje strefy odwrotne. W lutym 2007 r. firma TDC została pierwszym szwedzkim dostawcą usług internetowych, który zaczął oferować tę funkcję swoim klientom.

IANA publicznie testowała przykładowy podpisany root od czerwca 2007. W tym okresie przed podpisaniem produkcyjnym roota istniało również kilka alternatywnych kotwic zaufania. IKS Jena wprowadził jedną 19 stycznia 2006 r., Internet Systems Consortium wprowadził kolejną 27 marca tego samego roku, a sam ICANN ogłosił trzeci 17 lutego 2009 r.

2 czerwca 2009 r. Afilias , dostawca usług rejestrowych dla strefy .org rejestru interesu publicznego , podpisał .org TLD. Afilias i PIR wyszczególniły również 26 września 2008 r., że pierwsza faza, obejmująca dużych rejestratorów, z którymi ma silne relacje robocze („przyjaciele i rodzina”), będzie pierwszą, która będzie mogła podpisywać swoje domeny, począwszy od „początku 2009 r.” . 23 czerwca 2010 r. 13 rejestratorów zostało wymienionych jako oferujących rekordy DNSSEC dla domen .ORG.

Firma VeriSign przeprowadziła projekt pilotażowy, aby umożliwić domenom .com i .net rejestrację w celu przeprowadzenia eksperymentów NSEC3. 24 lutego 2009 r. ogłosili, że w ciągu 24 miesięcy wdrożą DNSSEC we wszystkich swoich domenach najwyższego poziomu (.com, .net itp.), a 16 listopada tego samego roku podali .com i . domeny sieciowe zostałyby podpisane do pierwszego kwartału 2011 roku, po opóźnieniach spowodowanych technicznymi aspektami wdrożenia. Cel ten został osiągnięty zgodnie z harmonogramem, a wiceprezes ds. DNSSEC firmy Verisign, Matt Larson, zdobył nagrodę InfoWorld's Technology Leadership Award za rok 2011 za swoją rolę w rozwoju DNSSEC.

Wdrożenie w katalogu głównym DNS

DNSSEC został po raz pierwszy wdrożony na poziomie głównym 15 lipca 2010 r. Oczekuje się, że znacznie uprości to wdrażanie programów rozpoznawania nazw DNSSEC, ponieważ główna kotwica zaufania może służyć do sprawdzania poprawności każdej strefy DNSSEC, która ma pełny łańcuch zaufania od strony głównej. Ponieważ łańcuch zaufania musi być śledzony z powrotem do zaufanego katalogu głównego bez przerywania w celu weryfikacji, kotwice zaufania muszą nadal być skonfigurowane dla bezpiecznych stref, jeśli którakolwiek ze stref nad nimi nie jest bezpieczna. Na przykład, jeśli strefa „signed.example.org” została zabezpieczona, ale strefa „example.org” nie, to nawet jeśli strefa „.org” i katalog główny są podpisane, kotwica zaufania musi zostać wdrożona w aby zatwierdzić strefę.

Kwestie polityczne związane z podpisaniem roota są ciągłym problemem, głównie z niektórymi kluczowymi kwestiami:

  • Inne kraje są zaniepokojone kontrolą USA nad Internetem i mogą z tego powodu odrzucić jakiekolwiek scentralizowane kluczowanie.
  • Niektóre rządy mogą próbować zakazać dystrybucji kluczy szyfrowania wspieranych przez DNSSEC.

Planowanie

We wrześniu 2008 r. ICANN i VeriSign opublikowały propozycje wdrożeniowe, aw październiku Krajowa Administracja Telekomunikacji i Informacji (NTIA) poprosiła opinię publiczną o komentarze. Nie jest jasne, czy otrzymane uwagi wpłynęły na projekt ostatecznego planu wdrożenia.

3 czerwca 2009 r. Narodowy Instytut Standardów i Technologii (NIST) ogłosił plany podpisania głównego do końca 2009 r., we współpracy z ICANN, VeriSign i NTIA.

6 października 2009 r., na 59. spotkaniu Konferencji RIPE , ICANN i VeriSign ogłosiły planowany harmonogram wdrożenia DNSSEC w strefie głównej. Na spotkaniu ogłoszono, że będzie on stopniowo wdrażany na jednym głównym serwerze nazw miesięcznie, począwszy od 1 grudnia 2009 r., a ostatni główny serwer nazw będzie obsługiwał strefę podpisaną DNSSEC 1 lipca 2010 r., a strefa główna będzie podpisany za pomocą klucza DNS RSA/SHA256. W okresie stopniowego wdrażania strefa główna będzie obsługiwać celowo niesprawdzoną strefę główną (DURZ), która korzysta z kluczy fikcyjnych, a ostateczny rekord DNSKEY nie będzie dystrybuowany do 1 lipca 2010 r. Oznacza to, że klucze zostały użyte do podpisania strefy użycie są celowo nieweryfikowalne; powodem tego wdrożenia było monitorowanie zmian we wzorcach ruchu spowodowanych większymi odpowiedziami na zapytania żądające rekordów zasobów DNSSEC.

.Org domeny najwyższego poziomu została podpisana z DNSSEC w czerwcu 2010 roku, a następnie .com , .net oraz .edu później w 2010 i 2011 roku kod kraju domeny najwyższego poziomu mogli zdeponować kluczyki od maja 2010 roku listopada 2011 ponad 25% domen najwyższego poziomu jest podpisywanych za pomocą DNSSEC.

Realizacja

25 stycznia 2010 r. serwer główny L (ell) zaczął obsługiwać strefę deliberately unvalidable root zone (DURZ). Strefa wykorzystuje sygnatury skrótu SHA-2 (SHA-256) utworzonego przy użyciu algorytmu RSA , zgodnie z definicją w RFC 5702. Od maja 2010 r. wszystkie trzynaście serwerów głównych zaczęło obsługiwać DURZ. 15 lipca 2010 r. podpisano pierwszą główną strefę główną DNSSEC z pełną produkcją z numerem seryjnym SOA 2010071501. Główne kotwice zaufania są dostępne w firmie IANA .

Wdrożenie na poziomie TLD

Pod korzeniem znajduje się duży zestaw domen najwyższego poziomu, które muszą zostać podpisane, aby osiągnąć pełne wdrożenie DNSSEC. Lista domen internetowych najwyższego poziomu zawiera szczegółowe informacje na temat, który z istniejących domen najwyższego poziomu zostały podpisane i związane z korzenia.

Sprawdzanie DNSSEC Lookaside — dane historyczne

W marcu 2006 roku Internet Systems Consortium wprowadziło rejestr DNSSEC Lookaside Validation. DLV miał na celu ułatwienie wdrożenia DNSSEC w przypadku braku głównej kotwicy zaufania. W tamtym czasie wyobrażano sobie, że walidator może być zmuszony do utrzymywania dużej liczby kotwic zaufania odpowiadających podpisanym poddrzewom DNS. Celem DLV było umożliwienie walidatorom przeniesienia wysiłku związanego z zarządzaniem repozytorium kotwic zaufania na zaufaną stronę trzecią. Rejestr DLV utrzymywał centralną listę kotwic zaufania, zamiast każdego walidatora powtarzania pracy polegającej na utrzymywaniu własnej listy.

Aby użyć DLV, potrzebny był walidator, który go obsługuje, taki jak BIND lub Unbound , skonfigurowany z kotwicą zaufania dla strefy DLV. Strefa ta zawierała rekordy DLV; miały one dokładnie taki sam format jak rekordy DS, ale zamiast odnosić się do delegowanej podstrefy, odnosiły się do strefy w innym miejscu w drzewie DNS. Gdy walidator nie mógł znaleźć łańcucha zaufania od katalogu głównego do zestawu RR, który próbuje sprawdzić, szukał rekordu DLV, który mógłby zapewnić alternatywny łańcuch zaufania.

Luki w łańcuchu zaufania, takie jak niepodpisane domeny najwyższego poziomu lub rejestratory, które nie obsługują delegacji DNSSEC, oznaczały, że administratorzy domen niższego poziomu mogli używać DLV, aby umożliwić weryfikację ich danych DNS przez programy rozpoznawania nazw, które zostały skonfigurowane do korzystania z DLV . Mogło to utrudnić wdrożenie DNSSEC, odciążając rejestratorów i rejestry TLD, aby prawidłowo obsługiwały DNSSEC. DLV zwiększył również złożoność, dodając więcej aktorów i ścieżek kodu do walidacji DNSSEC.

Firma ISC zlikwidowała swój rejestr DLV w 2017 r. Obsługa DLV została wycofana w wersji BIND 9.12 i całkowicie usunięta z wersji BIND 9.16. Niezwiązana wersja 1.5.4 (lipiec 2015) oznaczyła DLV jako wycofaną z użycia w przykładowej konfiguracji i na stronie podręcznika. Knot Resolver i PowerDNS Recursor nigdy nie zaimplementowały DLV.

W marcu 2020 r. IETF opublikował RFC 8749, wycofując DLV jako standard i przenosząc RFC 4432 i RFC 5074 do statusu „Historic”.

Inicjatywa wdrożenia DNSSEC przez rząd federalny USA

Dyrekcja ds. Nauki i Technologii Departamentu Bezpieczeństwa Wewnętrznego Stanów Zjednoczonych (DHS) sponsoruje inicjatywę „DNSSEC Deployment Initiative”. Ta inicjatywa zachęca „wszystkie sektory do dobrowolnego przyjęcia środków bezpieczeństwa, które poprawią bezpieczeństwo infrastruktury nazewniczej Internetu, w ramach globalnego, wspólnego wysiłku, który angażuje wiele narodów i organizacji z sektora publicznego i prywatnego”. DHS finansuje również wysiłki na rzecz dojrzałości DNSSEC i wdrożenia jej w rządzie federalnym Stanów Zjednoczonych.

Poinformowano, że 30 marca 2007 r. Departament Bezpieczeństwa Wewnętrznego USA zaproponował „posiadanie klucza do solidnego podpisania strefy głównej DNS w rękach rządu USA”. Jednak w sali konferencyjnej nie było żadnych urzędników rządu USA, a komentarz, który wywołał artykuł, wygłosiła inna strona. DHS później skomentował, dlaczego uważają, że inni pochopnie doszli do fałszywego wniosku, że rząd USA złożył taką propozycję: „Departament Bezpieczeństwa Wewnętrznego USA finansuje opracowanie technicznego planu wdrożenia DNSSec, a w październiku ubiegłego roku rozpowszechnił wstępny projekt do długiej listy międzynarodowych ekspertów w celu uzyskania komentarzy. Projekt przedstawia szereg opcji dotyczących tego, kto może być posiadaczem lub „operatorem” Klucza Strefy Root, zasadniczo sprowadzając się do agencji rządowej lub wykonawcy. w dokumencie czy przedstawiamy jakąkolwiek propozycję dotyczącą tożsamości głównego operatora głównego” – powiedział Maughan, kierownik ds. badań i rozwoju cyberbezpieczeństwa w Homeland Security.

Wdrożenie DNSSEC w rządzie federalnym USA

National Institute of Standards and Technology (NIST) opublikował Publikacja NIST Special 800-81 Bezpieczne Domain Name System (DNS) Przewodnik wdrażania w dniu 16 maja 2006 roku, z wytycznych dotyczących sposobu wdrażania DNSSEC. NIST zamierzał wydać nowe wymagania DNSSEC Federal Information Security Management Act (FISMA) w NIST SP800-53-R1, odwołując się do tego przewodnika wdrażania. Amerykańskie agencje miałyby wtedy rok po ostatecznej publikacji NIST SP800-53-R1 na spełnienie tych nowych wymagań FISMA. Jednak w tym czasie NSEC3 nie został ukończony. NIST zasugerował użycie dzielonych domen, techniki, o której wiadomo, że jest możliwa, ale jest trudna do prawidłowego wdrożenia i ma słabości bezpieczeństwa wymienione powyżej.

W dniu 22 sierpnia 2008 r. Biuro Zarządzania i Budżetu (OMB) opublikowało memorandum wymagające od agencji federalnych USA wdrożenia DNSSEC w witrynach .gov; root .gov musi zostać podpisany do stycznia 2009 r., a wszystkie subdomeny .gov muszą zostać podpisane do grudnia 2009 r. Chociaż notatka skupia się na witrynach .gov, amerykańska Agencja Systemów Informacyjnych Obrony twierdzi, że zamierza spełnić wymagania OMB DNSSEC w . domena mil (amerykańskie wojsko). Carolyn Duffy Marsan z NetworkWorld stwierdziła, że ​​DNSSEC „nie był szeroko stosowany, ponieważ cierpi na klasyczny dylemat kurczaka i jajka… z mandatem OMB wydaje się, że jajko pęka”.

Wdrożenie w przelicznikach

Kilku dostawców usług internetowych rozpoczęło wdrażanie rekurencyjnych rekursywnych przeliczników DNS z walidacją DNSSEC. Comcast stał się pierwszym dużym dostawcą usług internetowych, który to zrobił w Stanach Zjednoczonych, ogłaszając swoje zamiary 18 października 2010 r. i kończąc wdrożenie 11 stycznia 2012 r.

Według badania przeprowadzonego przez APNIC odsetek klientów korzystających wyłącznie z resolwerów DNS wykonujących weryfikację DNSSEC wzrósł do 8,3% w maju 2013 r. Około połowa z tych klientów korzystała z publicznego resolwera DNS firmy Google .

We wrześniu 2015 r. firma Verisign ogłosiła swoją bezpłatną usługę publicznego rozpoznawania nazw DNS i chociaż nie została wymieniona w swoich komunikatach prasowych, przeprowadza również walidację DNSSEC.

Na początku 2016 roku monitoring APNIC wykazał, że odsetek klientów korzystających wyłącznie z resolwerów DNS wykonujących walidację DNSSEC wzrósł do około 15%.

Obsługa DNSSEC

Publiczny rekursywny serwer DNS firmy Google włączył weryfikację DNSSEC 6 maja 2013 r.

BIND , najpopularniejsze oprogramowanie do zarządzania DNS, domyślnie włącza obsługę DNSSEC od wersji 9.5.

Quad9 publicznego rekurencyjne DNS dokonał walidacji DNSSEC na swoim głównym 9.9.9.9 adres, ponieważ powstała w dniu 11 maja 2016 roku Quad9 zapewnia również alternatywną usługę, która nie wykonuje walidacji DNSSEC, głównie do debugowania.

Publikacje IETF

  • RFC  2535 — rozszerzenia zabezpieczeń systemu nazw domen
  • RFC  3225 wskazujący na obsługę DNSSEC przez resolwer
  • RFC  3226 DNSSEC i IPv6 A6 Aware Aware Server/Resolver — wymagania dotyczące rozmiaru wiadomości
  • RFC  3833 Analiza zagrożeń związanych z systemem nazw domen
  • RFC  4033 — wprowadzenie i wymagania dotyczące zabezpieczeń DNS ( DNSSEC-bis )
  • RFC  4034 rekordy zasobów dla rozszerzeń zabezpieczeń DNS ( DNSSEC-bis )
  • RFC  4035 Modyfikacje protokołu dla rozszerzeń zabezpieczeń DNS ( DNSSEC-bis )
  • RFC  4398 przechowywanie certyfikatów w systemie nazw domen (DNS)
  • RFC  4431 Rekord zasobów DNS z sprawdzaniem poprawności wyszukiwania DNSSEC (DLV)
  • RFC  4470 minimalnie obejmujący rekordy NSEC i podpisywanie online DNSSEC
  • RFC  4509 Użycie SHA-256 w rekordach zasobów (RR) osoby podpisującej delegację DNSSEC (DS)
  • RFC  4955 Eksperymenty dotyczące bezpieczeństwa DNS (DNSSEC)
  • RFC  5011 — automatyczne aktualizacje kotwic zaufania zabezpieczeń DNS (DNSSEC)
  • RFC  5155 uwierzytelniona odmowa istnienia protokołu DNSSEC z haszowaniem
  • RFC  5702 Użycie algorytmów SHA-2 z RSA w rekordach zasobów DNSKEY i RRSIG dla DNSSEC
  • RFC  6605 Algorytm podpisu cyfrowego krzywej eliptycznej (DSA) dla DNSSEC
  • RFC  6725 Zabezpieczenia DNS (DNSSEC) Algorytm DNSKEY Aktualizacje rejestru IANA
  • RFC  6781 Praktyki operacyjne DNSSEC, wersja 2
  • RFC  6840 objaśnienia i uwagi dotyczące implementacji dotyczące zabezpieczeń DNS (DNSSEC)
  • RFC  7344 – automatyzacja utrzymania zaufania delegowania DNSSEC
  • RFC  7583 Uwagi dotyczące czasu przerzucania kluczy DNSSEC
  • RFC  8080 Edwards-Curve algorytm bezpieczeństwa cyfrowego (EdDSA) dla DNSSEC
  • RFC  8624 — wymagania dotyczące implementacji algorytmu i wskazówki dotyczące użytkowania dla DNSSEC
  • RFC  8749 – przenoszenie walidacji Lookaside DNSSEC (DLV) do statusu historycznego

Narzędzia

Wdrożenie DNSSEC wymaga oprogramowania po stronie serwera i klienta. Niektóre z narzędzi obsługujących DNSSEC obejmują:

Zobacz też

Bibliografia

Dalsza lektura

Zewnętrzne linki