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)
- со свободной регистрацией: .com, .net, .org, .info, .biz и .name.
- с ограниченной регистрацией: .edu (для образовательных сайтов), .gov (для сайтов государственных организаций США), .mil (для военных организаций США), .int (для международных организаций).
- Еще не так давно 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 часа протухнут все кэши никто не сможет достучаться до любого домена в этой зоне. На практике же, государство может у себя поднять несколько «зеркал» корневых серверов и использовать их на уровне магистральных интернет провайдеров. Этой весной вроде собирались тестировать подобный сценарий, чем дело кончилось – я не знаю, не следил.
Комментарии
объяснять днс без алиасов нет смысла. иначе не понятно , почему я могу попасть на сайт по имени через днс а вот напрямую на IP адрес выйдет далеко не всегда.
Не уверен, что я правильно понял, о каких алиасах идёт речь. Если про CNAME DNS запись (типа считать www.aftershock.news как то же самое, что и просто aftershock.news), то можно её рассматривать как своеобразную A (IP) запись с некоторыми ограничениями. В любом случае, это не даст ответа, почему по IP не всегда до сайта можно достучаться. Я планирую описать это в статье про хостинг - для shared hosting'а это важно.
ну так это напрямую к днс идёт - причем это самый большой вопрос у тех кто не до конца понимает механизм днс
Я так и не понял, про какой алиас идёт речь. Два разных домена могут иметь один IP-адрес (и, соответственно, физически хоститься на одном сервере). Домены, которые обслуживает веб-сервер прописаны у него в конфигурации. Для того, чтобы к сайту был доступ по IP нужно веб-серверу указать, на какой из обслуживаемых сайтов резолвить этот IP (если вообще давать доступ по IP). Где тут алиас?
Норвежское правительство забыли! .gov.no
:) Про норвежцев не скажу, а клиентов с .gov домена за глаза я называл govнюками - такие не забываются: компетенции обычно ниже среднего, а требований больше. Плюс достаточно мерзкая манера общения.
на примере:
ping aftershock.news
64 bytes from 185.112.80.17: icmp_seq=0 ttl=64 time=0.029 ms
зайти по адресу 185.112.80.17 получится, но будете незалогиненным и без https:
а при попытке логина, залогиниться не получится.
вот такой вот пердимонокль и shared hosting тут ни при чем :-)
Так это, вроде, зависит от настройки веб-сервера, который по ip может вообще другие страницы выдавать.
Но ведь это не DNS, а конфигурация веб-сервера :)
Но я кажется начинаю понимать, что ДК под "алиасом" подразумевает - похоже, что это A запись.
так откуда там буква А :)
кстати это тут нужно объяснять как один и тот же физически сайт может иметь два доменных имя, и наоборот одно доменное имя иметь несколько физических мест. это всё делается ДНС записями.
Смею предположить, что логин у вас для безопасности требует принудительный HTTPS, а SSL сертификат, необходимый для установления https соединения выписывается на доменное имя (на IP-адрес сертификат не выдаётся).
:-) А почему на IP адрес можно зайти по http, а на aftershock.news нельзя?
Зайти можно. Но при заходе происходит мгновенный форвард на https://aftershock.news . Цэ настраиваемая фича ВЭБ-сервера..
Потому, что на веб-сервере сконфигурирован редирект с http на https для домена aftershock.news:
На GET запрос по протоколу HTTP веб-сервер на самом деле отдаёт ответ с кодом 301 (перманентный редирект) не сам контент странички с кодом 200 (ok). Этот редирект обрабатывается браузером и идёт повторный запрос на адресс указаный в заголовке "Location": это https://aftershock.news/
Это стандартная практика - используя подобный редирект сейчас рекомендуется где можно переводить с протокола HTTP на HTTPS (а наоборот, с протокола HTTPS на HTTP скидывать соединение, скажем так, не рекомендуется).
Для домена включен редирект с http на https
но почему то он есть :)
Это самоподписанный сертификат - несчитово. Большинство браузеров на него сругнутся. Нормальный сертификат на IP-адрес вам не выпишут.
ну ну ну не выпишут. ещё как выпишут, только на компанию OV типа.
правда он будет "несколько дороже" :)
Чтобы другим тоже было понятно, о чем речь - сертификаты бывают трёх типов:
Так вот, доменное имя входит во все три типа. Для OV сертификата в качестве бонуса могут дать wildcard сертификат сразу для всех поддоменов, например *.aftershock.news - такой сертификат годится как для сайта и aftershock.news так и для m.aftershock.news. Еще приятным бонусом будет информация о организации в строке браузера. Цена на них не так, чтобы прям совсем заоблачная - по сравнению с DV отличается в диапазоне два раза - на порядок.
Совсем бездоменных (кроме self-signed) сертификатов на практике я не встречал, хотя могу допустить их существование. Цифровая подпись используется не только для HTTPS. Например, для цифровой подписи инсталлера какого-нибудь ПО доменное имя организации не важно. Зато когда вы запустите этот установщик система вам скажет "Вы точно хотите запустить установку этого ПО? Publisher: Такая-то Организация, ООО", где название "Такая-то Организация, ООО" возьмётся из сертификата подписи.
Для обычного хостинга чаще всего используют DV сертификаты, банки и прочие серъёзные структуры - EV.
Таким способом вы заходите на 80 порт . Поставьте двоеточие после и 443 и зайдёте на https
Напишите лучше статью, где лежат и как править файлы hosts в винде или на линуксе. У вас это явно получится)
Не уверен, что прям на статью наберётся :) Исторически, в файлике hosts руками велась база соответствй Domain -> IP до изобретения DNS. Но таки да, данные в текстовом файле hosts обычно имеют приоритет над DNS (но не всегда).
Linux: /etc/hosts
Windows: %SystemRoot%\System32\drivers\etc\hosts (обычно C:\Windows\System32\drivers\etc\hosts)
Директива хостс имела раньше (не знаю как сейчас) очень сильную дырку: если ее не прописать на ключевой сайт, то можно было сделать копию сайта (который по сути все страницы выкачивает с основного сайта, например динамически) и в hosts прописать свой домен. Для поисковиков (ЯНдекс, Гугл) ключевым становился левый сайта. Ну и трафик уходил вместе со всеми параметрами на левый сайт.
Копию размещаешь в какой нибудь Прибалтике, служба поддержки которых принципиально игнорит запросы из России и куча головняка для владельцев основного сайта. (Самый простой способ прописать хостс и заблокировать адрес с которого идет самый активный трафик, но до этого догадывались максимум 20% администраторов сайтов).
P.S.: это рассуждаю не с точки теоретика, но и не конкретного практика.
Это имеет отношение скорее к протоколам HTTP и HTTPS, чем к DNS.
Разные доменные имена могут иметь один ip адрес. HTTP сервер уже по имени (которое браузер передаёт в http-запросе) определяет, какой сайт ему отдавать.
Если запросить по ip-адресу, то будет отдан сайт по умолчанию.
на сервере есть ДНС записи, которые и управляют доступом. никого особо не интересует как там работают ДНС сервера, а вот как управлять сайтом через ДНС рекордс - вот что очень всех интересует.
потому что я полдня объяснял одному как у меня домен второго уровня на одном IP а домен третьего уровня на этом домене на другом сервере и другом провайдере.
Дык тут же проблемы не с DNS или с HTTPS, а банально с неумением в логику.
Современное поколение этим зало страдает, но как это можно исправить в статье про DNS?
Я вот даже представить себе это не могу...
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
Спасибо, интересная но очень узко специализированная статья . Хабра из АШа не выйдет ;)
Велкам! АШ на лавры Хабра не претендует, а лично меня к написанию побудило два момента:
Он уже десятилетие поддерживается всеми популярными серверами DNS. Единственное препятствие — то же, что и при https: нужен сертификат. А это дополнительные расходы.
Технически - да. DNSSEC записи поддреживаются начиная с BIND 9, а это аж 2000 год (к слову, заказчик - минобороны США).
Практически же сейчас DNSSEC пока используется не часто. И дело не только в платном сертификате (насколько я знаю, сертификат вообще не используется, а просто две пары ключей, кторые можно сгенерировать самостоятельно) - нужны дополнительные приседания:
Провайдерам этим заморачиваться недосуг, а простым смертным - не всегда хватает квалификации. Риски весьма условные, а возни много. Но это пока, общий мировой тренд идёт в сторону усиления безопасности и рано или поздно DNSSEC будет внедрен повсеместно.
Провайдерам как раз тривиально: dnssec-enable yes; dnssec-validation auto;
Владельцам зон не намного сложнее: галочка в интерфейсе или скрипт на полдюжины команд. На фоне остальной фигни, которую приходится запихивать в DNS — это вообще ни о чём.
Тогда как вы объясните, что за 20 лет технология так и не стала массовой?
Потому же, почему IPv6 за 25 лет не стал массовым. Лень и отсутствие мотивации для безопасности. Для внедрения HTTPS много сделали провайдеры, втыкающие рекламу в проходящий поток. А в чём опасность отравления DNS — не очевидно. Завернуть трафик на другой сервер? Так это пройдёт только с HTTP и не пройдёт с HTTPS.
P.S. Актуальная версия DNSSEC от 2005 года, так что за 15 лет.
Ну в целом и я об том же - просто вместо "лень и отсутствие мотивации" я сказал "делать дополнительные приседания с непонятным бизнес-эффектом". Стоит эта задача в планах у провайдера с приоритетом "P3 - future", без специального пенделя никто заморачиваться не станет. К тому же, как и у любой сложной технологии, полагаю там есть свои подводные камни - например, специалист, способный отравить кэш и воспользоваться этим, возможно сможет и подобрать соль к ключу для шифрования.
С IPv6 ситуация похожая, но тут мне видится еще и своя специфика - в мире упал спрос с сайты типа "я и моя собака" (соответствующие пользователи перебрались во всякие ЖэЖэшечки и прочие соц-сети), и как следствие упал спрос на "белые" IP. Опять же, IPv6 раньше активно продвигал Китай, которому остро не хватало выделенных ему IPv4 сетей. Но потом они этот вопос кардинально порешали - сайт в Китае требует специальной регистрации и проверки у государства, все явки-пароли (и на всякий случай фаберже) требуется сдать на хранение ответственным товарищам. Поэтому большинство китайских сайтов - это по сути статичный landing page, с сылкой на приложение, которое можно купить-установить через WeChat. Таких можно держать сотнями на одном shared hosting'е.
на территории россии уже много лет пяток корней размещается. рассказы некоторых интересантов про "пендосы отключат интернет" суть есть божья роса.
Судя по https://root-servers.org/ уже есть 6 в Москве и 1 в Екатеринбурге.
Хуже то, что все сайты зоны ru в таком случае станут недоступны из-за рубежа.
Неполно, однако.
Сразу после указания на склонность провайдеров к блокировке стандартных DNS портов автору следовало бы пройти на три буквы (в направлении DoH).
Но он этого не сделал.
А оттуда тянется интересная ниточка про унификацию.
Я рад, что вы знаете, что такое DNS over HTTPS и даже, возможно, DNS over TLS.
А это ничего, что для DNS over HTTPS нужно установить это самое HTTPS соединение, что в свою очередь требует резолва домена? Насколько я понимаю, DoH используется для скрытия DNS траффика от прослушки/подмены (в отличие от DNSSEC, который защищает только от подмены). Для того, чтобы обойти блокировку DNS траффика провайдером, мне проще проложить SSH туннельчик на виртуальную машинку в Амазоне и гонять DNS траффик через неё.
Вообщем, это пока всё рюшечки, не вижу смысла загромождать этим и так распухшую статью.
Вот про что я действительно забыл написать, это про WHOIS сервера и трансфер доменов между регистрарами - исправлю в следующей статье, буде таковая.