Основы IT: DNS

Аватар пользователя Karbafoz

DNS - Domain Name System, система доменных имён.

Иерархическая распределённая система серверов, отвечающая главным образом за трансляцию доменного имени в IP-адрес сервера. Также на DNS завязана доставка почты (домен присутствует в почтовом адресе), плюс последнее время стало крайне модно пихать всякие ключики и хэшики в TXT запись домена. Придумали это всё аж в 1984 году, сейчас этим управляет ICANN – “Корпорация по управлению доменными именами и IP-адресами.”

Доменное имя или FQDN (fully qualified domain name) в общем случае выглядит как-то так: subsubdomain.subdomain.domain.tld

Разбирается справа налево, tld – это домен первого уровня (или TLD, Top Level Domain), domain – это домен второго уровня, subdomain и subsubdomain – третьего и четвёртого соответственно, могут вообще отсутствовать. Домен должен начинаться с буквы, может содержать буквы, цифры и тире, только латиница, регистр не различается. TLD бывают:

Общие (gTLD)

  1. со свободной регистрацией: .com, .net, .org, .info, .biz и .name.
  2. с ограниченной регистрацией: .edu (для образовательных сайтов), .gov (для сайтов государственных организаций США), .mil (для военных организаций США), .int (для международных организаций).
  3. Еще не так давно ICANN одобрило создание кучи дополнительных зон общего пользования (.xxx, .mobi, .cat и т.д.)

Национальные (ccTLD) - делегированы соответствующим национальным регистраторам, которые устанавливают правила регистрации в них либо сами, либо согласно указаниям правительства. Управляющей организацией является IANA.

  • .US – Соединённые Штаты;
  • .RU – Россия (нам по наследству также достался домен .SU);
  • .CN – Китай;
  • И т.д.

Неплохо на этом деле подзаработало небольшое островное государство Тувалу с доменом .TV

Интернационализованные домены (IDN) - доменные имена, которые содержат символы национальных алфавитов, про них отдельно и позже.

И, наконец, еще есть немного зарезервированных доменных имён.

 

Сервера доменных имён, namservers или просто NS.

Сервер, который отвечает за определённую доменную зону – содержит все записи и отвечает на DNS запросы клиентов. Корневые сервера содержат информацию о NS серверах, обслуживающих определённый TLD. NS сервер может делегировать управление частью управляемой им зоны другим серверам.

Вот как происходит полный (рекурсивный) поиск доменного имени:

 

Разберём этот вывод немножко подробнее:

 

Это мы сходили к локальному DNS серверу, и спросили у него список корневых серверов и их адреса. Потом пошли к одному из них, чтобы узнать, кто отвечает за зону .NEWS

 

e.root-servers.net нам ответил, что вот четыре австралийца, с них и спрашивайте. И мы пошли у них спрашивать, кто отвечает за домен второго уровня aftershock.news:

 

demand.alpha.aridns.net.au нам ответил, что вот имеются 5 серверов в nic.ru (это Ru-Center – среди прочего и наш национальный регистратор в зоне .RU).

 

И вот, наконец, один из NS Ру-центра нам ответил, что m.aftershock.news имеет IP 185.112.80.17

Теоретически, владелец домена aftershock.news мог делегировать управление зоной m.aftershock.news еще кому-то под управлением других NS, тогда в этой цепочке добавился бы еще один шаг - ns4-cloud.nic.ru нам бы ответил, кто отвечает за m.aftershock.news и мы бы сходили к нему.

