Браузер инициирует dns запрос
Обновлено: 06.07.2024
В предыдущих статьях мы рассказали, как придумали доменные имена и кто контролирует их работу. Сегодня узнаем, как браузер понимает, где находится сайт, когда мы вводим в адресной строке домен.
Из статьи вы узнаете:
Что такое DNS
DNS — это технология, которая помогает браузеру найти правильный сайт по доменному имени.
Вы уже знаете, что компьютеры находят друг друга в интернете по IP-адресам. Чтобы подключиться к серверу с конкретным сайтом, нужно знать его IP-адрес. Похожим образом устроена мобильная связь: чтобы позвонить конкретному человеку, нужно знать его номер.
По такой же логике мы сохраняем важные номера в контакты смартфона. Только в случае с доменами, ничего сохранять не нужно. Мы просто вводим в адресной строке домен, а браузер сам находит IP-адрес нужного сервера и открывает сайт.
ВИДЕО ПО ТЕМЕ:
Прочитать статью — хорошо, а прочитать статью
и посмотреть видео — еще лучше!
Смотрите наше видео о том, что такое домен и IP-адрес сайта
Как это работало раньше
В первые годы интернета доменам присваивали IP-адреса вручную. Их записывали в текстовый файл hosts.txt в таком формате:
По сути это и был список контактов, как в смартфоне. Когда пользователь вводил в адресной строке домен, браузер проверял файл и брал из него IP-адрес.
Главным файлом управлял Стэнфордский исследовательский институт. Чтобы добавить в список новый сайт, нужно было звонить в институт по телефону. После этого все компьютеры в сети должны были скачать обновлённый файл.
Со временем такой подход стал отнимать много времени, так как требовалось вносить всё больше и больше данных, и технологию решили усовершенствовать. Новую систему придумали Пол Мокапетрис и Джон Постел в 1984 и назвали её DNS-протокол. Аббревиатура означала Domain Name System, по-русски — Система доменных имён.
Что такое DNS-сервер
Настройки каждого домена в интернете хранятся в текстовых файлах на DNS-серверах.
DNS-сервер — это специальный компьютер, который хранит IP-адреса сайтов. Основные функции сервера DNS — выдавать браузеру адрес сайта по доменному имени и кэшировать DNS-записи домена. То есть сервер DNS простыми словами — это всё та же «книга контактов», тот же файл hosts.txt, только больших масштабов.
Когда вы открываете в браузере сайт, в поиске IP-адреса домена обычно участвуют несколько DNS-серверов:
Локальный DNS-сервер вашего интернет-провайдера. Браузеры используют DNS-сервер провайдера, чтобы с его помощью узнать IP-адрес сервера, где находится сайт. Для этого в каждом браузере есть специальная программа — DNS-клиент. Вместо серверов вашего провайдера может быть любой другой публичный DNS-сервер, если вы укажете его в сетевых настройках. Например, вместо DNS-серверов интернет-провайдера можно использовать публичные серверы DNS от Google.
DNS-сервер верхнего уровня. DNS-серверы верхнего уровня содержат информацию о DNS-зоне и называются корневыми. Они выдают по запросу DNS-серверы доменов первого уровня, например, COM, UA, ORG, NET, ONLINE. Корневыми серверами управляют разные организации. Впервые такие DNS-серверы появились в Северной Америке, но со временем их количество росло и они появлялись в других странах. Сейчас есть 13 основных DNS-серверов верхнего уровня и множество реплик.
DNS-сервер, который отвечает за домен и где хранятся записи доменного имени. Адреса DNS-серверов владельцу домена обычно приходится указывать вручную — их присылает хостинг-провайдер. Например, наши публичные DNS-серверы — dns1.hostiq.ua и dns2.hostiq.ua.
Как браузер находит IP-адрес домена
Разберёмся пошагово, как браузер понимает, где находится сайт, когда мы вводим в адресной строке домен:
Шаг 4 Локальный DNS-сервер получает IP-адрес одного из этих DNS-серверов и обращается к нему. Этот DNS-сервер знает нужный IP-адрес и отправляет его локальному DNS-серверу.
Шаг 5 Локальный DNS-сервер получает нужный IP-адрес и отправляет его браузеру.
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
Что такое DNS?
Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
Пространство имен, которое сопоставляет адреса и уникальные имена, может быть организовано двумя путями: плоско и иерархически. В первом случае имя назначается каждому адресу и является последовательностью символов без структуры, закрепленной какими-либо правилами. Главный недостаток плоского пространства имен – оно не может быть использовано в больших системах, таких как интернет, из-за своей хаотичности, поскольку в этом случае достаточно сложно провести проверку неоднозначности и дублирования.
Сопоставление имен
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
Кто управляет и поддерживает DNS-сервера?
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
Защита от атак
Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер.
«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Заключение
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:
Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.
Оставшаяся часть ответа описывает сам ответ:
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:
Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
CNAME для Heroku или Github
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Архитектура системы доменных имен (DNS) за редким исключением остается неизменной с 1983 года. Каждый раз, когда вы хотите открыть сайт, браузер отправляет запрос с указанием домена на DNS-сервер, который в ответ отправляет необходимый IP-адрес. И запрос, и ответ на него передаются в открытом виде, без какого-либо шифрования. Это значит, что ваш провайдер, администратор сети или злоумышленник c MITM могут не только хранить историю всех запрошенных вами сайтов, но и подменять ответы на эти запросы. Звучит неприятно, не правда ли?
Предлагаю вспомнить несколько реальных историй перехвата и подмены DNS-запросов.
DNS hijacking
Перехват DNS-запросов (DNS hijacking) это не какая-то редкая страшилка, а вполне распространенная практика. Например, среди провайдеров. Обычно это работает следующим образом. Если пользователь пытается перейти на несуществующий сайт, то провайдер перенаправляет его на свою страницу с рекламой. А может и не на свою.
Вы, конечно же, можете отказаться от использования DNS-сервера провайдера и прописать в настройках роутера сторонние решения (например, Google Public DNS или Яндекс.DNS). Но при отсутствии шифрования это никак не решит проблему. Провайдер вполне может вмешаться и здесь, подменив ответ на свой.
Масштабы трояна DNSChanger впечатляют, но бразильцы его переплюнули. 4,5 млн DSL-модемов было взломано в одной только Бразилии в 2011-2012 годах. Для этого было достаточно разослать спам со ссылкой на вредоносную страницу, которая взламывала модем и прописывала новый адрес DNS-сервера. Причем в этот раз мошенники не стали мелочиться с рекламой. На своих подставных DNS-серверах они подменяли адреса для всех крупнейших банков Бразилии.
С домашними и офисными WiFi-роутерами дело обстоит так же печально, как и с бразильскими модемами. Пользователи нередко оставляют заводские логин и пароль на админку, да и за выходом свежих прошивок с исправленными уязвимостями не следит почти никто (кроме читателей Хабра, конечно же). В прошлом году исследователи из Sentrant в своем докладе рассказали о новых случаях взлома роутеров. Мошенники перехватывали обращения к Google Analytics и благодаря этому встраивали на сайты рекламу.
Думаю, с примерами перехвата можно закончить. Вывод тут простой: DNS перехватывают много, на разных этапах и с разной целью.
Во-вторых, вы больше не привязаны к серверу провайдера или настройкам своего роутера. DNSCrypt обращается за адресами напрямую на указанный вами сервер.
До сих пор для применения DNSCrypt пользователям было необходимо установить на компьютер отдельную утилиту. Это не сложно, но без широкого распространения знаний об угрозе и способах ее решения вряд ли стоит рассчитывать на массовое применение технологии.
Поддержка DNSCrypt в Яндекс.Браузере
При этом все запросы в зашифрованном виде будут отправляться на быстрый DNS-сервер Яндекса, который также получил поддержку протокола DNSCrypt. Ограничивать пользователей только одним сервером мы не хотим, поэтому уже в ближайшее время добавим в этом месте возможность выбрать альтернативный DNS-сервер (например, тот же OpenDNS).
И еще кое-что. Подменить IP-адрес на фишинговый можно не только через перехват запроса, но и через самый обычный системный host-файл. Поэтому мы сейчас экспериментируем с запретом использовать системный резолвер в случае недоступности DNS-сервера. Мы понимаем, что включение этой опции по умолчанию может навредить пользователям корпоративных и локальных ресурсов, поэтому пока только наблюдаем и собираем отзывы.
Читайте также: