Зачем придумали dns: что это простыми словами, зачем нужна и как работает DNS-сервер | Дропшиппинг

Содержание

Давайте уже разберемся в DNS / Хабр

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com, и получает в ответ 1.2.3.4.

Базовые штуки

Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net, который хостится на машине web01.bugsplat.info. Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).

Давайте взглянем на маппинг между именем и адресом:

$ dig web01.bugsplat.info

Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

;; QUESTION SECTION:
;web01.bugsplat.info.       IN  A

dig по-умолчанию запрашивает A-записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4-адрес. Есть эквивалент для IPv6-адресов — AAAA. Давайте взглянем на ответ:

;; ANSWER SECTION:
web01.bugsplat.info.    300 IN  A   192.241.250.244

Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A: 192.241.250.244. Число 300 это TTL, или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet. Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA’s DNS Parameters.

Оставшаяся часть ответа описывает сам ответ:

;; Query time: 20 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:01:16 2013
;; MSG SIZE  rcvd: 56

В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192. 168.1.1), на какой порт стучался dig (53, DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.

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

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig‘у, если бы информация не был закэширована:

$ dig +trace web01.bugsplat.info
; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info
;; global options: +cmd
.            137375  IN  NS  l.root-servers.net.
.           137375  IN  NS  m.root-servers.net.
.           137375  IN  NS  a.root-servers.net.
.           137375  IN  NS  b.root-servers.net.
.           137375  IN  NS  c.root-servers.net.
.           137375  IN  NS  d.root-servers.net.
.           137375  IN  NS  e.root-servers.net.
.           137375  IN  NS  f.root-servers.net.
.           137375  IN  NS  g.root-servers.net.
.           137375  IN  NS  h.root-servers.net.
.           137375  IN  NS  i.root-servers.net.
.           137375  IN  NS  j.root-servers.net.
.           137375  IN  NS  k.root-servers.net.
;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms
info.           172800  IN  NS  c0.info.afilias-nst.info.
info.           172800  IN  NS  a2.info.afilias-nst.info.
info.           172800  IN  NS  d0.info.afilias-nst.org.
info.           172800  IN  NS  b2.info.afilias-nst.org.
info.           172800  IN  NS  b0.info.afilias-nst.org.
info.           172800  IN  NS  a0.
  info.afilias-nst.info.
;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms
bugsplat.info.      86400   IN  NS  ns-1356.awsdns-41.org.
bugsplat.info.      86400   IN  NS  ns-212.awsdns-26.com.
bugsplat.info.      86400   IN  NS  ns-1580.awsdns-05.co.uk.
bugsplat.info.      86400   IN  NS  ns-911.awsdns-49.net.
;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms
web01.bugsplat.info.    300 IN  A   192.241.250.244
bugsplat.info.      172800  IN  NS  ns-1356.awsdns-41.org.
bugsplat.info.      172800  IN  NS  ns-1580.awsdns-05.co.uk.
bugsplat.info.      172800  IN  NS  ns-212.awsdns-26.com.
bugsplat.info.      172800  IN  NS  ns-911.awsdns-49.net.
;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms

Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info? Так вот, точка . это важная деталь, и она означает корень иерархии.

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

Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS-записи. NS-запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS-записи для вас.

В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A-запись для web01.bugsplat.info. Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!

$ dig -x 192.5.5.241
; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;241.   5.5.192.in-addr.arpa.  IN  PTR
;; ANSWER SECTION:
241.5.5.192.in-addr.arpa. 3261  IN  PTR f.root-servers.net.

Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR, которая соединяет IP и хост, в данном случае — f.root-servers.net.

Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS-серверов. Он отвечает за домен верхнего уровня info. dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info, и получает в ответ еще один набор NS-серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info.. И, наконец, получает ответ!

Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер.

Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com, net, org, и т.д. тоже обычно сильно закэшированы.

Другие типы

Есть еще несколько типов, о которых стоит знать. Первый это MX. Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX

для petekeen.net:

$ dig petekeen.net mx
; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;petekeen. net.          IN  MX
;; ANSWER SECTION:
petekeen.net.       86400   IN  MX  60 web01.bugsplat.info.
;; Query time: 272 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:33:43 2013
;; MSG SIZE  rcvd: 93

Заметьте, что MX-запись указывает на имя, а не на IP-адрес.

Еще один тип, который вам скорее всего знаком, это CNAME. Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

$ dig www.petekeen.net
; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.petekeen.net.      IN  A
;; ANSWER SECTION:
www.petekeen.net.   86400   IN  CNAME   web01.bugsplat.info.
web01.bugsplat.info.    300 IN  A   192.241.250.244
;; Query time: 63 msec
;; SERVER: 192.168.
  1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:36:58 2013
;; MSG SIZE  rcvd: 86

Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info. Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX, ни A, ни NS, ничего.

Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME, также валидны для CNAME. В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.

Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net, потому что обычно там нужны другие записи, например, MX.

Запросы к другим серверам

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

$ dig www.petekeen.net @8.8.8.8

Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2.

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Часто нужно сделать редирект домена iskettlemanstillopen.com

на www.iskettlemanstillopen.com. Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:

Символ @ означает корневой домен iskettlemanstillopen. com. Давайте посмотрим на запись A у этого домена:

$ dig iskettlemanstillopen.com
;; QUESTION SECTION:
;iskettlemanstillopen.com.  IN  A
;; ANSWER SECTION:
iskettlemanstillopen.com. 500   IN  A   192.64.119.118

Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:

$ curl -I iskettlemanstillopen.com
curl -I iskettlemanstillopen.com
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Jul 2013 23:53:21 GMT
Content-Type: text/html
Connection: keep-alive
Content-Length: 154
Location: http://www.iskettlemanstillopen.com/

CNAME для Heroku или Github

Взгляните на скриншот выше. На второй строке там CNAME. В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.

$ heroku domains
=== warm-journey-3906 Domain Names
warm-journey-3906. herokuapp.com
www.iskettlemanstillopen.com

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME. См. документацию.

Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info. Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

$ dig randomapp.web01.bugsplat.info
;; QUESTION SECTION:
;randomapp.web01.bugsplat.info. IN  A
;; ANSWER SECTION:
randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info.
web01.bugsplat.info.    15  IN  A   192.241.250.244

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

RFC 1034: Domain Names — Concepts and Facilities
RFC 1035: Domain Names — Implementation and Specification

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

система доменных имен. Что такое DNS для Чайников

В интернете для компьютеров используются ip-адреса, но людям с ip-адресами работать неудобно. Например, вряд ли вы скажете, что означает вот этот ip-адрес 77.88.55.66, а если адрес в формате ipv6 (2a02:6b8:a::a), то его запомнить еще сложнее. Для людей гораздо удобнее работать с символьными именами, например www.yandex.ru, вполне понятное имя для людей, сразу можно понять что это веб-сервер компании Яндекс.

Зачем нужен DNS

Система доменных имен позволяет использовать вместо ip-адресов понятные для человека символьные имена компьютера, она также позволяет по этому символьному имени определить ip-адрес.

Важным преимуществом системы DNS является возможность изменять сетевую инфраструктуру, например, если компания Яндекс захочет перенести свой веб-сервер на другой компьютер, у которого будет другой ip-адрес, то ничего страшного не произойдет, так как доменное имя не изменится. Люди будут обращаться по тому же самому доменному имени, которые теперь будет отображаться в другой ip-адрес.

DNS по английский Domain Name System — это протокол прикладного уровня стека протоколов tcp-ip.

Утилита nslookup

Узнать ip-адрес компьютера по его доменному имени можно с помощью утилиты nslookup.

Здесь представлен пример её использования:

nslookup www.yandex.ru
Сервер: dc1.imm.uroran.ru
Address: 172.19.132.29
Не заслуживающий доверия ответ:
www.yandex.ru
Addresses: 2a02:6b8:a::a
77.88.55.55
77.88.55.66
5.255.255.5
5.255.255.55
Другие утилиты (Linux)
Hots
Dig

Пишем nslookup и интересующие нас доменное имя (www.yandex.ru). Получаем ответ, что доменному имени www.yandex.ru соответствует сразу четыре ip-адреса (77.88.55.55 и так далее). Также есть еще один адрес ipv6 (2a02:6b8:a::a).

Для того чтобы попасть на веб-сервер Яндекса, можно подключиться к любому из представленных выше ip- адресов.Здесь мы видим еще одно преимущество системы DNS, если на наш сервер обращается большое количество клиентов, который один компьютер обработать не способен, мы можем создать несколько серверов и в систему DNS прописать, что он наш домен и обслуживает несколько серверов.

Для того чтобы получить доступ к веб-серверу компании Яндекс, можно обратиться к любому из этих серверов. Утилитой nslookup преимущественно используется под Windows, в Linux и Unix используются другие утилиты, такие как Host и Dig. Таким образом система DNS по доменному имени компьютера позволяет определить его ip-адрес, вопрос заключается в том, как это удается сделать в масштабах всей сети интернет, в которой огромное количество компьютеров и постоянно происходят изменения.

Файл /etc/ hosts

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

Этот файл в системах Unix и Linux называются Linux/Unix/etc/hosts, в Windows похожий файл тоже есть, только он находится по другому пути. Windows: C:\Windows\System32\drivers\etc\hosts. Такой подход работал на заре создания сетей tcp-ip, когда компьютеров было мало, все компьютеры и их ip-адреса можно было перечислить в одном файле, который хранился на центральном сервере имен, остальные компьютеры подключались к этому серверу и загружали файл.

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

Особенности DNS

При создании системы DNS было решено что это принципиально децентрализованная система. Децентрализованная как на техническом уровне, то есть нет одного сервера на котором хранятся все имена всех компьютеров в сети, так и на административном уровне. Название компьютеров делится на отдельные части, домены, и за имена компьютеров в разных доменах отвечают разные организации. Также для системы DNS очень важна надёжность, поэтому серверы DNS дублируются.

Структура доменного имени

Вместо обычных имен компьютеров, которые состоят из одного слова в системе DNS используются доменные имена. Имя компьютера состоит из нескольких частей, которые отделены друг от друга точками. Например, веб-сервер сайта о Мобильной связи и Технологиях имеет следующие имя www.zvondozvon.ru. Имя состоит из следующих частей ru это домен верхнего уровня, следующий домен отделён от него точкой zvondozvon домен второго уровня, и последний компонент www это имя компьютера в домене второго уровня.

Корневой домен

Важным элементом доменного имени, которое обычно не пишут, является корневой домен, он указывается точкой в конце. Если вы не укажете точку, то ничего страшного не произойдет, она подразумевается в конце каждого доменного имени.

Дерево доменных имен

Доменные имена образуют дерево. Корнем дерева является корневой домен, который представлен точкой. Затем идут домены верхнего уровня, которые бывают трех типов:

Домены для различных типов организаций, которые используются, как правило внутри США (org, com, net). Домен org для некоммерческих организаций, com для коммерческих организаций, net для организации связанных с компьютерными сетями, есть также и другие домены.
Тип доменов верхнего уровня, домены для стран. Каждая страна имеет свой домен. Домен Россия ru, домен Великобритании uk, и относительно недавно появились новые типы доменов верхнего уровня в которых можно использовать не только символы английского алфавита. Для России это домен рф.
Затем идут домены второго уровня, например cisco.com, yandex.ru или яндекс.рф русскими буквами.
На третьем уровне могут находиться, как домены следующего уровня их называют поддомены или адреса компьютера в домене второго уровня. Например, в домене yandex.ru есть компьютеры с адресами www.yandex.ru веб-сервер компании yandex, maps.yandex.ru сервер яндекс карт, такси.yandex.ru сервер яндекс такси и большое количество других серверов.

Доменная зона

Важным понятием в системе DNS является доменная зона. Это запись адресов всех компьютеров и всех поддоменов в некотором домене.

Корневая доменная зона содержит записи всех поддоменов первого уровня (org com net ru uk рф). Зона ru содержит записи всех доменов второго уровня (yandex urfu), зона urfu.ru записи всех поддоменов и всех компьютеров в домене urfu, и вот здесь еще показаны две отдельные зоны для разных институтов urfu, институт естественных наук (ins) и институт математики и компьютерных наук (imkn). Эти зоны содержат DNS-записи, о компьютерах соответствующих институтов.

Доменная зона является некоторым аналогом файла itc/hosts только в ней содержится не вся информация об именах компьютерах в сети, а некоторый ее фрагмент. Доменные зоны распределены по серверам DNS. Одну и ту же доменную зону может обслуживать несколько серверов DNS.

Например, корневую зону обслуживают больше всего серверов, так как к ним больше всего запросов. Все корневые серверы DNS содержат одинаковые записи. Зону ru также обслуживает несколько серверов DNS, у которых одна и та же база данных записи и доменов второго уровня.

Необязательно иметь выделенные DNS сервер для каждой доменной зоны, например DNS-сервер urfu может обслуживать зоны urfu.ru и ins.urfu.ru, а институт математики и компьютерных наук может иметь свой выделенный DNS сервер, который будет обслуживать зону imkn.urfu.ru.

Важным понятием в системе DNS является делегирование. Например DNS-сервер urfu отвечает за зону urfu.ru, но только часть информации об этой зоне хранится непосредственно на этом сервере, то что относится к urfu.ru и ins.urfu.ru. А для зоны imkn.urfu.ru создан отдельный сервер, таким образом сервер urfu.ru делегирует полномочия управления под доменом imkn. urfu.ru другому серверу. Чтобы было возможно делегирование на DNS сервере urfu.ru делаются соответствующие конфигурационные записи, которые указывают на DNS-сервер ответственный за зон, в нашем случае imkn.urfu.ru.

Инфраструктура DNS

Инфраструктура системы доменных имен состоит из следующих компонентов.

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

Распределение доменных имен

Точно так же как с ip-адресами, нельзя использовать такие DNS имена, какие вам вдумаются. Распределением доменных имен занимаются специализированные организации, которые называются регистраторами. Регистратором корневого домена является организация и ICAN, та же самая организация которая распределяет ip-адреса. С ICAN взаимодействует регистраторы зон первого уровня, например, org, com или рф, и которые занимаются распределением доменов второго уровня.

Зоны ru и рф

Для российской зоны ru до 2001 года был всего один регистратор доменных имен, это Российский Научно-Исследовательский Институт развития общественных сетей. Но в 2001 году регистраторов стало несколько и база данных зоны ru стала распределенной. Для координации работы регистраторов была создана некоммерческая организация Координационный центр национального домена сети Интернет.

Регистрация домена

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

Например у меня есть домен для моего персонального сайта в зоне ru, nurmaganov.ru и домен моего сайта о мобильной связи и технологиях zvondozvon.ru.

Видео о выборе доменного имени для сайта

Здесь я оставлю свою видео о том, как нужно выбирать доменное имя, если Вы хотите создать свой собственный сайт.

История

DNS. Когда и зачем был создан DNS?

Мы много говорили о DNS. Как это работает и все, что связано с этим. Но мы никогда не уделяли время истории DNS. Что привело к необходимости DNS? Кто был великим человеком, который его изобрел?

Содержание

До Интернета и DNS

Вернемся во времена, когда Интернета не существовало. Да, было такое время, даже если вы его не помните. Шла холодная война, США много вкладывали в оборону и технологии. В 1958, при президенте Эйзенхауэре, было запущено ARPA (Агентство перспективных исследовательских проектов). Это был большой шаг для американской науки и ответ на советские достижения (Спутник-1, 1957).

В 60-е годы САРП становилась все сильнее и больше. Он получил больше оборудования, включая компьютер Q-32. Идея компьютерных сетей начала завоевывать популярность.
MIT (Массачусетский технологический институт) тесно сотрудничал с ARPA, и в создании сети был достигнут серьезный прогресс. Была представлена идея коммутации пакетов, и был проект подключения Q-32 к компьютеру TX-2 (компьютер MIT) под руководством Ларри Робертса. Позже в 1966, тот же парень опубликовал статью об ARPANET — сети с коммутацией пакетов, использующей протокол TCP/IP. Это было похоже на Интернет, но не масштабируемо. Прошло еще несколько лет, прежде чем это стало реальностью.

В 70-е годы в мире наблюдался быстрый рост количества компьютеров. Появлялись разные сети и даже какие-то международные проекты. Было много разработок, и было создано множество различных протоколов и программ. Первые коммерческие программы электронной почты появились в 1976.

Через год была представлена первая 3-х сетевая система. Пакетное радио, ARPANET и SATNET работали вместе!

Технический прогресс шел так быстро, но у людей начались серьезные проблемы с бухгалтерией. Не было единой сети, а была система сетей. Потребность в глобальном решении была острой, и вот DNS!

Начало истории DNS

Изначально процесс назначения адресов был ручным. Компьютеры и связанные с ними имена хостов и адреса были добавлены в файл HOSTS.TXT путем обращения в Сетевой информационный центр SRI (NIC) по телефону в рабочее время. По мере роста сети Фейнлер представил каталог WHOIS на сервере сетевой карты, что позволило получить информацию о ресурсах и контактах.

Задача по упрощению сети была поручена Полу Мокапетрису . Перед ним и его командой стояла задача создать более удобную сеть, в которой людям не нужно было бы запоминать IP-адрес каждого компьютера. Раньше существовал централизованный текст HOSTS.TXT, отображающий текущие сайты. Но, благодаря растущему количеству сайтов, файл также становился больше, и возникла острая потребность в децентрализованной модели.

Пол Мокапетрис : «Он был создан, чтобы люди могли использовать имена для чего угодно. Но нам нужно было придумать, как организовать распределение доменных имен и как обеспечить, чтобы система могла вместить разнообразие без ненужных ограничений».

DNS была создана в 1983 году и стала одним из первых интернет-стандартов в 1986 году (после создания Инженерной группы Интернета IETF). В 1984 году студенты Калифорнийского университета в Беркли разработали первую реализацию сервера имен Unix, известную как BIND (Домен имен в Интернете Беркли). На протяжении многих лет различные разработчики и организации, в том числе Консорциум интернет-систем (ISC), вносили свой вклад в поддержку и развитие BIND. 19 ноября87, RFC 1034 и RFC 1035 заменили исходные спецификации DNS от 1983 года. Они описывают всю функциональность протокола и включают типы данных, которые он может передавать.

RFC 1034 и RFC 1035: Определение протокола DNS

RFC 1034 и RFC 1035 имеют огромное значение в мире DNS, поскольку они определяют самые основы протокола DNS. RFC 1034, опубликованный в 1983 году и озаглавленный «Доменные имена — концепции и возможности», содержит всесторонний обзор архитектуры DNS и ее ключевых компонентов. В нем изложены основные понятия и операции DNS, введены такие термины, как доменные имена, серверы имен и записи ресурсов. Создавая стандартизированную структуру, RFC 1034 обеспечивает совместимость и согласованность всей инфраструктуры DNS. Он служит жизненно важным справочником для внедрения систем DNS и понимания основных принципов, регулирующих разрешение имен в Интернете.

Дополняющий RFC 1034 документ RFC 1035, опубликованный в 1986 г. и озаглавленный «Доменные имена — реализация и спецификация», более подробно рассматривает технические аспекты протокола DNS. Он предоставляет подробные спецификации для форматов сообщений, типов данных и структуры пакетов DNS. RFC 1035 описывает конкретные операции и алгоритмы, используемые при преобразовании доменных имен в IP-адреса и наоборот. Он также представляет механизмы кэширования, которые улучшают производительность DNS за счет уменьшения потребности в повторных запросах. Вместе эти два документа составляют основу протокола DNS, обеспечивая согласованное поведение и облегчая беспрепятственную связь между преобразователями DNS, серверами имен и клиентами.

Значение RFC 1034 и RFC 1035 выходит за рамки их технических спецификаций. Они представляют собой совместные усилия экспертов и энтузиастов, которые сформировали ранний Интернет и заложили основу для современных сетей. Эти документы продолжают служить жизненно важным ресурсом для разработчиков, сетевых администраторов и исследователей, обеспечивая целостность и функциональную совместимость экосистемы DNS.

DNS В настоящее время

За время своего существования DNS претерпела различные обновления. Первым важным из них было введение механизмов NOTIFY и Incremental Zone Transfer IXFR. Теперь серверы могли обновляться динамически. С помощью NOTIFY главный сервер может «сообщить» подчиненным серверам, что у него есть обновление, которым он должен поделиться. Раньше рабы нужно было периодически проверять. А второму IXFR, теперь этим подчиненным серверам, не нужно было обновлять весь файл зоны, они могли обновлять только изменения.

Сегодня DNS имеет иерархическую и децентрализованную структуру. Система DNS состоит из нескольких взаимосвязанных серверов, которые совместно хранят записи DNS и управляют ими. Эти серверы подразделяются на различные типы, включая корневые серверы, серверы доменов верхнего уровня (TLD) и авторитетные серверы имен. Когда пользователь вводит доменное имя в своем веб-браузере, его устройство инициирует процесс поиска DNS, чтобы найти соответствующий IP-адрес.

Служба DNS развивалась с годами, чтобы соответствовать растущим требованиям Интернета. Он включает в себя различные улучшения, в том числе функции безопасности, такие как DNSSEC (расширения безопасности системы доменных имен), для защиты от ядовитых атак DNS. Кроме того, технологии на основе DNS, такие как балансировка нагрузки DNS и сети доставки контента, были разработаны для оптимизации производительности веб-сайта и обеспечения высокой доступности.

Будущее DNS: тенденции и инновации, на которые следует обратить внимание

По мере развития технологий приоритетность скорости и безопасности веб-сайтов становится краеугольным камнем оптимальной производительности DNS. В результате компании вкладывают значительные средства в новые технологии, чтобы улучшить взаимодействие с пользователем и обеспечить надежность.

Движение за переход на DNS через HTTPS набирает обороты, поскольку это обеспечивает дополнительную защиту для снижения угрозы киберпреступлений и сохранения конфиденциальности пользователей. Еще одна новая тенденция — использование DNS вместо TLS, поскольку компании стремятся укрепить доверие и повысить безопасность. Добавляя дополнительный уровень защиты, DoH и DoT усложняют злоумышленникам перехват или манипулирование DNS-запросами, обеспечивая более безопасный и надежный просмотр для пользователей. Кроме того, следует обратить внимание на обнаружение служб на основе DNS, что позволяет ИТ-специалистам использовать DNS или протоколы, связанные с DNS, для автоматического сопоставления или рабочих нагрузок.

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

Заключение

Система доменных имен (DNS) прошла долгий путь с момента своего скромного появления в виде централизованного текстового файла HOSTS.TXT, отображающего постоянно растущее число сайтов в Интернете. Благодаря разработкам Ларри Робертса и Пола Мокапетриса DNS была создана для упрощения работы в сети. С тех пор мы видели различные обновления, такие как механизмы NOTIFY и DNSSEC, для повышения производительности и безопасности. Поскольку мир технологий продолжает развиваться, будущее DNS должно оставаться в центре нашего внимания.

(Посетили 31 463 раза, 1 посещение сегодня)

Белослава Петрова

Привет, я Белла. Я специалист по цифровому маркетингу в ClouDNS. У меня есть степень бакалавра экономики и финансов Лилльского университета, что помогает мне быть в курсе последних тенденций цифрового маркетинга. Я увлечен созданием полезного цифрового маркетингового контента, который обучает, увлекает и привлекает читателей. Когда я не создаю контент и не изучаю цифровые тренды, я путешествую, открываю новые места и запечатлеваю прекрасные моменты на фотографиях.

Резюме

Понравилась эта статья? Не забудьте поделиться.

Теги: ARPA, ARPANET, DARPA, DNS, рождение DNS, история DNS, Первый DNS, Интернет, Сеть, сеть, Пол Мокапетрис, Начало DNS Последнее изменение: 31 мая 2023 г.

Празднование 30-летия системы доменных имен (DNS) в этом месяце!

Дэн ЙоркДиректор, Internet Technology

Тридцать лет назад в этом месяце, в ноябре 1983 г., были опубликованы два документа RFC, в которых определялась важнейшая интернет-служба, которую мы теперь воспринимаем как должное и используем каждый день, — система доменных имен или, в более общем смысле, просто «DNS». Этими двумя RFC, автором которых является Пол Мокапетрис, были:

RFC 882: Доменные имена — концепции и возможности
RFC 883: Доменные имена — реализация и спецификация

Эти два RFC легли в основу того, что должно было стать системой DNS, которую мы используем сегодня. В начале 19 века было много дискуссий.80-х вокруг того, как выйти за рамки соглашения об именовании, которое использовалось в раннем «Интернете ARPA». Было представлено несколько предложений, которые представляют интерес для чтения сегодня, в том числе RFC 799, RFC 819 и RFC 830. попросил Пола рассмотреть различные идеи и придумать собственное предложение о том, как это должно работать. Результатом стали RFC 882 и 883.

Четыре года спустя, в ноябре 1987, эти два первоначальных RFC (882 и 883) были затем «устарели» с помощью RFC 1034 и RFC 1035 , в которых Пол обновил и расширил исходные RFC, основываясь на четырехлетнем опыте фактического внедрения DNS. Эти более новые RFC 1034 и 1035 до сих пор являются основой DNS, хотя с тех пор они много раз «обновлялись», в том числе путем добавления DNSSEC в RFC 4033, 4034 и 4035.

Сегодня DNS является важнейшей частью нашей Инфраструктура Интернета и служба, которая помогает нам подключаться ко всем другим службам, которые мы используем в Интернете. Мы все используем DNS все время каждый день, хотя, как писал Пол Мокапетрис ранее в этом году, мы можем даже не осознавать, что — это с использованием DNS.

Здесь, в программе Deploy360, мы сосредоточены на том, как мы можем коллективно сделать DNS более безопасным с помощью расширений безопасности DNS (DNSSEC) и, таким образом, как мы можем сделать Интернет в целом более безопасным и защищенным. Но по мере того, как мы это делаем, нам также нужно сделать шаг назад и просто подумать о том, насколько великолепна система DNS в целом — и насколько невероятно критически важной она стала!

Поздравляем DNS с 30-летием! Будет интересно посмотреть, куда он пойдет дальше!

P.S. Большое спасибо Ондржею Сури из NIC.CZ, который сегодня отметил 30-летие в списке рассылки dns-operations.

ОБНОВЛЕНИЕ: Наш коллега Андрей Робачевский также прокомментировал пост С 30-летием, DNS! , где он указывает на некоторые другие информационные документы, исследования и отчеты по DNS, а также затрагивает вопросы, связанные со злоупотреблением DNS.