Streszczenie
W tym artykule omawiamy wdrożenie DNSSEC (rozszerzenia bezpieczeństwa systemu nazwy domeny) przez publiczną usługę DNS Google. DNSSEC to technologia, która dodaje bezpieczne podpisy kryptograficzne do DNS w celu złagodzenia luk i zapewnienia integralności rozdzielczości DNS. Podczas gdy DNSSEC istnieje od wielu lat, jego adopcja była stosunkowo niska. Publiczne DN Google wykonuje teraz walidację DNSSEC dla wszystkich zapytań domyślnie, zwiększając bezpieczeństwo usługi rozdzielczości DNS.
Kluczowe punkty:
- DNSSEC to krytyczna technologia, która dodaje podpisy kryptograficzne do DNS w celu ochrony przed atakami DNS.
- DNSSEC zapewnia integralność i autentyczność rozdzielczości DNS, uniemożliwiając użytkownikom przekierowanie na złośliwe strony internetowe.
- Public DNS Google to szeroko stosowany DNS Resoluver, który teraz domyślnie wykonuje sprawdzanie poprawności DNSSEC.
- Wdrażając DNSSEC, publiczne DN Google zwiększa bezpieczeństwo i wiarygodność swojej usługi rozwiązywania DNS.
- Przyjęcie DNSSEC było powolne z powodu różnych czynników, w tym braku motywacji wśród administratorów nazw domen i autorów przeglądarki.
- Usługi takie jak SECSPIDER śledzą postęp wdrożenia DNSSEC, zliczając liczbę nazw domen z poświadczeniami DNSSEC.
- ANPNIC LABS Przeprowadziły pomiary w celu oszacowania zakresu sprawdzania poprawności DNSSEC przez aplikacje użytkowników końcowych.
- W swoich początkowych pomiarach wydawało się, że około 9% klientów korzysta z rozdzielczości DNS, które przeprowadziły walidację DNSSEC.
- Nowszy pomiar wykazał, że około 1.6% klientów wykorzystywało wyłącznie rozdzielcze DNS, które konsekwentnie wykonywały walidację DNSSEC.
- Wyniki te podkreślają stosunkowo niski poziom adopcji DNSSEC i potrzebę zwiększonej świadomości i wdrażania technologii.
Unikalne pytania:
- Dlaczego DNSSEC jest ważne dla bezpieczeństwa rozdzielczości DNS?
DNSSEC dodaje podpisy kryptograficzne do DNS, zapewniając integralność i autentyczność rozdzielczości DNS. Bez DNSSEC użytkownicy są podatni na ataki DNS, w których ich aplikacje są kierowane na złośliwe strony internetowe zamiast zamierzonego miejsca docelowego. - Jakie jest znaczenie publicznego DN Google wdrażające walidację DNSSEC domyślnie?
Publiczne DN Google to szeroko stosowany DNS Resolver, a jego wdrożenie walidacji DNSSEC domyślnie zwiększa bezpieczeństwo i wiarygodność usługi rozwiązywania rozwiązywania przez DNS. Zapewnia to, że użytkownicy są chronieni przed atakami DNS i mogą mieć większe zaufanie do dokładności rezolucji DNS dostarczonych przez publiczne DN Google. - Dlaczego przyjęcie DNSSEC było powolne?
Przyjęcie DNSSEC było powolne z powodu różnych czynników. Jednym istotnym czynnikiem jest brak motywacji wśród administratorów nazwy domeny i autorów przeglądarki do podpisywania nazw domen za pomocą poświadczeń DNSSEC. Ponadto niskie poziomy wdrożenia DNSSEC sprawiają, że jest mniej przekonujące dla narzędzi klienta w celu włączenia walidacji DNSSEC do rozdzielczości DNS. - Jaka jest rola usług takich jak SecSpider w śledzeniu wdrożenia DNSSEC?
Usługi takie jak SECSPIDER śledzą postęp wdrożenia DNSSEC, zliczając liczbę nazw domen, które zawierają poświadczenia DNSSEC. Pomaga to zmierzyć zakres, w jakim nazwy domeny są podpisywane przy użyciu podpisów DNSSEC i zapewnia wgląd w ogólne przyjęcie DNSSEC. - W jaki sposób laboratoria ANPNIC kwantyfikowało zakres sprawdzania poprawności DNSSEC według aplikacji użytkowników końcowych?
ANPNIC LABS Przeprowadziły pomiary w celu ustalenia, w jakim stopniu klienci używają sprawdzania poprawności DNSSEC w połączeniu z rozdzielczością nazwiska. Pomiary te obejmowały obserwowanie dziennika zapytania DNS na autorytatywnych serwerach nazw oraz analizowanie sekwencji i czasów zapytań DNS w celu wnioskowania o możliwościach DNSSEC widocznych rozdzielczości DNS DNS. - Jakie były wyniki początkowych pomiarów laboratoriów ANPNIC?
Początkowe pomiary przez laboratoria ANPNIC wykazały, że około 9% klientów wydawało się używać rozdzielczości DNS, które wykonały jakąś formę walidacji DNSSEC. - Jakie ograniczenia zaobserwowano w początkowym podejściu pomiarowym?
Wstępne podejście pomiarowe zastosowano dynamiczne wytwarzanie unikalnych etykiet DNS i wspólnego łańcucha podpisu DNSSEC. Takie podejście oparło się na buforowaniu rozdzielczości DNS, które wpłynęło na dokładność wyników. Późniejsze pomiary przeprowadzono w celu rozwiązania tych ograniczeń. - Jaki był wynik najnowszego pomiaru przez laboratoria beznadziejne?
Nowszy pomiar wykazał, że około 1.6% klientów wykorzystywało wyłącznie rozdzielcze DNS, które konsekwentnie wykonywały walidację DNSSEC. Wskazuje to, że przyjęcie sprawdzania poprawności DNSSEC przez aplikacje końcowe jest nadal stosunkowo niskie. - Co oznacza niski poziom adopcji DNSSEC?
Niski poziom adopcji DNSSEC sugeruje potrzebę zwiększonej świadomości i rozmieszczenia DNSSEC. Bez szerszego przyjęcia korzyści płynących z DNSSEC, takie jak bezpieczna nazwa domeny do mapowania adresów IP i kluczowe oferty TLS za pośrednictwem technologii takich jak Dane, pozostają niewykorzystane. - Jaki jest potencjalny wpływ szerszego adopcji DNSSEC?
Szersze adopcja DNSSEC zwiększyłaby bezpieczeństwo i wiarygodność rozdzielczości DNS dla wszystkich użytkowników. Zmniejszyłoby to ryzyko ataków opartych na DNS i zapewniłoby bezpieczniejsze mapowanie między nazwami domen a adresami IP, wzmacniając ogólne bezpieczeństwo Internetu.
Odpowiedzi:
- DNSSEC jest ważne dla bezpieczeństwa rozdzielczości DNS, ponieważ
DNSSEC dodaje podpisy kryptograficzne do DNS, zapewniając integralność i autentyczność rozdzielczości DNS. Bez DNSSEC użytkownicy są podatni na ataki DNS, takie jak fałszowanie DNS lub zatrucie pamięci podręcznej, gdzie ich aplikacje są przekierowywane na złośliwe strony internetowe zamiast zamierzonego miejsca docelowego. Poprzez sprawdzanie odpowiedzi DNS za pomocą DNSSEC użytkownicy mogą mieć większą pewność, że rozwiązane adresy IP są rzeczywiście powiązane z zamierzonymi nazwami domen. - Znaczenie publicznego DNS wdrażające walidację DNSSEC domyślnie jest
Publiczne DNS Google jest jednym z najczęściej używanych rozdzielczości DNS, a jego wdrożenie walidacji DNSSEC domyślnie zwiększa bezpieczeństwo i wiarygodność usługi rozwiązywania rozwiązywania przez DNS. Dzięki walidacji DNSSEC publiczne DN Google może zweryfikować autentyczność i integralność odpowiedzi DNS, chroniąc użytkowników przed atakami opartymi na DNS. Ta domyślna walidacja zapewnia, że wszystkie zapytania dokonane za pośrednictwem publicznych DN Google są poddawane czekom DNSSEC, zapewniając dodatkową warstwę bezpieczeństwa użytkownikom. - Można przypisać powolne przyjęcie DNSSEC
Różne czynniki przyczyniają się do powolnego przyjęcia DNSSEC. Jednym z czynników jest brak motywacji wśród administratorów nazw domen do podpisywania nazw domen za pomocą poświadczeń DNSSEC. Wysiłek i dodatkowa złożoność związana z zarządzaniem klawiszami i podpisami DNSSEC mogą zniechęcać administratorów domen do przyjęcia DNSSEC. Ponadto autorzy przeglądarki mogli niechętnie wdrażać walidację DNSSEC ze względu na ograniczoną liczbę podpisanych nazw domen. Niskie zapotrzebowanie na walidację DNSSEC od użytkowników może również wpłynąć na motywację do wdrażania narzędzi klienta, które obsługują DNSSEC. Czynniki te tworzą cykl niskiej adopcji i ograniczonych zachęt do dalszego wdrażania. - Usługi takie jak Secspider śledzą wdrożenie DNSSEC przez
Usługi takie jak SecSpider Monitoruj postęp wdrożenia DNSSEC, zliczając liczbę nazw domen zawierających poświadczenia DNSSEC. Regularnie skanując strefy DNS i analizę podpisów DNSSEC, SECSPIDER może dostarczyć informacji na temat rozpowszechnienia podpisanych nazw domen i ogólnego przyjęcia DNSSEC. To śledzenie pomaga podnieść świadomość wskaźników adopcji DNSSEC i zachęca administratorów nazw domen do rozważenia wdrożenia DNSSEC dla ich domen. - ANPNIC LABS określono ilościowo stopień walidacji DNSSEC według
ANPNIC LABS określono ilościowo stopień sprawdzania poprawności DNSSEC poprzez przeprowadzanie pomiarów w aplikacjach użytkowników końcowych. Pomiary te obejmowały obserwowanie dziennika zapytania DNS na autorytatywnych serwerach nazwy i analizę sekwencji i czasów zapytań DNS. Badając odpowiedzi i wzorce czasowe, laboratoria bezwzględne mogą wywnioskować, czy rozstrzygający DNS używane przez użytkowników końcowych przeprowadziły walidację DNSSEC. Dane te dostarczyły wgląd w proporcję aplikacji użytkowników końcowych, które aktywnie wykorzystują sprawdzanie poprawności DNSSEC podczas rozwiązywania nazwisk. - W początkowych pomiarach laboratoriów ANPNIC około 9% klientów wydawało się
W początkowych pomiarach laboratoriów APNIC około 9% klientów wykorzystywało rozdzielczości DNS, które wykonały jakąś formę walidacji DNSSEC. To odkrycie sugeruje niewielki poziom przyjęcia DNSSEC wśród części aplikacji użytkowników końcowych. Podczas gdy 9% można uznać za stosunkowo niską liczbę, oznacza to, że znaczna liczba użytkowników lub organizacji wybrała, aby umożliwić walidację DNSSEC, priorytetyzując zwiększone bezpieczeństwo, które oferuje. - Ograniczenia zaobserwowane w początkowym podejściu pomiarowym przez laboratoria bezcerem
Początkowe podejście pomiarowe zastosowane przez laboratoria beznośnika miało pewne ograniczenia. Jednym ograniczeniem było poleganie na buforowaniu DNS. Eksperyment obejmował internetową kampanię reklamową, która zapisała miliony klientów końcowych do wykonywania zadań pobierania obiektów DNS. Wspólny łańcuch podpisu DNSSEC w całym eksperymencie oznaczał, że po tym, jak DNS Resitver odzyskał rekordy zasobów DNSSEC (RRS), kolejne zapytania dla tych samych RRS DNSSEC były obsługiwane z lokalnej pamięci podręcznej Resolver. To zachowanie buforowania utrudniało dokładną ocenę rzeczywistych możliwości DNSSEC każdego rozdzielonego i spowodowało potencjalne przeszacowanie przyjęcia DNSSEC. - W najnowszym pomiarze około 1.6% klientów wykorzystywało wyłącznie rozstrzygnięcia DNS
W najnowszym pomiarze przez ANPRAT LABS, około 1.6% klientów wykorzystywało wyłącznie rozdzielcze DNS, które konsekwentnie wykonywały walidację DNSSEC. Wskazuje to, że przyjęcie sprawdzania poprawności DNSSEC przez aplikacje końcowe jest nadal stosunkowo niskie. Chociaż nastąpił niewielki wzrost w porównaniu z poprzednimi pomiarami, podkreśla potrzebę bardziej rozpowszechnionego przyjęcia DNSSEC wśród rozdzielczości DNS i aplikacji użytkowników końcowych. - Niski poziom adopcji DNSSEC oznacza, że
Niski poziom adopcji DNSSEC oznacza, że pełny potencjał DNSSEC nie został jeszcze zrealizowany. Mając tylko niewielki odsetek klientów i administratorów nazwy domeny aktywnie korzystając z DNSSEC, korzyści płynące z bezpiecznej nazwy domeny do mapowania adresów IP i publicznego udostępniania TLS za pośrednictwem technologii takich jak Dane pozostają niewykorzystane. Szersze przyjęcie DNSSEC przyczyniłoby się do bezpieczniejszej infrastruktury internetowej poprzez zmniejszenie ryzyka ataków opartych na DNS i zapewnienie bezpiecznej komunikacji między klientami i serwerami. - Potencjalny wpływ szerszego adopcji DNSSEC obejmuje
Szersza adopcja DNSSEC znacznie zwiększyłaby bezpieczeństwo i wiarygodność rozdzielczości DNS dla wszystkich użytkowników. Zmniejszyłoby to ryzyko ataków opartych na DNS, takich jak zatrucie pamięci podręcznej DNS i porwanie DNS, chroniąc użytkowników przed przekierowaniem na złośliwe strony internetowe. Ponadto DNSSEC zapewnia bezpieczne mapowanie między nazwami domen a adresami IP, zapewniając, że użytkownicy łączą się z zamierzonymi serwerami. To wzmacnia ogólne bezpieczeństwo Internetu i sprzyja zaufaniu do interakcji online.
Potwierdzone – Google’S publiczne DNS wykonuje teraz walidację DNSSEC dla wszystkich zapytań domyślnie
Google dużo zainwestował w bezpieczeństwo IT i, myślę, że wykonał przyzwoitą robotę. Wszystkie usługi są domyślnie TLS, tożsamość i autoryzacja są dobrze rozwiązane.
DNSSEC i Google’S Public DNS Service
System nazwy domeny lub DNS jest krytycznym, ale niewidocznym elementem Internetu. Świat Internetu to świat symboli i słów. Wzywamy aplikacje do interakcji z usługami takimi jak Google, Facebook i Twitter, a interakcja jest sformułowana w czytelnych symboli ludzkich. Ale interakcja z siecią jest taka, która jest całkowicie w formacie binarnym. Tak więc nasz symboliczny pogląd na usługę, taki jak www.Google.com, należy przetłumaczyć na adres protokołu, taki jak 74.125.237.144. Mapowanie z symboli na adresy protokołu jest jedną z kluczowych funkcji DNS. Polegamy nie tylko na dalszej obecności DNS, ale także jego prawidłowe działanie. Wchodzenie do mybank.com.AU w przeglądarce niekoniecznie gwarantuje, że Twoja interakcja będzie z twoją przeznaczoną usługą. Jednym z bardziej podstępnych wektorów ataku dla Internetu jest celowe uszkodzenie działania DNS, a tym samym oszustwo aplikacji użytkownika, aby otworzyć sesję z niewłaściwym miejscem docelowym. Najbardziej solidną odpowiedzią, jaką udało nam się opracować, aby złagodzić tę wieloletnią podatność w DNS, było dodanie bezpiecznych podpisów kryptograficznych do DNS, przy użyciu technologii o nazwie DNSSEC. Ale czy używamy DNSSEC w dzisiejszych czasach’S Internet?
Historia DNSSEC ma silne podobieństwa do historii IPv6. Podobnie jak IPv6, DNSSEC istnieje już od wielu lat, ale ma to lekkie. Podobnie jak IPv6, DNSSEC jest najbardziej skuteczny, gdy wszyscy go używają, a marginalne zwroty z fragmentarycznej adopcji są bardzo niskie. I podobnie jak IPv6, stosunkowo niski poziom wdrażania i stosowania DNSSEC nie odzwierciedla długotrwałych wysiłków w celu podniesienia widoczności technologii i wspólnych wysiłków w celu opublikowania wyraźnych długoterminowych korzyści w korzystaniu z tej technologii.
Nawet gdy podstępne niebezpieczeństwa związane z atakiem na integralność DNS i powszechnie używaną infrastrukturę certyfikatu nazwy domeny zostały wyraźnie wykazane w incydencie Digiinotar w 2011 r., Potencjalne korzyści z użycia DNSSEC i przyjęcie bezpiecznego powiązania nazwy domeny z adresem IP na adres IP za pośrednictwem cyfrowych poświadczeń umieszczonych w bezpiecznych ramach DNS nie powiodło się. W pewnym sensie istnieje forma wzajemnego impasu: podczas gdy tak niewielu klientów używa DNSSEC, wydaje się, że nie ma motywacji dla administratorów nazwy domeny do używania DNSSEC do podpisywania nazw domen. I chociaż jest tak mało podpisanych nazw domen, niewiele jest motywacji do wdrażania narzędzi klienta do włączenia sprawdzania poprawności DNSSEC do rozdzielczości DNS. I chociaż nazwy domeny są w dużej mierze niepodpisane, a więc niewielu klientów używa DNSSEC do walidacji wyników rozdzielczości nazw DNS, nie ma motywacji dla administratorów nazwy domeny lub autorów przeglądarki do użycia technologii Dane do zapewnienia bezpiecznej formy mapowania z nazwy domeny na adres IP i klucz publiczny TLS TLS i klucz publiczny TLS TLS.
Czy możemy określić ilościowo zakres, w jakim DNSSEC został wdrożony i użyty dzisiaj’S Internet? Jednym ze sposobów jest zmierzenie zakresu, w jakim nazwy domeny są podpisywane za pomocą podpisów DNSSEC. Usługi takie jak SecSpider śledzą postęp podpisywania domeny w różnych strefach DNS na najwyższym poziomie i drugim poziomie, zliczając liczbę nazw domen zawierających poświadczenia DNSSEC. Ale druga połowa pytania jest również istotna. W jakim stopniu aplikacje użytkowników końcowych używają rozdzielczości DNS, które wykonują sprawdzanie poprawności DNSSEC podczas rozwiązywania nazwy? I, co najważniejsze, w jakim stopniu aplikacje użytkowników końcowych powstrzymają się od używania wyniku rozdzielczości nazwy DNS, jeśli nazwa domeny jest podpisana DNSSEC, a powiązana walidacja podpisu DNSSEC nie powiada się?
W laboratoriach bez’Patrzyłem na to drugie pytanie, próbując oszacować stopień, w jakim klienci używają sprawdzania poprawności DNSSEC w połączeniu z rozdzielczością nazwiska. Nasze początkowe wysiłki zostały podjęte w październiku i listopadzie 2012 r. Pierwsze ćwiczenie pomiarowe w październiku 2012 r. Wskazano na około 9% klientów, którzy wydawali się korzystać z rozdzielczości DNS, które wykonują jakąś formę walidacji DNSSEC. Ponowne uruchomienie eksperymentu w listopadzie 2012 r. Zapewniło wynik, że około 1.6% klientów, którzy wydawali się korzystać wyłącznie z rozdzielczości DNS, które konsekwentnie wykonywały walidację DNSSEC.
Żadne z tych wyników nie było tak satysfakcjonujące, a przyczyną tego poziomu niepokoju z wynikami była próba uwzględnienia skutków buforowania DNS Resitver w wynikach eksperymentu. W obu tych eksperymentach wykorzystaliśmy internetową kampanię reklamową, aby zapisać miliony klientów końcowych do wykonania kolekcji obiektów do odzyskania, aw obu przypadkach użyliśmy dzikich cardów w DNS i dynamicznej generowania unikalnych etykiet DNS, aby zaprezentować każdemu klientowi zestaw unikalnych nazw DNS w celu rozwiązania. Jednak ujawniona osłabienie tego podejścia, o ile pojedynczy łańcuch podpisu DNSSEC był podzielony w całym eksperymencie. Oznaczało to, że po tym, jak DNS Resistver odzyskał rekordy zasobów DNSSEC (RRS) dla nazw DNS eksperymentu (DNSKEY i DS RRs podpisanej strefy zawierającej wpis Wildcard), który zapewnił wszystkie kolejne rekordy DNSSEC RR. Biorąc pod uwagę, że naszym punktem obserwacji eksperymentu był dziennik zapytania DNS na autorytatywnym serwerze nazw, byliśmy zmuszeni wnioskować o możliwościach DNSSEC każdego z widocznych rozdzielczości DNS w oparciu o sekwencję zapytania DNS, jak widać na autorytatywnym serwerze nazw oraz terminów między zapytaniami. Eksperymenty te wykazały przybliżoną górną granicę około 9% klientów korzystających z rozdzielczości walidacji DNSSEC przy użyciu raczej liberalnego testu do walidacji DNSSEC i przybliżonej dolnej granicy 1.6% klientów, którzy używali DNSSEC walidacja rozdzielczości przy użyciu znacznie surowszego zestawu ograniczeń reguł wnioskowania. Oczywiście jesteśmy zainteresowani zmniejszeniem niepewności tych pomiarów, jeśli możemy.
Przeglądając poprzednie eksperymenty, zauważyliśmy, że jednym ze sposobów usunięcia potrzeby wnioskowania o zachowanie rozwiązywania DNS było użycie konfiguracji DNS, która usunęła jak najwięcej. Zamiast używać prostej karty wieloznacznej we wspólnej domenie podpisanej przez DNSSEC, gdybyśmy mogli zaprezentować każdemu klientowi unikalną domenę podpisaną przez DNSSEC, wówczas unikalna etykieta zmusiłaby dowolne rozstrzyganie do walizacji DNSSEC do odzyskania RR DNSSEC z autorytatywnego serwera nazwisk dla tej unikalnej strefy DNS. Innymi słowy, jeśli rozstrzygający klienta wykonywał sprawdzanie poprawności DNSSEC, autorytatywny serwer nazw nie tylko otrzymałby zapytania dotyczące adresu domeny, ale także otrzymał zapytania DNSKEY i DS w ramach fazy sprawdzania poprawności DNSSEC. Takie podejście pozwoliłoby nam z większym poziomem dokładności, ile klientów używał DNSSEC do weryfikacji nazw DNS. Ta struktura nazwy DNS pokazano na rycinie 1.
Rysunek 1: Struktura nazwy domeny używana do pomiaru zachowania sprawdzania poprawności DNSSEC
Prowadziliśmy tę wersję eksperymentu pomiarowego DNSSEC od 8 do 18 marca 2013 r.
19 marca Google ogłosił, że ich publiczne rozstrzygnięcia DNS poparli walidację DNSSEC. W swoim ogłoszeniu Google poinformował, że:
“Obecnie Google Public DNS obsługuje średnio ponad 130 miliardów zapytań DNS (osiągając 150 miliardów) z ponad 70 milionów unikalnych adresów IP każdego dnia. Jednak tylko 7% zapytań po stronie klienta jest obsługujących DNSSEC (około 3% żądania sprawdzania poprawności i 4% żądania danych DNSSEC, ale nie ma weryfikacji), a około 1% odpowiedzi DNS od strony serwera jest podpisanych.”
To ogłoszenie wydawało się stanowić idealną okazję dla “przed i po” Ćwiczenie, wykonując ćwiczenie pomiarowe DNSSEC w okresie bezpośrednio po Google’pozorne przejście do swoich rozdzielczych w celu wykonania sprawdzania poprawności DNSSEC. Jaki wpływ miałby ten przełącznik na ogólny obraz klientów wykonujących walidację DNSSEC? Ponownie zawarliśmy ten sam eksperyment od 22 marca do 1 kwietnia 2013 r’S serwery publiczne DNS zmieniły ogólny obraz klientów korzystających z walidacji DNSSEC.
W tej chwili Google nie włączyło bezwarunkowo DNSSEC. Cytuj z dodatkowych materiałów opublikowanych przez Google:
Czy Google Public DNS popiera protokół DNSSEC?
Tak. Google Public DNS to potwierdzający, świadomy bezpieczeństwa. Obecnie jest to funkcja opt-in: w przypadku zapytań pochodzących od klientów żądających walidacji (ustawiona jest flaga reklamy i/lub flaga), Google Public DNS weryfikuje, że rekordy odpowiedzi są poprawnie uwierzytelnione. Walidacja domyślnie (i.mi. W przypadku wszystkich pytań) zostanie wkrótce włączone.
Które rozwiązania klientów włączają obecnie DNSSEC?
Niestety, większość standardowych rozdzielczości odcinka klientów nie włącza pełnego sprawdzania DNSSEC i nie można go łatwo zrekonfigurować. Zdecydowaliśmy się, że nasza początkowa uruchomienie pokrywa tylko rozwiązania, które wyraźnie proszą o sprawdzenie DNSSEC, abyśmy stali się świadomi wszelkich problemów, zanim wystawiliśmy naszych użytkowników na możliwe awarie DNS na dużą skalę z powodu błędnych konfiguracji DNSSEC lub przerwy. Kiedy jesteśmy szczęśliwi, że możemy bezpiecznie włączyć DNSSEC dla wszystkich użytkowników, z wyjątkiem tych, którzy wyraźnie zrezygnujemy, zrobimy to.
Implikacja polega na tym, że obecnie, jeśli zapytanie klienta DNS nie zażąda sprawdzania poprawności DNSSEC, wówczas Google Public DNS zwróci wynik bez wykonywania żadnej formy walidacji DNSSEC odpowiedzi odpowiedzi. Materiał Google wskazuje, że żądanie sprawdzania poprawności DNSSEC jest oznaczone zapytaniem DNS z zestawem reklamy lub flagi do.
Jakie są te flagi zapytania DNS?
Flagi zapytania DNSSEC i DNS
Protokół DNS, zgodnie z definicją RFC 1034 i RFC 1035, nie zawierał żadnego konkretnego przepisu walidacji odpowiedzi DNS. Protokół to prosty protokół zapytania/odpowiedzi. Klient generuje zapytanie DNS składające się z zakończonego nagłówka i sekcji zapytania, a odpowiedź zawiera te same sekcje nagłówka i zapytania wraz z odpowiedziami, autorytetem i dodatkowymi sekcjami.
DNSSEC jest kompatybilnym wstecznym rozszerzeniem protokołu DNS, zdefiniowanego w RFCS RFC 4033, RFC 4034, RFC 4035, RFC 5155 i RFC 6840. W zapytaniu DNS są trzy flagi, które zawierają wyraźne instrukcje DNSSEC dla rozdzielonego.
Flaga Do
Pierwszy jest częścią rozszerzonych mechanizmów DNS (EDNS0), zdefiniowanych w RFC 2671. Jeśli DNSSEC OK (DO) Bit jest ustawiony w zapytaniu, a następnie interpretuje to jako sygnał, że odpowiedź powinna zawierać dane DNSSEC w swojej odpowiedzi. Jeśli odpowiedź jest rekordem zasobów ze strefy podpisanej przez DNSSEC, odpowiedź powinna zawierać podpis rekordu zasobów (RRSIG RR) w oprócz odpowiedzi rekordu zasobów. Jeśli nie ma takiej domeny, odpowiedź powinna obejmować NSEC lub NSEC3 RR w swojej odpowiedzi.
Flaga CD
Druga to flaga sprawdzania (CD). Jeśli ta flaga jest ustawiona w zapytaniu, rozdzielcz powinien zwrócić żądane informacje, w tym rekordy RRSIG, jeśli flaga DO jest ustawiona, ale nie powinna próbować weryfikacji podpisów zawarty. Ustawiając bit CD w zapytaniu, rdzenna rozdzielczy wskazuje, że bierze odpowiedzialność za wykonanie uwierzytelniania odpowiedzi i że zapytany serwer z rekurencyjnymi serwerami nie powinien zakłócać tej funkcji.
Flaga reklamowa
Ostatnią flagą jest flaga Uwierzytelniona (AD). Ta flaga ma nieco niejasne znaczenie. Do początku 2013 r. Dokument standardów był RFC4035:
4.6. Obsługa bitów CD i reklam
& nbs [;
Rozdzielcz ds. Uważania bezpieczeństwa musi wyczyścić bit reklamy podczas komponowania komunikatów zapytania, aby chronić przed serwerami nazwy buggy, które ślepo kopiują bity nagłówka, których nie rozumieją od wiadomości zapytania do wiadomości odpowiedzi.
W lutym 2013 r. Opublikowano RFC6840, z następującą Refinicją Bit AD:
5.7. Ustawienie bitu reklamy na zapytaniach
Semantyka bitu autentycznych danych (AD) w zapytaniu była wcześniej niezdefiniowana. Sekcja 4.6 z [RFC4035] poinstruował Resicvers, aby zawsze wyczyścili bit reklamy podczas komponowania zapytań.
Ten dokument określa ustawienie bitu reklamy w zapytaniu jako sygnału wskazującym, że wnioskodawca rozumie i jest zainteresowany wartością bitu reklamy w odpowiedzi. Pozwala to żądnikowi wskazać, że rozumie bit reklamy bez żądania danych DNSSEC za pośrednictwem bit
5.8. Ustawienie bitu reklamy na odpowiedzi
Sekcja 3.2.3 z [RFC4035] opisuje, w których warunkach powinien ustalić lub wyczyścić bit AD w odpowiedzi. Aby współpracować z starszymi rozdzielczymi odcinkami i skrzynkami środkowymi, które ani nie rozumieją, ani ignorują bitu AD, walidacja rozdzielczości powinna ustawić bit reklamy tylko wtedy, gdy odpowiedź spełnia warunki wymienione w rozdziale 3.2.3 [RFC4035], a żądanie zawierało zestaw zestawu lub zestawu reklamowego.
Połączone ustawienia flagi
Wpływ różnych ustawień flagi kombinacji w zapytaniach wysyłanych do rozdzielczych pokazano w poniższej tabeli.
Czy Efekt CD AD 0 0 0 Resolver może, ale nie musi wykonywać sprawdzania poprawności DNSSEC. Żadne DNSSEC RRS nie są przekazywane w odpowiedzi. 0 0 1 Resolver powinien wykonać sprawdzanie poprawności. Żadne RR DNSSEC nie są przekazywane w odpowiedzi 0 1 0. Żadne DNSSEC RRS nie są przekazywane w odpowiedzi 0 1 1 Sygnały mieszane! Działania Resolver są niezdefiniowane. 1 0 0 RESPIVER powinien wykonać sprawdzanie poprawności i zwrócić DNSSEC RRS w swojej odpowiedzi 1 0 1 Resyver powinien wykonać sprawdzanie poprawności, a zwrócić RRS DNSSEC w swojej odpowiedzi 1 1 0 Nie powinien wykonywać sprawdzania poprawności DNSSEC, ale powinien zwrócić RR DNSSEC w swojej odpowiedzi 1 1 1 mieszane sygnały mieszane! Działania Resolver są niezdefiniowane.
Tabela 1: Ustawienia flagi DNSSEC w zapytaniach DNS
Należy zauważyć, że gdy determinacja nie ma na celu nie wykonywania sprawdzania poprawności DNSSEC, wówczas rozwiązanie powinno odpowiedzieć na żądane rekordy zasobów, nawet w przypadku, że rekordy zasobów są podpisane DNSSEC, a podpis jest nieprawidłowy.
Zachowanie DNS Resolver i DNSSEC
Najprostszy model rozdzielczości DNS z udziałem klienta, DNS Resolver i zbiór autorytatywnych serwerów nazw, jak pokazano na rycinie 2.
Rysunek 2 – Prosty model rozdzielczości DNS dla nazwy domeny “X.y.z”
Gdy klient pyta jego DNS Resoluver w celu rozwiązania nazwy domeny, na przykład x.y.Z, następnie DNS Resolver, zakładając, że ma wyczyszczony stan pamięci podręcznej, najpierw wyśle to zapytanie do serwera nazwy głównej. Serwer odpowiedziałby zestawem autorytatywnych serwerów nazwisk dla domeny najwyższego poziomu Z.. DNS Resolver wyśle następnie to samo zapytanie do jednego z tych serwerów nazw z Z., które odpowiedziałyby serwerami nazw dla domeny y.z.. DNS Resolver będzie następnie zapytał jeden z tych serwerów nazwy dla nazwy DNS x.y.z., a następnie przekazuje odpowiedź, którą otrzyma z powrotem klientowi. Sekwencja zapytań DNS wysyłanych przez tego DNS Resister po otrzymaniu początkowego zapytania od klienta byłaby następująca:
# Odpowiedź serwera nazwy RR RR 1. A x.y.z. . Ns dla „z."2. A x.y.z. z. Ns dla „y.z."3. A x.y.z. y.z. A dla "x.y.z."
Rysunek 3 – Zapytania DNS bez walidacji DNSSEC
Co się stanie, jeśli ten DNS Resistver był DNSSEC weryfikującym rozdzielczość? Obejmowałoby to dodatkowe zapytania DNS, ponieważ DNS Resolver musi potwierdzić rekord RRSIG dla rekordu pobieranego zasobu. Ta walidacja obejmuje “tylny ślad” W górę hierarchii delegacji DNS, po łańcuchu DNSKEY i DS RRS, dopóki nie osiągnie punktu powierniczego, który w tym przypadku jest kluczem podpisującym strefę korzeniową. Równoważny zestaw zapytań DNS dla DNSSEC walidacja rozdzielczości, po otrzymaniu początkowego zapytania od klienta, byłby następujący:
# Odpowiedź serwera nazwy RR RR 1. EDC x.y.z. . Ns dla „z.„ + RRSIG 2. EDC x.y.z. z. Ns dla „y.z." + RRSIG 3. EDC x.y.z. y.z. A dla x.y.z. + RRSIG 4. Dnskey edc y.z. y.x dnskey dla strefy „y.Z " + RRSIG 5. Ds edc y.z. z. Ds dla strefy „y.Z " + RRSIG 6. Dnskey ecd z. z. Dnskey dla strefy „z.„ + RRSIG 7. Ds edc z. . DS dla strefy „z." + RRSIG 8. Dnskey EDC . . Dnskey dla strefy ".A"
Rysunek 4 – Zapytania DNS z walidacją DNSSEC
Początkowe 3 zapytania są podobne, ale teraz zapytania emitowane przez ten walidujący DNSSEC DNS Resolver obejmuje EDNS0 (mi) rozszerzenie i DNSSEC OK (D) i sprawdzanie wyłączone (C) Flagi. W każdym przypadku DO sygnały flagowe, że odpowiedzi z autorytatywnych serwerów mają uwzględnić RRSIG RRS, jeśli strefy są rzeczywiście podpisane.
Gdybyśmy spojrzeli na transakcje na autorytatywnym serwerze dla strefy Y.z. Zobaczymy zapytanie, a następnie zapytanie DNSKEY. Gdybyśmy spojrzeli na transakcje na autorytatywnym serwerze dla strefy nadrzędnej Z., Byłoby zapytanie, a następnie zapytanie DS i zapytanie DNSKEY. A jeśli mielibyśmy użyć tego samego autorytatywnego serwera nazw dla obu Z. i x.z. Wtedy ten serwer z nazwiskiem zobaczyłby zapytanie dla x.y.z., a następnie zapytania DNSKEY i DS za y.z.
Z tego przykładu wydawałoby się możliwe do kategoryzacji rozdzielczości DNS w doleceniu DNSSEC i niekwalifikującym rozdzielczości w oparciu o obserwację zapytań DNSKEY i DS na autorytatywnym serwerze nazwy serwera. Jeśli zaobserwujemy zapytania jak na rycinie 3, to rozdzielczy DNS jest niekwalifikującym rozwiązaniem, a jeśli są jak na rycinie 4, wówczas rozdzielcz. Niestety ta prosta forma Kategoryzacja nie jest możliwa, ponieważ obraz rozdzielczości DNS może być znacznie bardziej złożony niż prosty obraz z rysunku 2.
DNS Resolver można skonfigurować do używania “spedytor”. W takim przypadku DNS Resolver nie będzie zapytał bezpośrednio o autorytatywne serwery nazw, ale kierują swoje zapytania za pośrednictwem innego DNS Resolver. Zaletą użycia napastnika jest wykorzystanie wydajności buforowania wyników DNS. Warianty tej konfiguracji rozdzielczości umożliwiają ograniczenie funkcji przekazywania do rozdzielczości określonych stref DNS, a nie stosować ją do wszystkich zapytań. Resolver można również skonfigurować, aby powrócić do rozdzielczości rekurencyjnej, jeśli napastnicy nie udzielają odpowiedzi. Istnieje również “Farmy Resolver” W DNS, gdzie pojedynczy logiczny napastnik może zaakceptować zapytania DNS, ale następnie użyć kolekcji niewolników DNS, aby podejmować zapytania. Wyidealizowany obraz rozdzielczości DNS na ryc. 2 powinien być nieco rozszerzony, aby zilustrować poziom potencjalnej złożoności związanej z rozdzielczością DNS. Rysunek 5 pokazuje niektóre możliwe konfiguracje.
Rysunek 5 – Niektóre struktury rozdzielczości DNS z napastnikami
W kontekście eksperymentu, który tutaj podejmujemy, oprzyrządowaliśmy tylko autorytatywny serwer nazw i widzimy tylko zapytania DNS przesłane przez”widoczny” DNS Resistni na tym serwerze. Zatem pod względem bezpośrednio widocznych rozdzielczości widok infrastruktury rozdzielczości DNS jest bliższy temu, jak pokazano na rycinie 6. Tutaj wewnętrzna struktura napastników DNS jest skutecznie zamknięta z autorytatywnego serwera nazw, a serwer może zobaczyć tylko te zdecydowane, które przekazują do niego zapytania.
Rysunek 6 – Struktury rozdzielczości DNS
Implikacja polega na tym, że chociaż to eksperymentalne podejście może zapewnić dobry obraz zdolności walidacji DNSSEC klientów, wymaga pewnego poziomu wnioskowania i związanego z tym poziomu niepewności reguł wnioskowania, aby wnioskować o zachowaniu walidacji DNSSEC w rozdzielczości DNS. Na przykład, jeśli wydzielony przez DNSEC wykorzystywany przez DNSEC używa niekwalifikującego napastnika, wówczas autorytatywny serwer nazw zobaczy sekwencję zapytań z przodnika z zestawem flag DO i CD, które są zgodne z sprawdzaniem poprawności DNSSEC. Jeśli nie-DNSSEC wykorzystywał się do przekazania DNSSEC, walidujący rozdzielcz.
Eksperyment pomiarowy DNSSEC
W tym eksperymencie obiekt Flash Adobe jest osadzony w reklamie online. Kod jest wykonywany po prezentacji reklamy i nie wymaga od użytkownika kliknięcia wrażenia reklam.
Kod powoduje, że klient odzyskuje obiekt z kontrolera eksperymentu, który zasila klienta 4 URL, aby pobrać. Pierwsze trzy adresy URL mają zostać natychmiast pobrane, podczas gdy czwarty adres URL ma zostać pobrany po pobraniu pierwszych trzech obiektów lub po wygaśnięciu 10 -sekundowego timera, w zależności od tego, co nastąpi pierwsze. Wszystkie te adresy URL zawierają unikalną etykietę DNS. Przykładowy zestaw czterech adresów URL pokazano poniżej. Generator adresu URL generuje zestaw unikalnych wartości dla każdego eksperymentu. Te unikalne pola są podświetlone w kolorze.
D http: // d.U7280280162.S1364784185.V6022.69DA1.z.Dotnxdomain.Net/1x1.png?D.U7280280162.S1364784185.V6022.69DA1.z.Dotnxdomain.internet mi http: // e.U7280280162.S1364784185V6022.69DA1.z.dashnxdomain.Net/1x1.png?mi.U7280280162.S1364784185.V6022.69DA1.z.dashnxdomain.internet F http: // f.U7280280162.S1364784185.V6022.69DA2.z.Dotnxdomain.Net/1x1.png?F.U7280280162.S1364784185.V6022.69DA2.z.Dotnxdomain.internet wynik http: // wyniki.U7280280162.S1364784185.V6022.69DA1.X.skraj.ANPNIC.Net/1x1.png?wyniki.U7280280162.S1364784185.i767.V6022.69DA1& r =
Jak pokazano w powyższym przykładzie, trzy adresy URL mają etykietę Heksadecimal DNS, “69DA1 ″ w tym przypadku, podczas gdy drugi adres URL zawiera etykietę, która jest jedna większa wartość, “69DA2” W tym przypadku. Pierwszy adres URL, począwszy od etykiety D, wykorzystuje kombinację rekordu wieloznacznego i domeny podpisanej przez DNSSEC. W takim przypadku podpis DNSSEC rekord zasobów jest ważny. Drugi adres URL, począwszy od etykiety E, używa tej samej kombinacji, ale w tym przypadku domena nie jest podpisana. Trzeci adres URL, począwszy od etykiety F, wykorzystuje również kombinację domeny wieloznacznej i domeny podpisanej przez DNSSEC. Jednak w tym przypadku podpis DNSSEC jest nieprawidłowy, o ile rekord DS dla strefy 69DA2.z.Dotnxdomain.Net nie pasuje do odpowiednich rekordów DNSKEY. Wyniki URL nie jest podpisane DNSSEC. Kolejność prezentacji adresów URL w skrypcie jest ustalona jako sekwencja z końcowym adresem URL opóźnionym przez 10 sekund lub udane pobieranie pierwszych trzech adresów URL, w zależności od tego, co nastąpi pierwsze. Klient jest poinstruowany, aby rozpocząć liczniki liczby URL D, E i.
Naszym zamiarem było zapewnienie, że każdy klient został przedstawiony z wyjątkowo podpisaną etykietą DNS, zapewniając, że nie ma stanu buforowanego w żadnym DNS lub na żadnym serwerze serwera serwera internetowego. Wynikiem tego jest to, że każdy eksperyment powoduje zestaw transakcji DNS i HTTP z autorytatywnymi serwerami DNS i serwerami internetowymi dla tych nazw domen.
Eksperyment używa pojedynczego serwera, który zawiera zarówno serwer nazw DNS (Uruchamianie BIND 9.9.2-p1) i serwer WWW (uruchomiony apache v2.2.23). Ten serwer jest jedynym autorytatywnym serwerem nazw dla domen używanych w tych czterech adresach URL i punktem RRS tylko dla tego serwera. W tym eksperymencie celowo skonfigurowaliśmy cały eksperyment za pomocą IPv4, pozostawiając badanie IPv6 i DNSSEC na inne eksperymenty.
Podczas gdy możliwości walidacji DNSSEC poszczególnych rozdzielczości DNS są nieco trudne do wnioskowania z tej formy eksperymentu, cofamy się o krok i postawiamy pytanie, czy użytkownik końcowy używa sprawdzania poprawności DNSSEC za pośrednictwem skonfigurowanych rozdzielczych DNS, wówczas można to wywnioskować z dziennika Queries i HTTP Fetches na wspólnym serwerze. Przykład wyciągu z dzienników DNS i HTTP z serwera, odnoszący się do jednego eksperymentu (U5158122700.S1364428847 w tym przypadku) pokazano poniżej.
Zapytanie serwera DNS -ID w E.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.netto DNS -ed w f.U5158122700.S1364428847.V6022.5E3C0.z.Dotnxdomain.netto DNS -one w a.U5158122700.S1364428847.V6022.5e3bf.z.Dotnxdomain.netto http get/crossdomain.xml e.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.Net HTTP GET /1x1.png e.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.netto http get /crossdomain.xml d.U5158122700.S1364428847.V6022.5e3bf.z.Dotnxdomain.Net HTTP GET /1x1.png d.U5158122700.S1364428847.V6022.5e3bf.z.Dotnxdomain.netto http get /crossdomain.xml f.U5158122700.S1364428847.V6022.5E3C0.z.Dotnxdomain.Net HTTP GET /1x1.png f.U5158122700.S1364428847.V6022.5E3C0.z.Dotnxdomain.DNS netto -w wynikach.U5158122700.S1364428847.V6022.5e3bf.X.skraj.ANPNIC.netto http get /crossdomain.Wyniki XML.U5158122700.S1364428847.V6022.5e3bf.X.skraj.ANPNIC.Net HTTP GET /1x1.png?wyniki.U5158122700.S1364428847.i767.V6022.5e3bf i r = ZD-1923.ZE-1578.ZF-1578
Rysunek 7 – Dzienniki serwera z eksperymentu, który nie wykonał sprawdzania poprawności DNSSEC
Ten eksperyment wygenerował 4 zapytania DNS i 8 zapytań HTTP. Wszystkie zapytania DNS wykorzystały flagę DNSSEC OK (do)“-Wyd” W dzienniku wskazuje, że rozdzielczość rekurencyjna zapytania została wyłączona (-), zastosowano EDNS0 (E), a rekordów zasobów podpisu DNSSEC zostały wymagane, jeśli dostępne (D)). Jednak DNS Resolver prosi o RRS, ale nie prosi o DNSKEY lub DS RRS. Wygląda na to, że chociaż Resistver ustawił flagę DNSSEC OK, nie wykonuje żadnej formy sprawdzania poprawności DNSSEC na wartości zwróconej w RRSIG RRS.
Klient odzyskał wszystkie trzy (D, E i F) URL. Biorąc pod uwagę, że URL F ma nieprawidłowy podpis DNSSEC, to potwierdza to, że rozstrzyganie DNS używane przez tego klienta nie wykonuje żadnej walidacji DNSSEC. Linia wyników obejmuje również wynik licznika czasu klienta, a klient informuje, że eksperyment D wziął klienta 1 923 ms, E wziął 1 578 ms, a F wziął 1 578 ms. Nieco dłuższy czas na wykonanie pobierania URL D w porównaniu do pobierania URL może wynikać z buforowania rozdzielczości Z rozdzielczości Z.Dotnxdomain.net podczas rozwiązywania adresu URL D i używając wartości buforowanych podczas rozwiązywania adresu URL.
Natomiast następujące wyciąg z tych samych dzienników, które pokazują zapytania DNS otrzymane przez autorytatywny serwer z DNS, który wydaje się wykonywać sprawdzanie poprawności DNSSEC.
Zapytanie serwera DNS A -EDC w A D.U94278337.S1364428957.V6022.5E4E3.z.Dotnxdomain.netto dns a -Edc w e.U94278337.S1364428957.V6022.5E4E3.z.dashnxdomain.netto dns a -Edc w DNSKEY 5E4E3.z.Dotnxdomain.netto dns a -Edc w ds 5e4e3.z.Dotnxdomain.netto dns a -Edc w f.U94278337.S1364428957.V6022.5E4E4.z.Dotnxdomain.netto dns a -Edc w DNSKEY 5E4E4.z.Dotnxdomain.netto DNS -EDC w DS 5E4E4.z.Dotnxdomain.netto dns b -Edc w f.U94278337.S1364428957.V6022.5E4E3.z.Dotnxdomain.netto DNS B -EDC w DNSKEY 5E4E4.z.Dotnxdomain.netto DNS B -EDC w DS 5E4E4.z.Dotnxdomain.netto http get /crossdomain.xml d.U94278337.S1364428957.V6022.5E4E3.z.Dotnxdomain.Net HTTP GET /1x1.png d.U94278337.S1364428957.V6022.5E4E3.z.Dotnxdomain.netto http get /crossdomain.xml e.U94278337.S1364428957.V6022.5E4E3.z.dashnxdomain.Net HTTP GET /1x1.png e.U94278337.S1364428957.V6022.5E4E3.z.dashnxdomain.netto dns a -Edc w wynikach.U94278337.S1364428957.V6022.5E4E3.X.skraj.ANPNIC.netto http get /crossdomain.Wyniki XML.U94278337.S1364428957.V6022.5E4E3.X.skraj.ANPNIC.Net HTTP GET /1x1.png?wyniki.U94278337.S1364428957.i767.V6022.5e4e3 i r = ZD-1572.ZE-1269.zf-null
Rysunek 8 – Dzienniki serwera z eksperymentu, który przeprowadził sprawdzanie poprawności DNSSEC
W takim przypadku klient odzyskał dwa adresy URL (D i E) i nie odzyskał adresu URL powiązanego z nazwą domeny F, która nie powiodła się.
DNS Resolver wykonuje walidację DNSSEC, o czym świadczy pobrać DNSKEY i DS RRS dla stref domeny D i F. Pierwsza rozdzielczość DNS dla nazwy domeny F nie powiodła się walidacja DNSSEC, a klient wydaje się otrzymywać odpowiedź serwera. Klient następnie wypróbował swój drugi skonfigurowany rozdzielczy, który wykonuje również sprawdzanie poprawności DNSSEC. Na tym etapie klient zrezygnował z próby rozwiązania nazwy domeny F. Po wygaśnięciu 10 -sekundowego timera klient pobrał URL wyników. Linia wyników obejmuje również wynik licznika czasu klienta, a klient informuje, że DRL D zajął klienta 1572 ms, E wziął 1 269 ms, a F nie został odzyskany. Nieco dłuższy czas na wykonanie D Fetch w porównaniu z E Fetch może być częściowo wynikający z odzyskania RRS DNSKEY i DS dla domeny D, a powiązana operacja walidacji DNSEC, która została wykonana przez walidację rozdzielczości, ponieważ klient nie otrzymałby wyniku zapytania D DNS do i dodatkowej walidacji DNSEC.
Celem tego eksperymentu jest wypróbowanie dużego losowego zestawu klientów z całego Internetu i skłonienie ich przeglądarki do przeprowadzenia tego eksperymentu. Jeśli zestaw transakcji na serwerze przypomina pierwszy zestaw transakcji pokazanych powyżej, możemy zakończyć, a klient nie używa DNSSEC, podczas gdy zestaw transakcji przypomina drugi zestaw powyżej, wówczas klient używa rozdzielczości DNS, które wykonują sprawdzanie poprawności DNSSEC w celu ochrony funkcji rozdzielczości nazwy.
W tej eksperymentalnej konfiguracji jedynym dostępnym komponentem, który możemy wyposażyć w oprzyrządowanie, jest autorytatywny serwer dla domeny “Dotnxdomain.internet.”. Gdyby DNS Resolver nie wykonywał sprawdzania poprawności DNSSEC, spodziewalibyśmy się pojedynczego zapytania dla RR wykonanego dla autorytatywnego serwera, podczas gdy DNS Resicver był DNSSEC Residating, wówczas spodziewalibyśmy się zapytania A RR, a następnie zapytanie DNSKEY i DS DS.
I to jest widziane. Poniższe zapytania zostały zarejestrowane przez autorytatywny serwer nazw z niekwalifikującego się DNS Resitver:
22-mar-2013 01:46:34.209 10.0.0.1#59296: Zapytanie: E.U3435434437.S1363916793.V6022.58CB7.z.dashnxdomain.netto w -ed 22-mar-2013 01:46:34.311 10.0.0.1#57571: Zapytanie: D.U3435434437.S1363916793.V6022.58CB7.z.Dotnxdomain.netto w -ed 22-mar-2013 01:46:34.245 10.0.0.1#6322e: zapytanie: F.U3435434437.S1363916793.V6022.58CB8.z.Dotnxdomain.net w -ed
Poniższe zapytania zostały zarejestrowane przez autorytatywnego serwera nazw z zestawu rozdzielczości DNS, które wydają się wykonywać sprawdzanie poprawności DNSSEC:
22-mar-2013 01:40:48.029 10.0.0.2#17283 Zapytanie: D.U2867716218.S1363916447.V6022.58721.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.038 10.0.0.2#22572 Zapytanie: 58721.z.Dotnxdomain.netto w DS -ED 22-mar-2013 01:40:48.056 10.0.0.2#54384 Zapytanie: 58721.z.Dotnxdomain.netto w dnskey -ed 22-mar-2013 01:40:48.229 10.0.0.3#18024 Zapytanie: E.U2867716218.S1363916447.V6022.58721.z.dashnxdomain.netto w -ed 22-mar-2013 01:40:48.024 10.0.0.4#19869 Zapytanie: F.U2867716218.S1363916447.V6022.58722.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.032 10.0.0.4#52521 Zapytanie: 58722.z.Dotnxdomain.netto w DS -ED 22-mar-2013 01:40:48.049 10.0.0.4#35302 Zapytanie: 58722.z.Dotnxdomain.netto w dnskey -ed 22-mar-2013 01:40:48.084 10.0.0.5#44543 Zapytanie: F.U2867716218.S1363916447.V6022.58722.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.092 10.0.0.5#46424 Zapytanie: 58722.z.Dotnxdomain.netto w DS -ED 22-mar-2013 01:40:48.109 10.0.0.5#17802 Zapytanie: 58722.z.Dotnxdomain.netto w dnskey -ed 22-mar-2013 01:40:48.139 10.0.0.6#24334 Zapytanie: F.U2867716218.S1363916447.V6022.58722.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.147 10.0.0.6#18014 Zapytanie: 58722.z.Dotnxdomain.netto w DS -ED 22-mar-2013 01:40:48.164 10.0.0.6#43916 Zapytanie: 58722.z.Dotnxdomain.netto w dnskey -ed 22-mar-2013 01:40:48.197 10.0.0.6#51221 Zapytanie: F.U2867716218.S1363916447.V6022.58722.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.230 10.0.0.7#58295 Zapytanie: F.U2867716218.S1363916447.V6022.58722.z.Dotnxdomain.netto w -ed 22-mar-2013 01:40:48.239 10.0.0.7#34658 Zapytanie: 58722.z.Dotnxdomain.netto w DS -ED 22-mar-2013 01:40:48.255 10.0.0.7#31055 Zapytanie: 58722.z.Dotnxdomain.net w dnskey -ed
W takim przypadku URL F, który zawiera nieprawidłowy podpis DNSSEC, najwyraźniej generuje odpowiedź błędu serwowego z początkowego zapytania DNS, która z kolei uruchamia proces rozwiązywania nazwy klienta w celu ponownego ponownego ponownego zapytania DNS za pomocą innego rozdzielczości. Powtórzenie tej samej awarii powoduje, że klient wykonuje trzecią i końcową ponowną próbę w innym skonfigurowanym rozdzielczości.
Wyniki eksperymentu
Pierwszy przebieg tego eksperymentu miał następujące wyniki:
Przedstawione eksperymenty: 2 802 390 przedstawionych eksperymentów z pobieraniem sieci: 2 632 322 Przedstawione eksperymenty z wynikami internetowymi: 2142,141
Tabela 2 – Eksperymentuj liczenie
To pokazuje “oddać” Oceń w eksperymencie. Gdy reklama jest prezentowana użytkownikowi ( “wrażenie”) Użytkownik końcowy’Przeglądarka S jest przekazywana obiekt Flash. Wykonanie obiektu Flash powoduje, że przeglądarka użytkownika końcowego zebrała parametry eksperymentu, która składa się z trzech adresów URL eksperymentów i URL wyników. Przeglądarka rozpocznie następnie pobieranie trzech adresów URL, rozwiązywając nazwy DNS dla adresów URL. Pierwszy pomiar “Przedstawione eksperymenty” Na autorytatywnym serwerze nazw znajduje się całkowita liczba liczby unikalnych identyfikatorów, które wygenerowały zapytania DNS. Przeglądarka użytkownika końcowego wykona następnie pobieranie adresów URL. Różnica między liczbą zapytań DNS a liczbą pobierania sieci pokazuje, że około 6% przebiegów eksperymentów jest przerwane przed przejściem do części eksperymentu w Internecie. Po pobraniu wszystkich trzech adresów URL lub 10 sekund, przeglądarka użytkownika końcowego wykonuje zapytanie DNS Resolut. Kolejne 19% przebiegów eksperymentów nie dociera do tego wyniku fazy pobierania. Aby upewnić się, że efekt przerwania przebiegu eksperymentu jest zminimalizowany, następujące podsumowanie dotyczy tylko tych 2142 141 eksperymentów, które zakończyły pobieranie adresu URL wyników.
Eksperyment polega na pobraniu url D, E i. Poniższa tabela pokazuje liczbę klientów, którzy pobrali różne kombinacje tych adresów URL (a także pobrały adres URL wyników).
D e f Count no nr 4325 0.20% Tak Nie Nie 1 024 0.05% Nie Tak Nie 2627 0.12% Tak Tak Nie 60 988 2.85% nie, tak 1 045 0.05% Tak Nie Tak 6,108 0.29% nie Tak Tak 3291 0.15% Tak Tak Tak, 2 059 990 96.17%
Tabela 3 – Eksperymentuj kombinacje pobierania adresu URL
Poszło w sumie 60 998 eksperymentów D I mi, ale nie F. Możliwe, że jest to spowodowane tym, że klient nie jest w stanie zweryfikować podpisów DNSSEC na F Nazwa domeny, ale jest również możliwe, że klient po prostu nie przyniósł F ze względu na jakąś formę przedwczesnego końca eksperymentu’s egzekucja, mimo że URL wyników został pobrany. Możliwe jest użycie dzienników DNS, aby potwierdzić, czy klient próbował potwierdzić nazwę domeny F, szukając klientów, którzy odzyskali DS i DNSKEY RRS D I F, Ale tylko przyniósł D I mi. Jak pokazano w poniższej tabeli, było 58 303 takich eksperymentów lub 2.72% całości.
Jesteśmy również zainteresowani liczbą klientów, którzy korzystają z wielu rozdzielczości DNS, w których tylko niektórzy z rozdzielczości wykonują walidację DNSSEC. W przypadku, gdy weryfikacja DNSSEC zwróci kod błędu serwera, prawdopodobne jest, że klient przekazuje zapytanie do innych rozdzielczych. Jeśli te zdecydowane nie wykonują sprawdzania poprawności DNSSEC, klient otrzyma odpowiedź dla nazwy domeny F. Kolejną kategorią jest liczba klientów, którzy pobrali D, E i F, i pobierali RRS DS i DNSKEY. Ci użytkownicy wydają się korzystać z mieszanki klientów walidujących DNSSEC i nie zatwierdzających DNSSEC. Jak pokazano w poniższej tabeli, było 52 713 takich eksperymentów lub 2.46% całości.
Spośród pozostałych eksperymentów wyodrębniliśmy te eksperymenty, w których zapytano tylko RRS, co stanowiło 2 026 014 przebiegów eksperymentów, czyli 94 58% całości.
Pozostało około 2368 przebiegów eksperymentów, które wydaje się pobierać niektóre RR DNSSEC, ale nie można ich podzielić na żadną z dwóch powyższych kategorii.
Używane DNSSEC walidacyjne rozdzielczości: 58 303 2.72% zastosowało mieszankę walidacji i niekwalifikujących rozdzielczych: 52 713 2.46% pobrał DNSSEC RRS w czasie: 2368 0.11% nie przyniosło żadnych DNSSEC RRS: 2 026 014 94.58%
Tabela 4 – Eksperymentuj możliwości klienta dla DNSSEC
Wynik tego eksperymentu pokazuje, że niektóre 2.72% Spośród wszystkich klientów wydają się korzystać wyłącznie z rozdzielczości DNSSEC i nie będą w stanie rozwiązać nazwy DNS, gdy podpis DNSSEC jest nieprawidłowy. Kolejne 2.46% klientów korzysta z mieszanki weryfikacji DNSSEC i nie-walidujących rozstrzygnięcia, aby nie czerpali żadnych namacalnych “ochrona” Z tej mieszanej konfiguracji.
Co zmieniło się po ogłoszeniu walidacji DNSSEC z publicznych rozdzielczych DNS Google? Poniżej znajdują się te same dane z eksperymentu przeprowadzonego z 22 marca do 1 kwietnia.
Przedstawione eksperymenty: 2 590 330 Przedstawione eksperymenty z pobieraniem internetowym: 2 421 138 Przedstawione eksperymenty z wynikami internetowymi: 1 930 180
Tabela 5 – Liczba eksperymentu B
d e f Count no no 3471 0.18% Tak Nie Nie 797 0.04% Nie Tak Nie 2698 0.14% Tak Tak Nie 67 487 3.50% nie, tak 832 0.04% Tak Nie Tak 4027 0.21% nie Tak Tak 3352 0.17% Tak Tak, 1 844 790 95.58%
Tabela 6 – Eksperymentuj kombinacje pobierania adresu URL
Używane DNSSEC walidacja rozdzielczości: 64 690 3.35% zastosowało mieszankę walidacji i niekwalifikujących rozdzielczych: 43 657 2.26% przyniósł DNSSEC RRS.11% nie przyniosło żadnych DNSSEC RRS: 1 816 968 94.13%
Tabela 7 – Eksperyment B możliwości klienta dla DNSSEC
Wynik tego drugiego okresu eksperymentu pokazuje, że niektóre 3.35% spośród wszystkich klientów wydają się korzystać wyłącznie z rozdzielczości DNSSEC, a poprawnie nie będzie w stanie rozwiązać nazwy DNS, gdy jej podpis DNSSEC jest nieprawidłowy. Kolejne 2.26% klientów korzysta z mieszanki weryfikacji DNSSEC i niekwalifikujących rozdzielczych. Wydaje się, że poziom klientów weryfikujących DNSSEC wzrósł o nieco więcej niż 0.5%.
Czy ta pozytywna zmiana poziomów klientów, którzy wykonują sprawdzanie poprawności DNSSEC, związane z zmianą zachowania publicznych serwerów DNS Google?
Publiczne serwery DNS Google
Ten wzrost 0.5% w liczbie klientów wykonujących walidację DNSSEC od eksperymentu A do eksperymentu B można przypisać Google włączającemu walidację DNSSC w publicznych serwerach DNS w momencie ogłoszenia lub może znajdować się w granicach błędu eksperymentalnego, lub może to być wynik innego zestawu rozdzielczości włączających DNSSEC w tym okresie. To’jest rozsądne pytanie, czy zestawy danych zapytania DNS z serwerów nazwy DNS Google przed i po ogłoszeniu Google pokazują jakąkolwiek różnicę w zakresie, w jakim wykonują one walidację DNSSEC.
Public DNS Google jest przekierowcą DNS, więc patrząc na profil zapytań DNS, które są generowane przez Google Resolvers, przydatne może być spojrzenie na zestaw transformacji między zapytaniami wysyłanymi do Google i zapytania, które Google DNS Resourvers dokonuje do autorytatywnych serwerów nazwisk. (Zakładając zestaw unikalnych nazw domen, które nie są jeszcze ładowane do lokalnej pamięci podręcznej DNS Google).
Oryginalne zapytanie Google odpowiednie zapytanie | Niezapowalniowe walidacja | |. |. A a a (cd) a a a (do) a (do) a (do), ds (do), dnskey (do) a (do, cd) a (do) a (do) ds (cd) ds (do) ds (do) dnskey (do, cd) dnskey (do) dnskey (do) „cd” jest sprawdzającym zdarzeniem flagowym, a „do edtns0 opcja Present i DNS i DNSECECS i DNSECES i DNS -CD i DNS -CD i DNS -CD i DNSecse i DNS -CD i DNS -CD i DNS -CD i DNS -CD i DNS -CD i DNS -CD i DNS -CD) zestaw
Tabela 8 – Zapytanie DNS przekształca się w realizacji publicznych napastników DNS Google
Publiczne rozwiązania DNS Google nie ustawiają flagi CD na żadnym z zapytań, które dokonują na autorytatywne serwery (w przeciwieństwie do wyraźnych porad w sekcji 5.9 z RFC6840, ale ponieważ serwer jest autorytatywnym serwerem nazw, porady w tym RFC w tym konkretnym przypadku ma wątpliwą wartość! Wydaje się, że DNS DNS nie wydaje się zmieniać żadnego zachowania rozdzielczości DNS w nie ustawianiu flagi CD podczas wykonywania zapytania na autorytatywne serwery nazw).
Oprócz tej zmiany na profilu zapytania, jedyną inną zmianą, której spodziewalibyśmy się z perspektywy zapytań otrzymanych na autorytatywnym serwerze nazw między Google Resolver, który nie wykonał sprawdzania poprawności DNSSEC i takim, który wykonał sprawdzanie poprawności, jest to, że odsetek zapytań dla RR z DNSSEC OK Flag powinien być nieco niższy, powinna być nieco niższa, proporcjonalne zapytania A, DNSKey RR, wszystkie z DNSKEY, wszystkie z DNSKey RR, wszystkie z DNSKey RR, wszystkie z DNSKey RR, wszystkie z DNSKey RR, wszystkie z DNSKey RR, wszystkie z DNSkey. powinien powstać. Rozumowanie polega na tym, że jeśli Google otrzyma zapytanie z zestawem flagi DO i flaga CD, wówczas sam wykonuje sprawdzanie poprawności DNSSEC w wyniku, a tym samym wygeneruje zapytania A, DS i DNSKEY. Jeśli Google odbędzie zapytanie z zestawem flag DO i CD, to wyśle zapytanie do autorytatywnego serwera nazw z zestawem flagi DO, ale nie wykonuje żadnej walidacji DNSSEC w samej prawej.
Oto wyniki dwóch przebiegów tego eksperymentu pomiarowego. Eksperyment A to okres od 8 do 18 lutego 2013 r., A eksperyment B to okres od 22 marca do 1 kwietnia 2013 r.
Eksperymentuj eksperyment B Całkowita liczba zapytań: 309 043 328 059 . Single A zapytanie: 256 708 83.07% 289 428 88.22% Single A Query z zestawem DO: 23 134 7.48% 20 119 6.13% wielokrotne zapytania: 11 700 3.79% 7 916 2.41% wielokrotne zapytania A, wszystkie z zestawem DO: 1179 0.38% 578 0.18% wielokrotne zapytania, niektóre z zestawem DO: 1194 0.39% 877 0.27% pojedyncza sekwencja zapytania DNSSEC: 5904 1.91% 3196 0.97% innych sekwencji zapytań: 7482 2.42% 4706 1.43%
Tabela 9 – Google’S publiczne DNS Resicvers DNS Profil: Razem
Ten wynik nie jest zbyt pouczający. Proporcja pojedynczej sekwencji zapytania DNSSEC-Walidacji (zapytanie A, a następnie zapytania DS i DNSKEY w dowolnej kolejności) faktycznie wpadł w eksperyment B. Prowadzi to do niepewnego wniosku, że w granicach zmienności danych w tym eksperymencie wydaje się, że publiczne serwery DNS Google od pewnego czasu wykonują walidację DNSSEC, a walidacja DNSSEC nie została po prostu włączona w momencie ogłoszenia Google w dniu 19 marca 2013 r.
Istnieje inny potencjalny sposób wykrycia DNS Resolver Google wykonujący walidację DNSSEC. Jeśli zapytasz o RR z Publicznych serwerów DNS Google z zestawem bitów DNSSEC OK, a nazwa domeny jest podpisana DNSSEC, a podpis DNSSEC jest ważny, wówczas pierwsze zapytanie spowoduje, że DNS rozstrzyganie, aby zapytać o autorytatywne serwery nazw, dalsze przekształcenie, które będą odpowiedzieć od DNS rozstrzygnięcia. wysłane do autorytatywnych serwerów nazwisk. Z drugiej strony, jeśli podpis DNSSEC nazwy domeny jest nieprawidłowy, wówczas kolejne zapytania dla tej samej nazwy domeny (z zestawem bitów DNSSEC OK) spowodują, że rozstrzygnięcia DNS ponownie zapytają autorytatywne serwery nazwy. Ten eksperyment ma sygnatury DNSSEC-Valid i DNSSEC z nazwami domen D i F. To widoczne różnice we wzorcach zapytania z publicznych rozdzielczych DN Google?
Eksperyment kategorii A Eksperyment B Ważny (%) Nieprawidłowy (%) Ważny (%) Nieprawidłowy (%) Całkowita liczba zapytań: 153 540 154,907 164 043 165 623 Pojedyncza zapytanie: 127 366 82.95% 128 134 82.72% 144 561 88.12% 145 725 87.99% pojedyncze zapytanie z zestawem DO: 5465 3.56% 5 386 3.48% 6 308 3.85% 6 259 3.78% wielokrotne zapytania: 5557 3.62% 5789 3.74% 3780 2.30% 4 038 2.44% wielokrotne zapytania, wszystkie z zestawem do: 245 0.16% 248 0.16% 226 0.14% 236 0.14% wielokrotne zapytania, niektóre z zestawem DO: 202 0.13% 222 0.14% 231 0.14% 224 0.14% pojedyncza sekwencja zapytania DNSSEC: 10 818 7.05% 5 904 3.81% 6434 3.92% 3196 1.93% DNSSEC Valididate plus dodatkowe zapytania: 1 864 1.21% 7482 4.83% 1124 0.69% 4706 2.84% pozostałe 2 023 1.32% 1742 1.12% 1 379 0.84% 1 239 0.74%
Tabela 10 – Google’S PUBLICZNE DNS RESPORVERS DNS Profil: Ważne i nieprawidłowe sumy
Ta tabela nie pokazuje żadnej znaczącej zmiany woluminu zapytania między ważnymi i nieprawidłowymi nazwami DNS. Jest prawdopodobnie spowodowany naturą tego eksperymentu, w którym użycie unikalnych etykiet DNS w każdym eksperymencie zostało celowo zaprojektowane w celu obejścia buforowania.
Istnieje jednak jeden przypadek, w którym istnieją pewne dowody na powtarzające się zapytania DNS. Spadek względnej proporcji pojedynczych sekwencji zapytania DNSSEC między prawidłowymi i niepoprawnymi nazwami domeny jest ilustracyjny formy zachowania klienta, w której odpowiedź błędu serwfail z początkowego zapytania DNS powoduje ponowne ponowne ponowne zapytanie do następnego rozwiązania w lokalnej liście rozwiązywania nazw DNS rozwiązywania nazw DNS. Być może ironiczną częścią tego konkretnego zachowania jest to, że to, co widzimy tutaj w tej tabeli, jest wynikiem tych przypadków, w których wiele rozstrzygnięć DNS na liście dostępnych rozdzielczości klienta ostatecznie przekazuje te rzekomo odrębne zapytania na wspólny punkt publicznych serwerów DNS Google.
Możemy więc z całą pewnością powiedzieć, że Google nie włączył walidacji DNSSEC w momencie publicznego ogłoszenia 19 marca 2013 r., A Google wykonuje walidację DNSSEC od jakiegoś czasu przed ogłoszeniem. Wygląda na to, że 0.5% Zmiana poziomu stosowania przez klienta końcowego walidacji DNSSEC jest bardziej prawdopodobne, że wynik zmienności eksperymentu.
Wyniki – użycie DNSSEC przez użytkowników końcowych
Ten eksperyment pokazuje, że na początku 2013 roku niektóre 3% Spośród wszystkich klientów wydają się korzystać wyłącznie z rozdzielczości DNSSEC i odpowiednio nie będzie w stanie rozwiązać nazwy DNS, gdy jej podpis DNSSEC jest nieprawidłowy. Dalsze 2% klientów używa mieszanki weryfikacji DNSSEC i niekwalifikujących rozdzielczych.
Potwierdzone – Google’S publiczne DNS wykonuje teraz walidację DNSSEC dla wszystkich zapytań domyślnie
To’S Oficjalny… Google’S Public DNS Service wykonuje teraz walidację DNSSEC dla Wszystko Pytania DNS domyślnie!
Kiedy 19 marca pojawiły się Wiadomości, że Google włączył walidację DNSSEC w swojej publicznej usługi DNS, wystąpiły początkowe obawy po tym, jak ludzie zauważyli, że Google wykonuje walidację DNSSEC tylko na żądanie. Doprowadziło to do wyjaśnienia kilka dni później od Google, że ich początkowe wdrożenie wymagało, aby klient poprosiła o weryfikację DNSSEC, aby mógł przetestować usługę – i że pełna walidacja wkrótce się pojawiła.
Oficjalne słowo
Wczoraj Google’S Warren Kumari opublikowana na liście mailingowej DNSSEC-DEPLOMENT, że teraz dzieje się pełna walidacja:
Niedawno włączyliśmy sprawdzanie sprawdzania poprawności na całym świecie i powinieneś teraz uzyskać serwera dla awarii sprawdzania poprawności. Ponownie przeprosiny za oryginalne, niejasne ogłoszenie.
Blog / dokumentacja nie została jeszcze zaktualizowana (to prawdopodobnie nastąpi w ciągu najbliższych kilku dni), ale chcieliśmy jak najszybciej dać ci dobrą wiadomość.
I rzeczywiście szybki test, aby sprawdzić, czy mogę uzyskać rekordy DNS dla domeny testowej, o której wiadomo, że ma zły podpis DNSSEC, wytworzył oczekiwany “Servfail” Wiadomość i poprawnie zrobiła nie Zwróć dowolne rekordy DNS:
$ dig @8.8.8.8 www.DNSSEC Failed.org; > DIG 9.8.3-p1> @8.8.8.8 www.DNSSEC Failed.org; (1 znaleziony serwer) ;; Opcje globalne: +cmd ;; Dostałem odpowiedź :;; ->> Headerservfail, ID: 60286 ;; Flagi: Qr Rd RA; Zapytanie: 1, Odpowiedź: 0, Autorytet: 0, dodatkowe: 0 ;; Sekcja pytań :; www.DNSSEC Failed.org. W
To świetna wiadomość dla tych z nas, którzy są zwolennikami DNSSEC i oznacza, że każdy korzysta z Google’P publiczne serwery DNS dla rozdzielczości nazwy DNS są teraz automatycznie otrzymujące większe bezpieczeństwo DNSSEC. Każdy, kto korzysta z tych serwerów, będzie wiedział, że (w przypadku podpisanych domen) informacje, które wydostają się z DNS, to ta sama informacja, którą operator domeny umieścił w DNS – a nie na atakującym, który chce, żebyś udał się na inną stronę.
Jeśli ty również chcesz uzyskać dostęp do zwiększonego bezpieczeństwa DNSSEC, wystarczy skonfigurować komputer lub router domowy, aby miał jako serwery DNS, serwery Google Public DNS:
Przenoszenie walidacji DNSSEC jeszcze bliżej
Tak niesamowite jak ten ruch Google jest (i to Jest niesamowite), nadal możesz zwiększyć bezpieczeństwo zapewnione przez DNSSEC. Ponieważ Google’Publiczne serwery DNS nie ma w sieci lokalnej i są raczej gdzieś w Internecie, jest Nadal szansa, że napastnik mógłby wstawić się między tobą a Google’S serwery DNS. Atakujący mógłby następnie udawać, że wysyła cię poprawne informacje i udawanie go jako Google’s publiczne serwery DNS.
Aby uzyskać najwyższy poziom bezpieczeństwa DNSSEC, najlepiej chcesz wykonać walidację DNSSEC przynajmniej w sieci lokalnej, a potencjalnie nawet lokalny komputer. Tam’S wielki oficjalny dokument od ludzi z Surfnet Calling “Wdrożenie DNSSEC: Walidacja na rekursywnych serwerach nazwisk buforowania” To wyjaśnia, w jaki sposób możesz po prostu włączyć walidację DNSSEC dla trzech wspólnych serwerów DNS używanych przez przedsiębiorstwa i sieci dzisiaj.
Hej, jeśli Google może włączyć sprawdzanie poprawności DNSSEC, dlaczego może’t You?
Jeśli możesz’T dokonaj walidacji DNSSEC lokalnie (na przykład, jeśli masz tylko domowy router Wi -Fi, który nie’t wykonać walidację), wówczas wykonanie sprawdzania poprawności na twoim dostawcy dostawcze usług internetowych może być następnym krokiem… a jeśli wygrał twój dostawca usług internetowych’T dokonaj sprawdzania poprawności DNSSEC, to naprawdę nie masz innego wyboru, jak korzystać z usługi takiej jak Google’s publiczne usługi DNS. Ich walidacja DNSSEC jest zdecydowanie znacznie lepsza niż żadna!
Znowu uznanie dla Google’Publiczny zespół DNS za zrobienie tego kroku i czekamy na dzień, w którym Wszystko DNS Resicvers po prostu automatycznie wykonują sprawdzanie poprawności DNSSEC.
Oświadczenie: Punkty widzenia wyrażone w tym poście są punkty autora i mogą, ale nie musi odzwierciedlać oficjalnych stanowisk społeczeństwa internetowego.
Czy Google używa DNSSEC
Czy Google publikuje wszelkie statystyki na żywo dotyczące stanu swojej sieci DNS?
Bardzo się cieszę, że wdrażasz pełną parę w DNSSEC i innych najlepszych praktykach DNS Security wdrożenie i chcesz popierać Google DNS innym ludziom, ale niestety, nie jesteś w tej chwili zgodny ze specyfikacjami DNSSEC z tego momentu z tego prostego powodu, że jeśli bit nie jest ustawiony w zapytaniach, nie wykonujesz żadnej sprawdzania poprawności. To jest po prostu złe; Powinieneś zwrócić serwfail na każdą awarię walidacji dowolnego klienta.
To naprawdę świetna i pomocna informacja.
Jestem zadowolony, że po prostu udostępniłeś nam te przydatne informacje.
Proszę, pozostańmy w takim poinformowaniu. Dzięki za udostępnienie informacji.
Czy ktoś w Google przydzielony do pracy, aby uzyskać Google.podpisana DSNSec com Domena? Mamy problem z kurczakiem i jajkiem, w którym użytkownicy końcowi nie poświęcają czasu na zaangażowanie się w DNSSEC, jeśli witryny, w których często uzyskują dostęp do. Jeśli ktoś nad tym pracuje, jaka jest docelowa data wdrożenia/kwartał?
Google: gdzie’S Your DNSSEC?
Google dużo zainwestował w bezpieczeństwo IT i, myślę, że wykonał przyzwoitą robotę. Wszystkie usługi są domyślnie TLS, tożsamość i autoryzacja są dobrze rozwiązane.
Więc byłem trochę zaskoczony, że widzę, że Google’s własny .com (i .CA) nie są konfiguracją DNSSEC. Zastanawiam się, dlaczego musi istnieć powód.
DNSSEC pomaga uniknąć fałszowania domen, które z kolei można użyć do oszukiwania i otrzymywania certyfikatów TLS. I’Jestem pewien, że to była świadoma decyzja. Ich 8.8.8.8 serwer wykonuje sprawdzanie poprawności DNSSEC. Jest to opcja w ich zarządzanych domenach Google. Ich chmur DNS to obsługuje. Po prostu nie przychodzą do ich domeny korporacyjnej.