Ясное дело, не гоже бегать по всем этим серверам для каждого запроса – DNS ответы кэшируются на промежуточных серверах. Предположим, я полез на АШ с мобильника, через Wi-Fi домашнего рутера. Во-первых, в веб-браузер обычно встроен свой маленький DNS cache, так же есть свой кэш и в операционной системе мобильника. Когда мой мобильник устанавливает Wi-Fi соединение с домашним рутером, он получает свой персональный IP адрес в моей локальной домашней подсети, а также в качестве DNS-сервера по умолчанию прописывается сам рутер. Поэтому, если искомого адреса не нашлось ни в локальном кэше браузера, ни в системном кэше телефона, запрос идёт к рутеру. Рутер ищет ответ в своём DNS кэше, и, если там ничего нет, даёт запрос DNS запрос моему интернет провайдеру. Что там происходит у провайдера, и сколько там еще кэширующих серверов – я не знаю, но рано или поздно где-нибудь да произойдёт рекурсивный поиск имени и информация попадёт в мой телефон, а также во все промежуточные кэши.

Адреса NS серверов обычно появляются в рутере при подключении к интернет провайдеру сами (DHCP) или прописываются руками. Технически можно прописать там и другие внешние NS, но провайдеры еще могут предоставлять какие-нибудь дополнительные сервисы в локальной сети, а также еще они очень любят резать DNS трафик к чужим серверам (53 TCP и UDP порт) – блокировка DNS, это первое, что приходит в голову в случае возникшей задолженности.

Выше была упомянута некоторая организация Ру-центр, коротко о доменных регистраторах.

