[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

Дедушка NetBIOS

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

Стандарт наших дней – DNS

DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Порядок разрешения имен

Операционная система Windows пытается разрешить имена в следующем порядке:

проверяет, не совпадает ли имя с локальным именем хоста;

смотрит в кэш DNS распознавателя;

если в кэше соответствие не найдено, идет запрос к серверу DNS;

если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

Для удобства проиллюстрирую алгоритм блок-схемой:

Алгоритм разрешения имен в Windows.

То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

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

Active Directory и суффиксы

Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

При попытке запуска команды ping servername система проделает следующее:

если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

Это поведение иногда приводит в замешательство начинающих системных администраторов.

Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

Источник

Общие сведения о понятиях DNS

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Служба доменных имен (DNS) — это распределенная база данных, представляющая пространство имен. Пространство имен содержит все сведения, необходимые любому клиенту для поиска любого имени. Любой DNS-сервер может отвечать на запросы о любом имени в своем пространстве имен. DNS-сервер отвечает на запросы одним из следующих способов:

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

Дополнительные сведения о DNS и службах домен Active Directory (AD DS) см. в разделе DNS и AD DS.

Делегирование

Чтобы DNS-сервер ответил на запросы о любом имени, он должен иметь прямой или косвенный путь к каждой зоне в пространстве имен. Эти пути создаются с помощью делегирования. Делегирование — это запись в родительской зоне, которая содержит сервер доменных имен, полномочный для зоны на следующем уровне иерархии. Делегирование позволяет серверам в одной зоне ссылаться на клиентов на серверы в других зонах. На следующем рисунке показан один пример делегирования.

Корневой DNS-сервер размещает корневую зону, представленную точкой (. ). Корневая зона содержит делегирование для зоны на следующем уровне иерархии — в зоне com. Делегирование в корневой зоне сообщает корневому серверу DNS, что для поиска зоны com необходимо обратиться к серверу com. Аналогично, делегирование в зоне com сообщает серверу com, что для поиска зоны contoso.com необходимо обратиться к серверу Contoso.

Делегирование использует два типа записей. В записи ресурса сервера имен (NS) содержится имя полномочного сервера. Записи ресурсов узла (A) и узла (AAAA) предоставляют адреса IP версии 4 (IPv4) и IP версии 6 (IPv6) полномочного сервера.

Эта система зон и делегирования создает иерархическое дерево, представляющее пространство имен DNS. Каждая зона представляет слой в иерархии, и каждое делегирование представляет собой ветвь дерева.

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

Рекурсивное разрешение имен

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

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

Разрешение имен с помощью корневых ссылок

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

В этом примере происходят следующие события:

Разрешение имен с помощью пересылки

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.

В этом примере происходят следующие события:

Источник

Разрешение имен

Алгоритм разрешения имен достаточно прост. Когда программе-клиенту требуется по доменному имени выяснить IP-адрес, она связывается с сервером имен, адрес которого указан в настройках TCP/IP.

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

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

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

Порядок взаимодействия DNS-клиента с сервером для обеспечения разрешения имен определяется специальным протоколам DNS. Этот протокол предусматривает свой формат сообщения (пакета) и использует для доставки данных транспортные протоколы UDP и TCP как нижележащие.

Задачи, решаемые сервисом DNS, являются относительно простыми, поэтому DNS-сообщение устроено несложно: оно включает в себя:

Источник

СЛУЖБА DNS

Система доменных имен представляет собой организованную компиляцию доменных имен и соответствующего IP-адреса, определяющего узел, с которого размещается веб-сайт. [1] Эта функция очень похожа на директорию, которая позволяет пользователям вводить именованный веб-адрес в браузер вместо указанного IP-адреса для этого сайта. Все пользователи Интернета подключаются к DNS-серверам, которые сопоставляют доменные имена с назначенными IP-адресами с помощью процесса, известного как DNS-разрешение имен. [2] DNS-серверы могут систематически получать такую информацию, поскольку база данных DNS иерархически организована через дерево доменных имен, которые подразделяются на различные зоны. [3]

Cодержание

Доменное имя

Устройства полагаются на разрешение DNS, чтобы найти IP-адрес для определенного веб-сайта. Это включает в себя процесс картирования, основанный на 3-х частях доменного имени, которые включают в себя:

Домен третьего уровня

Это относится к поддомену, части доменного имени, которая отображается перед доменом второго уровня. Наиболее распространенным доменом третьего уровня является www.

Домен второго уровня

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

Домен верхнего уровня

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

разрешение DNS

Основываясь на этих частях доменного имени, разрешение DNS также зависит от 4 компонентов системы:

DNS-рекурсор

DNS-рекурсор также называется DNS resolver. Это сервер, который отвечает за прием запросов от клиентских машин через приложения, такие как интернет-браузеры.

Корневой сервер имен

Существует 13 корневых серверов, стратегически распределенных по всему миру. Функция перенаправления DNS-рецидива на сервер имен ДВУ. Это очень похоже на индекс, который работает как ссылка для определения IP-адреса узла сайта.

Сервер имен домена верхнего уровня (ДВУ)

Авторитетный сервер имен

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

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

Типы запросов DNS

Есть 2 основных запроса, которые возникают при разрешении DNS.

Рекурсивный запрос

Итеративный запрос

Типы записей DNS [4]

История

Концепция системы доменных имен возникла в результате развития ARPANET, которая была разработана в 1966 году как эффективный метод передачи данных и информации между исследовательскими центрами по всей Америке. [5] К 1980 году через эту систему было подключено более 300 компьютеров, и было также создано несколько сайтов. Буквенные имена хостов были включены в систему, что устраняет необходимость запоминания пользователями IP-адресов, необходимых для доступа к нужным им серверам.

Однако по мере дальнейшего роста этой системы стала очевидной необходимость в более централизованной системе управления. Пол Мокапетрис, который тогда работал над эффективной системой организации файлов в компьютерах, смог предложить новый метод присвоения имен веб-сайтам с помощью своих коллег Джона Постеля и Зо Синг Су. [6]

Источник

Как это работает: Пара слов о DNS

Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.

/ фото James Cridland CC

Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).

Что такое DNS?

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

DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).

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

Сопоставление имен

Давайте взглянем, как происходит сопоставление имен и IP-адресов. Предположим, пользователь набирает в строке браузера www.1cloud.ru и нажимает Enter. Браузер посылает запрос DNS-серверу сети, а сервер, в свою очередь, либо отвечает сам (если ответ ему известен), либо пересылает запрос одному из высокоуровневых доменных серверов (или корневому).

Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые 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-серверов верхнего уровня».

Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно они отправляются в виде одной UDP-датаграммы. Однако UDP является протоколом без установления соединения и поэтому обладает уязвимостями, связанными с подделкой адресов – многие из атак, проводимых на 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.

Заключение

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

Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.

Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.

Источник