Google i OpenDNS przedstawiają ulepszenie protokołu DNS

Google i OpenDNS, dwie z najpopularniejszych usług rozpoznawania nazw publicznych w internecie, zaproponowali i wdrożyli Rozszerzenie protokołu DNS Co pozwoli poprawić prędkość nawigacja podczas korzystania z zasobów z sieci dystrybucji treści.

Duże firmy zajmujące się dystrybucją treści mają serwery rozmieszczone na całym świecie w systemach zwanych Content Delivery Network (CDN). Dobrym tego przykładem jest na przykład Akamai, który służy jako magazyn plików dla firm zewnętrznych.

Jeśli założymy, że sieci CDN mają wyłączny serwer obsługujący kraj ze wszystkimi dostępnymi treściami replikowanymi, wielką zaletą w porównaniu z centralizacją wszystkiego w jednym miejscu jest to, że teoretycznie czas dostępu do treści jest zminimalizowany. (Opóźnienie), ponieważ Na przykład użytkownik w Sewilli zamiast komunikować się z centralą w Stanach Zjednoczonych, zrobi to z serwerem, który ma w Hiszpanii.

Aby to osiągnąć, sieci CDN używają systemu DNS, który na podstawie adresu IP komputera wysyłającego żądanie może ustalić jego pochodzenie i odpowiedzieć na adres IP serwera treści znajdującego się najbliżej tego kraju lub obszaru.

Jednak nie jest to już idealne, gdy nie ma kilku i coraz więcej użytkowników sieci, którzy nie korzystają z DNS dostarczonego przez ich operatora i nie konfigurują publicznych na swoim komputerze, takich jak Google lub OpenDNS, aby nazwać dwa przykłady zawarte w artykule.

1. Stronę internetową loquesea.eu piszemy w pasku przeglądarki.
2. Komputer, który nie wie, który adres IP odpowiada nazwie, żąda tłumaczenia od serwera DNS (1), który skonfigurował (operatora lub innego).
3. Jeśli założymy, że ten serwer ma pustą pamięć podręczną, będziesz musiał poprosić o pomoc tak zwane serwery główne, które poinformują Cię, który serwer odpowiada za całą przestrzeń adresową .eu (2).
4. Następnie operacja jest powtarzana. W takim przypadku serwer DNS, który skonfigurowaliśmy, zapyta (3) tego, który jest odpowiedzialny za wszystkie nazwy .eu dotyczące serwera, który ma pod swoją kontrolą nazwę loquesea.eu i jego subdomeny (np. Linebenchmark.loquesea.eu) .
5. Na koniec ostatnie żądanie DNS jest wysyłane do tego ostatniego serwera, który zwróci adres IP loquesea.eu (4) i zostanie przekazany do komputera, który zainicjował zapytanie w pierwszej instancji (5), aby ostatecznie otworzyć HTTP sesji i pobrać stronę internetową (6).

Jak widać, jest to dość złożony proces, choć w oczach użytkownika sieci odbywa się to w sposób transparentny.

Poprawa wydajności DNS podczas uzyskiwania dostępu do sieci CDN

Problem systemów DNS dla tradycyjnych CDN, o którym wspomnieliśmy, jest następujący: ponieważ negocjacje DNS w celu uzyskania adresu IP żądanego miejsca docelowego są przeprowadzane przez serwer pośredniczący, CDN wykrywają serwery Google DNS jako źródło żądania, które znajdują się w Stanach Zjednoczonych. Biorąc to pod uwagę, CDN odpowiada adresem IP swoich serwerów w Stanach Zjednoczonych, a nie w Hiszpanii. Tracimy wydajność, ponieważ zwiększa się opóźnienie.

Aby rozwiązać ten problem, opracowano modyfikację protokołu DNS, która wykorzystuje rozszerzenia proponowane w RFC 2671 aby rozpoznawanie nazw było bardziej inteligentne.

Pomysł, który nazywa się Globalne przyspieszenie Internetu i wciąż jest w środku faza robocza, pomaga w oryginalnym adresie klienta, który dodaje jako jeszcze jedno pole danych do żądania („edns-client-subnet”).

Chociaż tak naprawdę, aby zachować prywatność użytkownika, to, co jest wysyłane, jest częścią publicznego adresu IP użytkownika (bity są usuwane z końca), więc zamiast wysyłać 1.2.3.4 (jeśli był to publiczny adres IP użytkownika), jest obcinany do 1.2.3.0 (wszystkie pośredniczące serwery DNS będą mogły odczytać te informacje), wraz z 24-bitową maską sieci.

Dzięki temu nie ma znaczenia, że ​​używany jest DNS Google, ponieważ gdy informacje użytkownika są dołączone jako dane w żądaniu, jeśli serwer docelowy jest zgodny z tą nową inicjatywą, będzie w stanie poprawnie określić, skąd naprawdę chcesz uzyskać dostęp do jego treści i odpowiadać na serwer najbliżej klienta, minimalizując opóźnienia, a tym samym poprawiając szybkość przeglądania.

Dla tych, którzy są bardziej podejrzliwi co do swojej prywatności, można ją skonfigurować tak, aby żadna część adresu IP użytkownika nie była wysyłana (wysyłany jest adres 0.0.0.0/0). W takich przypadkach rozumiemy, że usługa będzie działać jak tradycyjny DNS w CDN. Oznacza to, że nie mając pojęcia o swoim prawdziwym pochodzeniu, CDN odpowiadałoby adresem IP najbliższym serwerowi DNS wysyłającemu żądanie.

W tej chwili zarówno Google, jak i OpenDNS zainstalowały już tę nową funkcję w swoich systemach, którą opracowały wspólnie z CDNetworks, EdgeCast, BitGravity i samą Akamai, co pomogło w napisaniu wersji roboczej.

Chociaż nadal wydaje się niejasne, jak duży wpływ będzie to miało na rzeczywistą wydajność sieci, wcale nie jest nierozsądne, że IETF ostatecznie przyjmuje tę technikę jako standard, który operatorzy mogą również przyjąć, czy to w jej aktualnej wersji roboczej, czy też w finale.

źródło: Internet szerokopasmowy