Доменный регистратор (registrar) – это организация, уполномоченная добавлять и вносить изменения в соответствующую TLD зону. Ру-центр отвечает за национальные TLD .ru, .su и .рф. Также, регистраторы могут позволять (другим организациям-партнёрам регистрировать домены в своих зонах предоставляя для этого API (application programming interface - программный интерфейс приложения). По таким программам с Ру-центром работают все перепродавцы доменов в зоне .ru, а сам Ру-центр работает со сторонними регистраторами (международными и национальными) для доменов в таких зонах как .com (международная) и .tv (национальный домен Тувалу). Это не для всех так, например, в итальянском TLD .it Ру-центр регистрацию не предлагает, там могут зарегистрироваться только резиденты.

 

Чтобы программистам, ваяющим софт для регистрации доменов было не скучно, иногда домен второго уровня может сам выступать как своего рода TLD – есть стандартные коммерческие или региональные зоны, такие как .co.uk, .co.il, .spb.ru, .gov.ru и т.д.

 

Домен регистрируется сроком на 1-2 года, потом регистрация может быть продлена. При покупке домена, регистратор обычно предлагает использовать его NS и предоставляет некоторую панель для управления DNS записями в соответствующей зоне. Вообще это не обязательно, и можно для купленного домена указать свои NS.

 

Раньше было условие, что указывать нужно минимум два NS сервера, которые сами имеют IP-адрес из двух разных подсетей класса “C”. Сейчас даже это не требуется – либо можно указать один NS, либо оба NS могут работать на одном IP. Выше мы видели, что при рекурсивном поиске домена, нам отдавалось аж по 4-5 NS серверов. Это потому, что изначально архитектура разрабатывалась при предположении возможного ядерного удара – она должна оставаться рабочей, даже если часть серверов выйдет из строя. Отсюда и появились требования на два NS и разные подсети IP-адресов. Информация на всех NS синхронизируется, обычно у провайдера за публичными NS серверами стоит скрытый мастер NS сервер, с которого публичные NS периодически забирают данные. В процессе рекурсивного поиска, получив список NS серверов, система обращается к одному из них. Опрашивается первый попавшийся, случайный, по-очереди, всегда первый - по-разному, зависит от реализации. На всякий случай NS сервера еще могут перетасовать NS записи при ответе.

 

Что еще есть интересного в DNS зоне, помимо IP адреса домена и NS серверов для его поддоменов?

Из основного это:

  • SOA (Start of Authority) запись – в ней указываются первичный NS сервера зоны, email администратора, технические параметры для синхронизации зон, в частности TTL (time to live) – время жизни зоны в кэше. Стандартное значение TTL – 24 часа (86400 секунд), однако некоторые кэширующие DNS сервисы могут игнорировать TTL зоны и устанавливать свой.
  • MX (Mail exchange record) – в этой записи указывается имя почтового сервера, принимающего почту для домена
  • TXT (Text record) – изначально предполагалась как human-readable text, однако сейчас больше используется как machine-readable data, туда пишут публичные ключи для шифрования, подписи и прочие данные для автоматизации.

 

Пару слов про IDN-домены, вроде мойклёвыйдомен.рф. С начала века это активно продвигали китайцы и индусы. Запустилось в 2010 году для Египта, России, Саудовской Аравии и Эмиратов. Функционал нагородили поверх уже имеющийся системы, IDN домены пока используются весьма ограниченно. Доменное имя на локальном языке в кодировке UTF специальным алгоритмом переводится в ASCII с добавлением префикса “xn--“. мойклёвыйдомен.рф с точки зрения DNS серверов это просто xn--b1aednbehfglcg0o6c.xn--p1ai, где .xn--p1ai это TLD, соответствующее .рф. Запись вида xn--что-то-там называется “punicode”, переводом имени домена из локального написания в пуникод и обратно занимается непосредственно браузер, делая процедуру для пользователей прозрачной.

 

Уфф, опять что-то многобукв выходит. Reverse зоны пропустим, просто отметим, что в DNS есть механизм и для обратного разбора – по IP-адресу NS выдаст какой-то из доменов для указанного IP. На практике же не все домены попадают в обратные зоны.

 

Безопасность и риски.

 

DNS трафик не шифруется. Его может подделать зловредный man in the middle, такой тип атаки называется DNS cache poisoning. В результате в каком-то сегменте сети в кэшах оказывается поддельная DNS информация. Например, кто-то в моей сети подменил IP-адрес aftershock.news на свой сервер и вместо аналитики показывает мне котиков и как люди ругаются. Активно разрабатывается DNSSEC – протокол, в котором внедряются цифровые подписи для обеспечения целостности данных, дело не быстрое, особенно когда еще необходимо обеспечить и обратную совместимость.

 

Кривая настройка NS сервера может позволить стороннему человеку произвести полный трансфер зоны (AXFR, так информация синхронизуется между мастер-NS и его слэйвами). Тогда можно узнать все поддомены в зоне и атаковать не основной сервер, а какой-то богом забытый поддомен, обслуживающийся на том же сервере, но на котором может стоять старый кривой дырявый софт.

 

Из глобальных проблем, которые упоминались в связи с «законом о суверенном интернете» - а что будет, если на корневых NS серверах вообще запретят делегацию зоны .ru? Тогда, теоретически, где-то через 24 часа протухнут все кэши никто не сможет достучаться до любого домена в этой зоне. На практике же, государство может у себя поднять несколько «зеркал» корневых серверов и использовать их на уровне магистральных интернет провайдеров. Этой весной вроде собирались тестировать подобный сценарий, чем дело кончилось – я не знаю, не следил.

Авторство: 
Копия чужих материалов

Комментарии

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

объяснять днс без алиасов нет смысла. иначе не понятно , почему я могу попасть на сайт по имени через днс а вот напрямую на IP адрес выйдет далеко не всегда.

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Не уверен, что я правильно понял, о каких алиасах идёт речь. Если про CNAME DNS запись (типа считать www.aftershock.news как то же самое, что и просто aftershock.news), то можно её рассматривать как своеобразную A (IP) запись с некоторыми ограничениями. В любом случае, это не даст ответа, почему по IP не всегда до сайта можно достучаться. Я планирую описать это в статье про хостинг - для shared hosting'а это важно.

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

ну так это напрямую к днс идёт - причем это самый большой вопрос у тех кто не до конца понимает механизм днс

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Я так и не понял, про какой алиас идёт речь. Два разных домена могут иметь один IP-адрес (и, соответственно, физически хоститься на одном сервере). Домены, которые обслуживает веб-сервер прописаны у него в конфигурации. Для того, чтобы к сайту был доступ по IP нужно веб-серверу указать, на какой из обслуживаемых сайтов резолвить этот IP (если вообще давать доступ по IP). Где тут алиас?

Аватар пользователя cr4zyr0m
cr4zyr0m(11 лет 6 месяцев)

есть стандартные коммерческие или региональные зоны, такие как .co.uk, .co.il, .spb.ru, .gov.ru и т.д.

Норвежское правительство забыли! .gov.no

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

:) Про норвежцев не скажу, а клиентов с .gov домена за глаза я называл govнюками - такие не забываются: компетенции обычно ниже среднего, а требований больше. Плюс достаточно мерзкая манера общения.

Аватар пользователя alexsword
alexsword(12 лет 8 месяцев)

на примере:

ping aftershock.news
64 bytes from 185.112.80.17: icmp_seq=0 ttl=64 time=0.029 ms

зайти по адресу 185.112.80.17 получится, но будете незалогиненным и без https:

186c357f2d22b91a711b4e8a89695f17.png

 а при попытке логина, залогиниться не получится.

вот такой вот пердимонокль и shared hosting тут ни при чем :-)

Аватар пользователя Jeque
Jeque(12 лет 2 месяца)

Так это, вроде, зависит от настройки веб-сервера, который по ip может вообще другие страницы выдавать.

Комментарий администрации:  
*** Подаёт сплетни под видом фактов, уличен в гнилоязыком пустословии ***
Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Но ведь это не DNS, а конфигурация веб-сервера :)

Но я кажется начинаю понимать, что ДК под "алиасом" подразумевает - похоже, что это A запись. 

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

так откуда там буква А :)

кстати это тут нужно объяснять как один и тот же физически сайт может иметь два доменных имя, и наоборот одно доменное имя иметь несколько физических мест. это всё делается ДНС записями.

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Смею предположить, что логин у вас для безопасности требует принудительный HTTPS, а SSL сертификат, необходимый для установления https соединения выписывается на доменное имя (на IP-адрес сертификат не выдаётся).

Аватар пользователя alexsword
alexsword(12 лет 8 месяцев)

:-)  А почему на IP адрес можно зайти по http, а на aftershock.news нельзя? 

Аватар пользователя Спасибо
Спасибо(10 лет 1 месяц)

Зайти можно. Но при заходе происходит мгновенный форвард на https://aftershock.news .   Цэ настраиваемая фича ВЭБ-сервера..

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Потому, что на веб-сервере сконфигурирован редирект с http на https для домена aftershock.news:

root@server# curl -i http://aftershock.news
HTTP/1.1 301 Moved Permanently
Server: ddos-guard
Connection: keep-alive
Keep-Alive: timeout=60
Set-Cookie: __ddg1=Da0fyz3I6ZUqo6i6zMiy; Domain=.aftershock.news; HttpOnly; Path=/; Expires=Thu, 30-Sep-2021 21:57:29 GMT
Date: Wed, 30 Sep 2020 21:57:29 GMT
Content-Type: text/html
Content-Length: 184
Location: https://aftershock.news/
Access-Control-Allow-Origin: *

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.8.1</center>
</body>
</html>

На GET запрос  по протоколу HTTP веб-сервер на самом деле отдаёт ответ с кодом 301 (перманентный редирект) не сам контент странички с кодом 200 (ok). Этот редирект обрабатывается браузером и идёт повторный запрос на адресс указаный в заголовке "Location": это https://aftershock.news/

Это стандартная практика - используя подобный редирект сейчас рекомендуется где можно переводить с протокола HTTP на HTTPS (а наоборот, с протокола HTTPS на HTTP скидывать соединение, скажем так, не рекомендуется).

Аватар пользователя Великий Кукурузо

Для домена включен редирект с http на https

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

но почему то он есть :)

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Это самоподписанный сертификат - несчитово. Большинство браузеров на него сругнутся. Нормальный сертификат на IP-адрес вам не выпишут.

root@server$ echo | openssl s_client -connect 185.112.80.17:443 | openssl x509 -noout -enddate
depth=0 C = EU, ST = *, O = ddos-guard
verify error:num=18:self signed certificate
verify return:1
depth=0 C = EU, ST = *, O = ddos-guard
verify return:1
DONE
notAfter=Mar 25 19:26:13 2028 GMT
 

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

ну ну ну не выпишут. ещё как выпишут, только на компанию OV типа.

правда он будет "несколько дороже" :)

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Чтобы другим тоже было понятно, о чем речь - сертификаты бывают трёх типов:

  1. DV (Domain Validation) - проверяется, что владелец сертификата действительно является владельцем домена;
  2. OV (Organization Validation) - помимо домена, проверяется еще и назавние организации, которое также вносится в одно из полей (ON) сертификата;
  3. EV (Extended Validation) - практически как OV, только организация проверяется более детально.

Так вот, доменное имя входит во все три типа. Для OV сертификата в качестве бонуса могут дать wildcard сертификат сразу для всех поддоменов, например *.aftershock.news - такой сертификат годится как для сайта и aftershock.news так и для m.aftershock.news. Еще приятным бонусом будет информация о организации в строке браузера. Цена на них не так, чтобы прям совсем заоблачная - по сравнению с DV отличается в диапазоне два раза - на порядок.

Совсем бездоменных (кроме self-signed) сертификатов на практике я не встречал, хотя могу допустить их существование. Цифровая подпись используется не только для HTTPS. Например, для цифровой подписи инсталлера какого-нибудь ПО доменное имя организации не важно. Зато когда вы запустите этот установщик система вам скажет "Вы точно хотите запустить установку этого ПО? Publisher: Такая-то Организация, ООО", где название "Такая-то Организация, ООО" возьмётся из сертификата подписи.

Для обычного хостинга чаще всего используют DV сертификаты, банки и прочие серъёзные структуры - EV.

Аватар пользователя Vovcha22
Vovcha22(8 лет 9 месяцев)

Таким способом вы заходите на 80 порт . Поставьте двоеточие после и 443 и зайдёте на https 

Аватар пользователя Inkvizitor
Inkvizitor(12 лет 4 месяца)

Напишите лучше статью, где лежат и как править файлы hosts в винде или на линуксе. У вас это явно получится)

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Не уверен, что прям на статью наберётся :) Исторически, в файлике hosts руками велась база соответствй Domain -> IP до изобретения DNS. Но таки да, данные в текстовом файле hosts обычно имеют приоритет над DNS (но не всегда).

Linux: /etc/hosts

Windows: %SystemRoot%\System32\drivers\etc\hosts (обычно C:\Windows\System32\drivers\etc\hosts)

 

Аватар пользователя brekotin
brekotin(9 лет 2 месяца)

Директива хостс имела раньше (не знаю как сейчас) очень сильную дырку: если ее не прописать на ключевой сайт, то можно было сделать копию сайта (который по сути все страницы выкачивает с основного сайта, например динамически) и в hosts прописать свой домен. Для поисковиков (ЯНдекс, Гугл) ключевым становился левый сайта. Ну и трафик уходил вместе со всеми параметрами на левый сайт. 

Копию размещаешь в какой нибудь Прибалтике, служба поддержки которых принципиально игнорит запросы из России и куча головняка для владельцев основного сайта. (Самый простой способ прописать хостс и заблокировать адрес с которого идет самый активный трафик, но до этого догадывались максимум 20% администраторов сайтов).

P.S.: это рассуждаю не с точки теоретика, но и не конкретного практика. 

Аватар пользователя eumorozov
eumorozov(5 лет 18 часов)

Это имеет отношение скорее к протоколам HTTP и HTTPS, чем к DNS.

Разные доменные имена могут иметь один ip адрес. HTTP сервер уже по имени (которое браузер передаёт в http-запросе) определяет, какой сайт ему отдавать.

Если запросить по ip-адресу, то будет отдан сайт по умолчанию.

Аватар пользователя ДК
ДК(11 лет 8 месяцев)

на сервере есть ДНС записи, которые и управляют доступом. никого особо не интересует как там работают ДНС сервера, а вот как управлять сайтом через ДНС рекордс - вот что очень всех интересует.

потому что я полдня объяснял одному как у меня домен второго уровня на одном IP а домен третьего уровня на этом домене на другом сервере и другом провайдере.

Аватар пользователя GrumpyVK
GrumpyVK(3 года 9 месяцев)

потому что я полдня объяснял одному как у меня домен второго уровня на одном IP а домен третьего уровня на этом домене на другом сервере и другом провайдере.

Дык тут же проблемы не с DNS или с HTTPS, а банально с неумением в логику.

Современное поколение этим зало страдает, но как это можно исправить в статье про DNS?

Я вот даже представить себе это не могу...

Скрытый комментарий Повелитель Ботов (без обсуждения)
Аватар пользователя Повелитель Ботов
Повелитель Ботов(54 года 6 месяцев)

Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.

Комментарий администрации:  
*** Это легальный, годный бот ***
Аватар пользователя AndreyTemp
AndreyTemp(8 лет 7 месяцев)

Спасибо, интересная но очень узко специализированная статья . Хабра из АШа не выйдет ;)

Комментарий администрации:  
*** отключен (систематические набросы) ***
Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Велкам! АШ на лавры Хабра не претендует, а лично меня к написанию побудило два момента:

  1. Еще раз переложить в голове знания - объясняя что-то кому-то можно лучше понять некоторые нюансы.
  2. Уровень большинства комментариев под нечастыми статьями, затрагивающими сферу IT просто удручает. Не всякий не-айтишник пойдёт читать Хабр, вики и тем более RFC - может, хоть так расширят свой кругозор. Ну или хотя бы подчерпнут пару-тройку ключевых слов, по которым можно самостоятельно искать информацию дальше.
Аватар пользователя monk
monk(12 лет 4 месяца)

Активно разрабатывается DNSSEC – протокол, в котором внедряются цифровые подписи для обеспечения целостности данных, дело не быстрое, особенно когда еще необходимо обеспечить и обратную совместимость.

Он уже десятилетие поддерживается всеми популярными серверами DNS. Единственное препятствие — то же, что и при https: нужен сертификат. А это дополнительные расходы.

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Технически - да. DNSSEC записи поддреживаются начиная с BIND 9, а это аж 2000 год (к слову, заказчик - минобороны США).

Практически же сейчас DNSSEC пока используется не часто. И дело не только в платном сертификате (насколько я знаю, сертификат вообще не используется, а просто две пары ключей, кторые можно сгенерировать самостоятельно) - нужны дополнительные приседания:

  1. Нужно ввести специальные DS записи непосредственно на регистраторе домена;
  2. После каждого изменения в доменной зоне её нужно заново переподписать;
  3. И вообще, в силу особенностей алгоритма, для пущей надёжности DNS зону рекомендуют переподписывать раз в три дня.

Провайдерам этим заморачиваться недосуг, а простым смертным - не всегда хватает квалификации. Риски весьма условные, а возни много. Но это пока, общий мировой тренд идёт в сторону усиления безопасности и рано или поздно DNSSEC будет внедрен повсеместно.

Аватар пользователя monk
monk(12 лет 4 месяца)

Провайдерам как раз тривиально: dnssec-enable yes; dnssec-validation auto;

Владельцам зон не намного сложнее: галочка в интерфейсе или скрипт на полдюжины команд. На фоне остальной фигни, которую приходится запихивать в DNS — это вообще ни о чём.

 

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Тогда как вы объясните, что за 20 лет технология так и не стала массовой?

Аватар пользователя monk
monk(12 лет 4 месяца)

Потому же, почему IPv6 за 25 лет не стал массовым. Лень и отсутствие мотивации для безопасности. Для внедрения HTTPS много сделали провайдеры, втыкающие рекламу в проходящий поток. А в чём опасность отравления DNS — не очевидно. Завернуть трафик на другой сервер? Так это пройдёт только с HTTP и не пройдёт с HTTPS.

P.S. Актуальная версия DNSSEC от 2005 года, так что за 15 лет.

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Ну в целом и я об том же - просто вместо "лень и отсутствие мотивации" я сказал "делать дополнительные приседания с непонятным бизнес-эффектом". Стоит эта задача в планах у провайдера с приоритетом "P3 - future", без специального пенделя никто заморачиваться не станет. К тому же, как и у любой сложной технологии, полагаю там есть свои подводные камни - например, специалист, способный отравить кэш и воспользоваться этим, возможно сможет и подобрать соль к ключу для шифрования.

С IPv6 ситуация похожая, но тут мне видится еще и своя специфика - в мире упал спрос с сайты типа "я и моя собака" (соответствующие пользователи перебрались во всякие ЖэЖэшечки и прочие соц-сети), и как следствие упал спрос на "белые" IP. Опять же, IPv6 раньше активно продвигал Китай, которому остро не хватало выделенных ему IPv4 сетей. Но потом они этот вопос кардинально порешали - сайт в Китае требует специальной регистрации и проверки у государства, все явки-пароли (и на всякий случай фаберже) требуется сдать на хранение ответственным товарищам. Поэтому большинство китайских сайтов - это по сути статичный landing page, с сылкой на приложение, которое можно купить-установить через WeChat. Таких можно держать сотнями на одном shared hosting'е.

Аватар пользователя vvelichko
vvelichko(12 лет 6 месяцев)

Из глобальных проблем, которые упоминались в связи с «законом о суверенном интернете» - а что будет, если на корневых NS серверах вообще запретят делегацию зоны .ru? Тогда, теоретически, где-​то через 24 часа протухнут все кэши никто не сможет достучаться до любого домена в этой зоне. На практике же, государство может у себя поднять несколько «зеркал» корневых серверов и использовать их на уровне магистральных интернет провайдеров. Этой весной вроде собирались тестировать подобный сценарий, чем дело кончилось – я не знаю, не следил.

 

на территории россии уже много лет пяток корней размещается. рассказы некоторых интересантов про "пендосы отключат интернет" суть есть божья роса.

Аватар пользователя monk
monk(12 лет 4 месяца)

Из глобальных проблем, которые упоминались в связи с «законом о суверенном интернете» - а что будет, если на корневых NS серверах вообще запретят делегацию зоны .ru? Тогда, теоретически, где-​то через 24 часа протухнут все кэши никто не сможет достучаться до любого домена в этой зоне. На практике же, государство может у себя поднять несколько «зеркал» корневых серверов и использовать их на уровне магистральных интернет провайдеров.

Судя по https://root-servers.org/ уже есть 6 в Москве и 1 в Екатеринбурге.

Хуже то, что все сайты зоны ru в таком случае станут недоступны из-за рубежа.

Аватар пользователя И-23
И-23(8 лет 9 месяцев)

Неполно, однако.
Сразу после указания на склонность провайдеров к блокировке стандартных DNS портов автору следовало бы пройти на три буквы (в направлении DoH).
Но он этого не сделал.
А оттуда тянется интересная ниточка про унификацию.

Аватар пользователя Karbafoz
Karbafoz(5 лет 5 месяцев)

Я рад, что вы знаете, что такое DNS over HTTPS и даже, возможно, DNS over TLS.

А это ничего, что для DNS over HTTPS нужно установить это самое HTTPS соединение, что в свою очередь требует резолва домена? Насколько я понимаю, DoH используется для скрытия DNS траффика от прослушки/подмены (в отличие от DNSSEC, который защищает только от подмены). Для того, чтобы обойти блокировку DNS траффика провайдером, мне проще проложить SSH туннельчик на виртуальную машинку в Амазоне и гонять DNS траффик через неё.

Вообщем, это пока всё рюшечки, не вижу смысла загромождать этим и так распухшую статью.

Вот про что я действительно забыл написать, это про WHOIS сервера и трансфер доменов между регистрарами - исправлю в следующей статье, буде таковая.