DNS использует UDP или TCP? Что говорит RFC
Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS.
Со временем ответ на довольно примитивный вопрос начинает интересовать каждого специалиста, так или иначе имеющего отношение к информационным технологиям и безопасности:
В каком случае DNS работает по UDP, а в каком — по TCP?
На этот вопрос отвечает действующий документ RFC5966 , раздел 4. Transport Protocol Selection , в котором фигурируют следующие утверждения:Most DNS [ RFC1034 ] transactions take place over UDP [ RFC0768 ]. TCP
[ RFC0793 ] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
То есть, большинство DNS-запросов будет обрабатываться с использованием протокола UDP, исключение составляют трансфер зоны (Query type AXFR) и ответы сервера, превышающие 512 байт на одно сообщение.
На вопрос «зачем» ответ простой: чтобы не использовались для DDoS.
All general-purpose DNS implementations MUST support both UDP and TCP
transport.
Это означает, что все реализации DNS-серверов в общем случае должны поддерживать использование обоих протоколов транспортного уровня: TCP и UDP.
Теперь более частные случаи:
Authoritative server implementations MUST support TCP so that they
do not limit the size of responses to what fits in a single UDP
packet.
То есть, авторитативный сервер, хранящий зону, должен поддерживать TCP. Как минимум, чтобы передавать зону тому, кто имеет право ее запросить.
Recursive server (or forwarder) implementations MUST support TCP
so that they do not prevent large responses from a TCP-capable
server from reaching its TCP-capable clients.
Рекурсивный же сервер должен поддерживать TCP для того, чтобы передавать полученные большие ответы от серверов клиентам, проверяя отсутствие подмены адреса инициатора запроса.
Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would
limit their interoperability with their own clients and with
upstream servers.
Stub resolver — это маленький тупой рекурсивный сервер, использующийся для небольшого количества клиентов. Например, домашний маршрутизатор, к которому подключаются клиенты. Он транслирует запросы вышестоящим серверам провайдера.
Stub resolver implementations MAY omit support for TCP when
specifically designed for deployment in restricted environments where
truncation can never occur or where truncated DNS responses are
acceptable.
Как видим, RFC дает поблажку производителям маломощных устройств для того, чтобы снизить нагрузку на сервера в том окружении, где либо большие ответы от DNS маловероятны, либо они предполагается, что не будут вредить. Например, домашний маршрутизатор доступа, к которому подключены пользователи одной квартиры (2-3 устройства).
В этом случае попытка выполнить DDoS второго устройства бессмысленна, и, как следствие, маловероятна.
Ну и, конечно, порядок использования протоколов:
A resolver SHOULD send a UDP
query first, but MAY elect to send a TCP query instead if it has good
reason to expect the response would be truncated if it were sent over
UDP (with or without EDNS0) or for other operational reasons, in
particular, if it already has an open TCP connection to the server.
То есть, (маленький тупой) рекурсивный сервер должен сначала пробовать выполнять DNS-запрос с использованием UDP, но при высокой вероятности большого и усеченного ответа, либо при наличии открытой TCP-сессии к запрашиваемому серверу (по которому обрабатывается другой запрос или запрос другого клиента), не возбраняется использование TCP.
DNS работает как на TCP, так и на UDP — Windows Server
- Чтение занимает 2 мин
В этой статье
В этой статье объясняется, почему некоторые службы используют протоколы TCP и UDP.
Применяется к: Windows Server 2003
Исходный номер КБ: 556000
СВОДКА
DNS и некоторые другие службы работают в обоих протоколах. Возьмем пример службы DNS. Два протокола отличаются друг от друга. TCP — это протокол, ориентированный на подключение, который требует, чтобы данные были последовательными в пункте назначения, а UDP — протоколом без подключения и не требовал последовательности данных или не требовало подключения к хосту для обеспечения согласованности данных.
Пакеты UDP меньше по размеру. Пакеты UDP не могут быть больше 512 bytes. Поэтому любому приложению необходимо, чтобы данные были переданы более 512 bytes, требуют TCP на месте. Например, DNS использует TCP и UDP по веские причины, описанные ниже. Сообщения UDP не больше 512 bytes и усечены, если больше этого размера. DNS использует TCP для передачи зоны и UDP для имени, а запросы регулярные (первичные) или обратные. UDP можно использовать для обмена небольшой информацией, в то время как TCP должен использоваться для обмена информацией размером более 512 bytes.
Если клиент не получает ответа от DNS, он должен повторно перенапустить данные с помощью TCP через 3-5 секунд с интервалом.
В базе данных DNS Zone должна быть согласованность. Чтобы сделать это, DNS всегда передает данные зоны с помощью TCP, так как TCP является надежным и убедитесь, что данные зоны соответствуют, передав полную зону другим DNS-серверам, запрашивающим данные.
Проблема возникает, когда Windows 2000 серверов и продуктов Advanced Server использует динамические порты для всех выше 1023. В этом случае DNS-сервер не должен быть интернет-лицом, то есть делать все стандартные запросы для клиентских машин в сети. Маршрутизатор (ACL) должен разрешить всем входящий трафик UDP для доступа к любым высоким портам UDP, чтобы он работал.
LDAP всегда использует TCP — это верно и почему бы не UDP, так как между клиентом и сервером установлено безопасное подключение для отправки данных, и это можно сделать только с помощью TCP, а не UDP. UDP используется только при поиске контроллера домена (Kerberos) для проверки подлинности.
Например, клиент домена находит контроллер домена с помощью DNS.
Community Отказ от контента решений
Корпорация Майкрософт и/или соответствующие поставщики не делают представлений о пригодности, надежности или точности сведений и связанных с ними графических данных, содержащихся в этой записи. Вся такая информация и связанная графика предоставляются «как есть» без какой-либо гарантии. Корпорация Майкрософт и/или соответствующие поставщики тем самым отключили все гарантии и условия в отношении этой информации и связанной графики, включая все подразумеваемые гарантии и условия торговой доступности, пригодность для определенной цели, рабочий труд, название и неущемление. Вы соглашаетесь, что ни в каких событиях корпорация Майкрософт и/или ее поставщики не несут ответственности за любые прямые, косвенные, штрафные, случайные, специальные, сопутствующие повреждения или любые повреждения, включая без ограничений убытки за потерю использования, данных или прибыли, возникающие из-за использования или невозможности использования сведений и связанных с ними графических элементов, содержащихся в этом деле, независимо от того, были ли они связаны с контрактом, тортом, халатностью, строгой ответственностью или иным образом, даже если корпорации Майкрософт или любому из ее поставщиков было рекомендовано о возможности ущерба.
Давайте уже разберемся в 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, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Приватность DNS — Интернет изнутри
Да, в наши дни открытость DNS невероятно облегчает его прослушку, перехват и подмену данных; но отчаиваться рано – прилагается много усилий к тому, чтобы создать среду DNS, которая защищала бы конфиденциальность и целостность данных. Минимизация имен запросов позволит значительно сократить уровень утечки информации DNS. А передача запросов и ответов DNS по безопасному каналу затруднит посторонним лицам прослушку и перехват пакетов DNS в пути. Если вдобавок ко всему этому еще и широко распространится DNSSEC, облик Интернета существенно изменится.
Протокол трансляции имен DNS (Domain Name System) пришел к нам еще из тех времен, когда в Интернете царило взаимное доверие, а не нынешняя атмосфера всеобщей подозрительности. DNS – протокол открытый, и свои данные он рассылает направо и налево. Но эти данные – не просто абстрактные непонятные циферки. Запросы и ответы DNS содержат доменные имена для всего, что пользователи делают в Интернете: доменное имя каждого URL, каждой почты, каждого расположения, к которому обращается пользователь. Этот поток данных синхронизирован с действиями пользователей. Практически каждой сетевой транзакции предшествует вызов DNS. Поэтому неудивительно, что в наши дни DNS широко используется для незаявленных целей. Сейчас DNS – не только привычный нам всем протокол трансляции имен, который опрашивает огромную распределенную базу данных, но и потенциальный канал для слежки, а кроме того, способ реализации самых разнообразных способов контроля доступа к контенту в общедоступной сети.
Ситуация с DNS должна измениться. Теперь, когда файлы Сноудена наглядно показали нам, какой масштаб принимают подобные системы слежки – как на службе правительств, так и мотивированные коммерчески, – мы воочию увидели, что многие привычные нам инструменты Интернета слишком доверчивы, слишком болтливы и слишком легко обходятся умным противником. И первым в этой коллекции уязвимых инструментов будет DNS.
Запросы к системе доменных имен предшествуют практически каждой интернет-транзакции. Журнал моих запросов DNS в плане содержащейся в нем информации, пожалуй, эквивалентен тому, чем был для предыдущего поколения список набранных телефонных номеров. Пусть журнал транзакций DNS и не содержит информацию о конкретных действиях в сети, но в нем регистрируется то, к каким сайтам я обращался – а зачастую этого достаточно, чтобы создать весьма точный профиль того, чем конкретно мы занимаемся в Интернете. Нередко отмечают, что метаданные такого вида даже полезнее для различных видов анализа, поскольку не загромождены описаниями отдельных действий.
Не только спецслужбы полюбили стоять у нас за плечом и подсматривать, что происходит на наших экранах. Появилось множество продуктов и услуг, нацеленных на индивидуального пользователя и стремящихся построить всеобъемлющий профиль его желаний и потребностей. Хэл Вариан (Hal Varian), главный экономист Google, однажды заметил, что надоедливую рекламу отличает от своевременной подсказки лишь уровень точности и актуальности данных о пользователе. Потому неудивительно, что многие компании строят подобные профили для своей клиентской базы просто по работе. Дошло до того, что во многих случаях на стоимость чистых активов компании больше влияет не ценность и прибыльность ее продуктов и услуг, а масштаб собранной клиентской базы, ее общая покупательная способность и точность информации о ней. И с этой точки зрения поток запросов DNS – настоящий Клондайк.
DNS – находка для шпиона
DNS невероятно болтлив, и доступ к его данным может получить буквально кто попало!
Чтобы преобразовать новое имя, например, www.example.com, резолвер DNS сначала запрашивает IP-адрес имени www.example.com у корневых серверов имен. Очевидно, корневой сервер не может ответить на этот запрос, поэтому он в ответ выдает список серверов имен, ответственных за домен .com. Затем резолвер снова отправляет запрос IP-адреса для имени www.example.com, на этот раз серверу имен .com – и снова получает непрямой ответ, означающий, что сам сервер не знает адреса, но за адреса домена example.com отвечают такие-то и такие-то серверы имен, и адресовать запрос нужно им. Теперь резолвер может направить тот же самый запрос серверу, отвечающему за домен example.com – и, возможно, наконец-то получит от него в ответ адрес www.example.com. Но у этой горы запросов есть и неприятный побочный эффект. Корневой сервер имен, сервер имен .com и сервер example.com теперь знают, что меня интересует имя www.example.com, и они наверняка ведут журнал подобных запросов. Откуда мне знать, общедоступен он или закрыт? Кто и как анализирует журнал, какие выводы делают из этих данных? Нет ответа.
А может быть, ситуация еще хуже: ведь приложение, с которым я работаю, например, браузер, как правило не выполняет трансляцию имен DNS само. Оно для этого обращается к операционной системе, например в форме запроса gethostbyname(). А ведь ОС тоже может вести журнал подобных запросов. Получается, что мой браузер и моя ОС осведомлены о моих действиях. Платформа операционной системы, как правило, не содержит автономного резолвера DNS, а настроена на вызов удаленного резолвера. Обычно такой рекурсивный резолвер предоставляется интернет-провайдером. Все это хорошо и замечательно, но, выходит, мой провайдер тоже знает всю мою историю обращений к DNS.
Дальше – больше. Провайдер, чтобы не связываться с поддержкой полномасштабного сервера DNS, может транслировать запросы другому рекурсивному резолверу, т.е. еще одной стороне. Как правило, подобные пересылки влекут за собой потерю атрибуции, так как пересылаемые запросы не содержат моих идентификационных данных. Но если резолвер использует опцию EDNS0 Client Subnet (RFC 7871), тогда пересылаемые запросы сохраняют ряд важных данных о моей локальной сети.
Из этого примера видно, что о моем интересе к сайту www.example.com узнает множество посторонних лиц.
Все эти запросы DNS – огромная куча данных даже по меркам нынешнего информационного века. Еще в апреле 2015 года Google сообщил, что его серверы DNS выдают около 400 миллиардов ответов в сутки, а по другим сведениям, Google обрабатывает примерно 12% общей нагрузки DNS. Получается, что на тот момент в мире генерировалось порядка трех триллионов запросов DNS. С тех пор эта цифра точно не стала меньше.
Мало того, что DNS беспардонно делится информацией о действиях пользователя с кем попало – он еще и передает ее открыто. Запросы DNS и ответы на них не шифруются, просто сидят на порту 53 для UDP и TCP. Запросы DNS легко можно перехватить, а если не используется DNSSEC – и подсунуть в поток данных фальшивые ответы, а клиент ничего не заметит. В некоторых странах перехват и подмена DNS уже стали обычным делом. Другие обратились к перехвату и блокировке DNS, пытаясь решить проблемы, связанные с перегрузкой IP-адресов при виртуальном веб-хостинге.
Можно ли «научить» DNS здоровой осторожности?
В последние годы IETF, наконец, занялась приватностью DNS, и появились предложения по его доработке, с тем чтобы лишить шпионов и цензоров всех мастей их любимого инструмента. Рассмотрим эти инициативы подробнее.
- Рис. 1 Предлагаемая схема минимизации имен запросов.
Минимизация QNAME
В рабочей группе DNS Operations возникло предложение минимизировать имена запросов DNS, в результате чего появилась спецификация QNAME Minimisation (RFC 7816, март 2016 г.). В этом документе говорится: «Минимизация QNAME исходит из того принципа, что чем меньше рассылается данных, тем меньше возникает проблем с их утечкой» – на мой взгляд, более чем разумная позиция.
В вышеприведенном примере запрос к корневым серверам для получения IP-адреса www.example.com содержит два лишних элемента информации, а именно полное доменное имя и тип запроса. Разумнее и безопаснее было бы запросить у корневых серверов имен записи NS для домена .com, не делясь информацией, которая корневым серверам вообще не нужна. Аналогично, у серверов имен .com лучше было бы запрашивать список серверов имен для домена example. com и так далее (см. рис. 1).
Минимизация QNAME в плане эффективности ничем не хуже передачи полного имени запроса, да и возможность использовать кэшированные данные не страдает. Она выявила ряд несоответствий при обработке т.н. пустых нетерминальных доменных имен (empty non-terminal domain names), но сам подход реализуется надежно и станет хорошим шагом к тому, чтобы положить конец разбазариванию информации. Никаких изменений на серверах DNS не требуется, а любой резолвер, реализующий этот метод, предоставит своим пользователям преимущества защиты их данных.
Одними из первых резолверов DNS, реализовавших минимизацию QNAME, стали Knot DNS Resolver, разработанный CZNIC , и Unbound (начиная с версии 1.5.7, хотя, как я понял, в реализации преобразователя Unbound минимизация QNAME по умолчанию отключена).
DNS по безопасному каналу
Минимизация имен запросов DNS решит лишь часть проблем – ведь в DNS вообще ничего не шифруется. Благодаря такой открытости DNS, прослушивать, перехватывать и подменять его данные невероятно просто. Этой проблемой занимается рабочая группа DPRIVE в составе IETF, пытаясь найти способы защитить обмен запросами и ответами DNS между клиентом и резолвером.
Здесь главная проблема – обеспечить безопасность протокола преобразования имен DNS. Причем для обеспечения безопасности нужно решить две задачи. Во-первых, требуется защитить транзакции DNS от прослушивания, т.е. зашифровать трафик DNS. А во-вторых, клиенты DNS должны отправлять запросы только своему резолверу DNS и проверять, что полученный ответ действительно пришел от нужного резолвера. Таким образом клиент сможет удостовериться в подлинности транзакции DNS, а попытки перехвата будут для него легко различимы.
DNS поверх TLS
У нас уже есть сеансовый сервис общего назначения, способный обеспечить такую безопасность на уровне сеанса, а именно протокол TLS (Transport Layer Security). TLS вырос из более раннего протокола SSL (Secure Socket Layer), разработанного Netscape в 90-е годы.
Надо признать, что сочетание TLS и DNS в одной фразе вызывает довольно бурную реакцию в сообществе DNS. По вопросу использования TCP вместо UDP в качестве основного транспортного протокола для DNS, а не резервного варианта для больших ответов, было сломано множество копий. Утверждалось, что усилия по поддержке соединения TCP значительно затруднят для сервера обработку больших объемов запросов, а дополнительная задержка на первоначальное «рукопожатие» негативно отразится на пользователе. Другая сторона оперировала следующими аргументами: «Веб и так уже используется, в основном, как служба коротких транзакций, и веб-серверы неплохо справляются с подобной нагрузкой. Кроме того, применение TCP – эффективное лекарство от различных злоупотреблений, эксплуатирующих уязвимость UDP к спуфингу исходных адресов».
Спецификация DNS поверх TLS (RFC 7858, май 2016 г.) довольно проста: транспортная служба, обеспечиваемая TLS, фактически та же, что и у TCP, с тем отличием, что порт прослушивания на сервере – TCP 853, а не 443.
Недостатком TLS является необходимость выполнить трехэтапное «рукопожатие» TCP для создания сеанса, а затем передачу аутентификационных данных TLS для создания защищенного сеанса. В TLS 1.2 это означает, что перед тем как запрос клиента поступит на сервер, должно пройти три интервала передачи данных с клиента на сервер и обратно (Round Trip Time, RTT). В более новой версии TLS 1.3 планируется улучшить положение, избавившись от одной RTT, но все равно это будет куда медленнее UDP и, скорее всего, увеличит нагрузку на серверы DNS за счет необходимости поддерживать сеансы.
Есть, однако, одно изменение, которое позволило бы устранить существенную, если не большую часть дополнительной нагрузки – вариант с повторным использованием сеансов TLS. В спецификации DNS поверх TLS предлагается именно это: «Чтобы свести к минимуму задержку, клиентам СЛЕДУЕТ направлять несколько запросов в сеансе TLS конвейерно». Для обмена данными между клиентом и рекурсивным резолвером повторное использование сеанса имеет смысл, но при обмене данными между авторитетным сервером имен и клиентом, который сам выполняет преобразование DNS, это может быть малореально.
Также интересно предложение использовать выделенный порт TCP. Если надо замаскировать шифрованный трафик DNS и затруднить блокировщикам его обнаружение, то напрашивается вариант пустить DNS поверх TLS через порт 443 (по крайней мере, я бы так и сделал!). А зашифрованный трафик через ничем больше не занятый порт TCP просто кричит: «Вот он я, блокируй – не хочу!» — и тогда будет гораздо легче заставить вас отказаться от шифрования DNS. Куда логичнее пустить безопасный трафик DNS через активно используемый порт TCP 443, где его будет значительно труднее выделить.
В ближайшие месяцы DNS поверх TLS будет реализован для устройств Android, так что можно ожидать некоторого повышения приватности DNS в этом аспекте.
Узнать больше о нынешнем состоянии клиентов и серверов, поддерживающих DNS поверх TLS, можно по адресу https://dnsprivacy. org/wiki/display/DP/DNS+Privacy+Imple mentation+Status.
Проблема этого варианта в том, что хотя обмен данными между тупиковым резолвером и выбранным рекурсивным резолвером шифруется, ваш рекурсивный резолвер все равно оказывается в курсе всего, что вы делаете по DNS. От атак на канал это защитит, но что касается ситуации на другом конце канала, тут остается только уповать на порядочность и квалификацию хозяев сервера.
DNS поверх DTLS
TCP не всегда будет оптимальным способом создать безопасный канал для DNS. TCP пытается доставлять данные последовательно, а в приложении, ориентированном на сообщения, потеря сообщения в TCP задержит доставку всех последующих до тех пор, пока TCP не исправит потерю данных и не передаст пропавшее сообщение. Эта особенность TCP может привести к неприемлемому возрастанию нагрузки при передаче сообщений по типу датаграмм: одна потеря, как вредный или нерасторопный покупатель, будет задерживать всю очередь. Для защиты приложений на основе UDP лучшим вариантом мог бы оказаться IPSEC, но IPSEC – функция ядра, а не модуль прикладного уровня, и его семантика применяется на уровне IP, а не в качестве атрибута транспортного протокола. Это затрудняет реализацию IPSEC в приложениях и развертывание криптографических функций в пространстве пользователя.
Альтернативный вариант защиты транспорта DNS – внедрение безопасного уровня сеанса в среду передачи датаграмм. На этом и построен новый протокол DTLS, представляющий собой адаптацию функции TLS, которая может обеспечить приложению функцию доставки по типу датаграмм, не требующую надежного транспортного сервиса. DTLS может восстанавливать потерю пакетов и выполнять переупорядочение, но нетерпим к фрагментации пакетов UDP. Он построен по образцу TLS 1.2 и пытается немного снизить негативное воздействие от использования TLS на качество работы DNS, особенно по сравнению с вариантом «DNS поверх TLS поверх TCP». Главное отличие – необходимость первоначального рукопожатия DTLS для того, чтобы создать общее состояние шифрования, и применение файлов cookie, чтобы повторно использовать это состояние на протяжении нескольких отдельных взаимодействий «запрос-ответ».
Применение DNS в его нынешнем варианте поверх UDP отличается тем, что накладные расходы на обслуживание общего состояния нагружают каждую отдельную транзакцию по минимуму, в результате чего сервис оказывается очень надежным и оперативным. DNS поверх DTLS пытается, насколько возможно, сохранить эту простую модель обмена датаграммами «запрос-ответ», но при этом сделать так, чтобы клиент использовал шифрование, основанное на предложенных сервером и проверенных сертификатах (RFC 8094, февраль 2017 г.).
DTLS нетерпим к фрагментации IP, поэтому реализация DNS поверх DTLS по структуре своей сходна с использованием флага TC в реализации DNS поверх UDP: если размер ответа превосходит MTU маршрута, то сервер должен выдать сокращенный ответ и установить флаг TC, чтобы просигнализировать клиенту о необходимости повторить запрос по TCP. Цель такого поведения в случае DTLS в следующем: если сервер DNS поверх DTLS выдает ответ длиннее, чем оценка MTU локального маршрута, то сервер должен в ответе установить флаг TC, а клиент интерпретирует это как инструкцию повторить запрос по DNS поверх TLS.
Спецификация DTLS содержит любопытную оговорку: «Это решение DTLS рабочая группа DPRIVE сочла подходящим вариантом для использования в случае, если метод на основе TLS, описанный в RFC7858, обнаружит проблемы при внедрении. На момент написания спецификации ожидается, что RFC7858 будет внедрен, а потому настоящая спецификация задумана, главным образом, как резервная».
Похоже, сами разработчики не очень-то верят в DTLS: разумно сделать вывод, что на сей момент интерес к DNS поверх DTLS невелик, и спецификация DTLS разработана, скорее, не для широкомасштабного применения, а в качестве формальности.
«Минимизация QNAME исходит из того принципа, что чем меньше рассылается данных, тем меньше возникает проблем с их утечкой» – на мой взгляд, более чем разумная позиция.
Безопасный DNS поверх JSON
И DNS поверх TLS, и DNS поверх DTLS просто заменяют транспортный протокол, никак не трогая формат запросов и ответов. Но, разумеется, никто не объявлял формат DNS неприкасаемым, а потому есть и другие методики, основанные на новом представлении запросов и ответов DNS.
Сервер по адресу https://dns. google.com выполняет функцию трансляции поверх TLS через порт 443, передавая результаты в формате структур данных JavaScript Object Notation ( JSON). Эту реализацию легко превратить в альтернативную форму gethostbyname() для приложения, заменяя обычный запрос DNS выборкой веб-объекта. Преимуществом для вызывающего станет некий уровень защиты от прослушивания третьими сторонами, потенциального вторжения и цензуры… хотя непонятно, о какой «защите» может идти речь, если вы оповещаете о своих действиях DNS-серверы Google!
Однако, чтобы проиллюстрировать, как приложение может использовать такой сервис непосредственно, обходя перехват как со стороны платформы, так и локального DNS, приведу пример скрипта Python, который устанавливает безопасный сеанс с этим сервисом Google:
Этот метод может оказаться полезным, так как опасения об утечке данных DNS нельзя ограничивать только внешними формами слежки и перехвата. «Адекватно осторожное» приложение не будет использовать службу трансляции имен DNS, предоставленную платформой, поскольку тогда запросы DNS приложения попадут в неконтролируемую среду, где могут регистрироваться платформой и другими приложениями. В этом случае приложение не выполняет трансляцию DNS и проверку DNS само: оно использует безопасный канал связи со службой трансляции имен Google по соединению TLS. Приложение может быть в некоторой степени уверено в том, что не допускает локальной утечки данных DNS, и что (при включенной проверке DNSSEC) получаемые ответы с известной степенью надежности достоверны, при условии, что само преобразуемое имя подписано по DNSSEC.
Отправка запросов по безопасному каналу на очень загруженный рекурсивный резолвер – а вряд ли найдется резолвер более загруженный, чем общедоступный DNS-сервер Google – имеет еще и то преимущество, что ваши запросы могут затеряться в горе кэшированной информации и тем избежать обнаружения. Если вы не против того, чтобы оповещать Google о своих запросах DNS, то довольно разумно использовать безопасный доступ к рекурсивному DNS-резолверу, который стремится к точности, целостности и полноте в выполнении своих задач. Такой безопасный канал гораздо труднее обойти и прослушать поток запросов.
Если же такой вариант вас не устраивает, есть и другой: вернуть трансляцию имен на свою платформу или даже в приложение, используя такие инструменты, как GetDNS. Здесь, правда, возникнет другая проблема: да, вы не доверяете чужому рекурсивному резолверу и ваши запросы напрямую передаются на ответственные серверы имен, но зато вы опять используете незашифрованный DNS – а к тому же теряете преимущество в быстродействии из-за общего кэша DNS. Возможно, лучше использовать безопасный канал к рекурсивному преобразователю, которому вы доверяете, но выполнять проверку DNSSEC самостоятельно.
DNS поверх HTTPS
Теперь мы можем обратиться к стандартизационной работе в IETF, где рабочая группа DOH пытается стандартизировать DNS поверх HTTPS. В уставе этой рабочей группы записано: «Данная рабочая группа стандартизирует шифрование для запросов и ответов DNS, пригодное для использования в HTTPS. Это позволит системе доменных имен функционировать на некоторых маршрутах, где существующие методы DNS (UDP, TLS [RFC 7857 ] и DTLS [RFC 8094]) столкнулись с проблемами. Данная рабочая группа будет в максимально возможной степени повторно использовать методы, коды ошибок и прочую семантику HTTPS. Применение HTTPS и его существующего PKI обеспечивает целостность и конфиденциальность, а также взаимодействие с общей инфраструктурой и политиками HTTPS».
Какой метод используется здесь?
Новые метки URI для различных схем именования URI сейчас не в моде, и работа DOH не стала исключением. Вместо того, чтобы повторно задействовать префикс «dns:», рабочая группа использует популярный в наше время механизм, а именно хорошо известный URI-путь «.well-known/ dns-query». В этой схеме запрос DNS может выглядеть так:
В этой методологии используется существующий двоичный формат DNS по проводу с применением типа данных MIME «application/dns-udpwireformat». При использовании метода GET запрос DNS шифруется по Base64, в то время как метод POST помещает двоичный запрос DNS в тело HTTP-объекта, к которому применяется POST, как в примере выше.
Надо сказать, я не слишком понимаю, в чем тут выгода. Дополнительная оболочка HTTP не добавляет практически ничего, кроме ненужных украшательств – и никаких преимуществ, кроме демонстрации ловкости рук, я тут не вижу! Если все, что нам надо – это упрятать запросы DNS в зашифрованный канал, то в HTTPS этим занимается тот же TLS, а компонент HTTP лишь усложняет задачу. Так может, просто использовать DNS поверх TLS?
Что дальше?
Мы затронули не все аспекты приватности DNS.
Например, есть еще и возможность паддинга (заполнение пустыми данными) пакетов. Даже если содержимое DNS передается по зашифрованному сеансу, есть возможность установить факт обмена данными DNS по размеру пакетов запроса и ответа DNS. Если блокировать такой зашифрованный трафик DNS, то пользователи будут вынуждены передавать данные DNS открыто и подставляться под DNS-атаки. С этим пытается бороться паддинг DNS (RFC7830, май 2016 г.): можно увеличивать размер запросов и ответов DNS, добивая их переменным количеством байтов, чтобы нельзя было отлавливать зашифрованный трафик по длине. Однако, хотя эта спецификация описывает, как добавлять мусорное содержимое, она не рекомендует никакой конкретной политики паддинга. Этой темой сейчас занимается IETF, и рабочая группа DRPIVE вырабатывает новую спецификацию, ориентированную на политики (текущий рабочий документ носит имя draft-ietf-dprive-padding-policy), чтобы дать полезные рекомендации в части политик паддинга, которые пригодятся клиентам DNS.
Еще один аспект, заслуживающий рассмотрения, это взаимодействие между рекурсивным резолвером и авторитетным сервером имен. До сих пор основные усилия по защите передачи DNS были сосредоточены на канале, ведущем от оконечного клиента к рекурсивному резолверу, а ведь канал от преобразователя к серверу имен не лишен тех же самых проблем. Недавно в этой сфере появились подвижки (рабочий документ носит имя draft-bortzmeyer-dprive-resolver-to-auth-00): предлагается использовать DANE и возложить на DNS публикацию открытого ключа сервера для запросов DNS поверх TLS. Работа находится еще на ранней стадии и наверняка будет переделываться, но выглядит эта идея достойно.
Паддинг может устранить некоторые очевидные паттерны трафика DNS, которые не сможет скрыть шифрование, но остается еще проблема времени передачи пакетов: оно тоже демаскирует обмен данными DNS. Ведутся разговоры о том, не стоит ли добавлять пакеты-«пустышки» в потоки запросов и ответов, чтобы лучше замаскировать паттерны коммуникации DNS. Пока неясно, что из этого получится, но если ответом на шифрование сеансов DNS действительно станет блокировка шифрованного трафика DNS, то идея добротной маскировки этого трафика наберет популярность среди пользователей.
Состояние дел с приватностью DNS
Да, в наши дни открытость DNS невероятно облегчает его прослушку, перехват и подмену данных; но отчаиваться рано – прилагается много усилий к тому, чтобы создать среду DNS, которая защищала бы конфиденциальность и целостность данных.
Минимизация имен запросов позволит значительно сократить уровень утечки информации DNS. А передача запросов и ответов DNS по безопасному каналу затруднит посторонним лицам прослушку и перехват пакетов DNS в пути.
Если приложения начнут использовать сервисы, которые инкапсулируют локальный трафик запросов DNS в зашифрованных сеансах TLS, то значительная часть данных DNS, доступных сегодня любому желающему, просто исчезнет из поля зрения. Более того, нынешняя практика выборочной локальной инспекции и вмешательства в процесс преобразования имен DNS станет гораздо более трудной, если вообще возможной.
Если вдобавок ко всему этому еще и широко распространится DNSSEC, облик Интернета существенно изменится. Само собой, попытки цензуры Интернета никуда не денутся – равно как и практика мониторинга и слежки в сети. Но если все мы решим всерьез заняться приватностью и безопасностью DNS, он перестанет быть тем, чем является сейчас – исключительно простым и дешевым инструментом для этих неблаговидных целей.
Источник: DNS privacy, Geoff Huston
DNS Службы и Протокол
Сейчас, имея более глубокое понимание того, как приложения обеспечивают интерфейс для пользователя и предоставляют доступ к сети, мы рассмотрим несколько конкретных широко используемых протоколов.
Как мы увидим позже, Транспортный уровень использует схему адресации, применяющую понятие номера порта. Номера портов идентифицируют приложения и службы Прикладного уровня, которые являются источником и назначением данных. Серверные программы как правило используют предопределенные номера портов, которые хорошо известны клиентам.
При рассмотрении различных протоколов и служб TCP/IP Прикладного уровня, мы будем ссылаться на стандартные номера портов TCP и UDP, которые обычно связаны с этими службами. Некоторые из этих служб:
DNS
В информационных сетях устройства маркируются числовыми IP адресами, так чтобы они могли участвовать в отправке и получении сообщений по сети. Однако, человеку весьма неудобно запоминать такие числовые адреса. Поэтому были созданы доменные имена — чтобы конвертировать числовые адреса в простые, легко запоминаемые и узнаваемые имена.
В Интернете эти доменные имена, такие как yandex.ru, людям гораздо легче запомнить, нежели 213.180.193.11, что является фактическим числовым адресом для этого сервера. Кроме того, если адрес сайта google.ru вдруг поменяется, это произойдет незаметно для пользователя, поскольку доменное имя по прежнему останется yandex.ru. Новый адрес просто будет привязан к существующему доменному имени и возможность захода на сайт не пострадает. Когда сети были небольшими, поддержка соответствия между доменными именами и адресами, которые они представляют, была простой задачей. Однако, как только сети начали расти, а количество устройств увеличиваться, эта ручная система стала неработоспособной.
Система Доменных Имен (DNS) была создана вместо доменного имени, чтобы решить проблему разрешения для растущих в размерах сетей. DNS использует распределенный набор серверов для разрешения имен, связанных с этими числовыми адресами.
DNS протокол определяет автоматическую службу, которая сопоставляет имена ресурсов требуемому числовому сетевому адресу. Он включает формат для запросов, ответов, а также форматов данных. Коммуникации DNS протокола используют одиночный формат называемый сообщением. Этот формат сообщения используется для всех типов клиентских запросов и ответов сервера, сообщений об ошибках и для передачи информации о записях ресурсов между серверами.
Далее: Утилита nslookup
Смотрите также
Написать
D-Link DNS-320
Стандарты
• IEEE 802.3
• IEEE 802.3ab
• IEEE 802.3u
• TCP/IP
• CIFS/SMB
• NFS
• AFP
• DHCP-клиент
• DDNS
• NTP
• FTP через SSL/TLS, FXP
• HTTP/HTTPS
• LLT D
• PnP -X
• UPnP AV
• USB 2.0
• Bonjour
Индикаторы
• Power
• LAN
• HDD 1
• HDD 2
Порты
• 1 порт 10/100/1000 Gigabit Ethernet
• 1 порт USB 2.0
• Питание
Поддерживаемые типы жестких дисков*
Внутренний 3.5” SATA1
Управление диском1
• Множество конфигурациц жестких дисков: RAID 0, RAID 1, JBoD, Standard
• RAID migration from Non-RAID to RAID 1
• Форматирование жесткого диска: EXT3
• Сканирование диска
• S.M.A.R.T.
Управление устройством
• Internet Explorer 7, Mozilla Firefox 3+ или Apple Safari 4
• Утилита Easy Search
• Уведомления по e-mail
• Журнал системны/FTP
• Yahoo! Widget
Совместный доступ к файлам
• Макс. количество учетных записей: 64
• Макс. количество групп: 10
• Макс. количество общих папок: без BitTorrent: 64
• Макс. число одновременных соединений: 64 (Samba)
Потоковая передача медиа-данных2
• Соответствует стандарту DLNA
• Поддержка для PS3/Xbox 360
• iTunes -сервер
Источник питания
• Внешний источник питания
• Переключаемый 12 В постоянного тока / 4A
Потребляемая мощность
• Нормальный режим: 15.7 Вт
• Спящий режим: 8.2 Вт
Температура
• Рабочая:от 0 до 40 C
• Хранения: от -20 до 70 C
Рабочая влажность
От 5% до 90% (без конденсата)
Размеры (Д x Ш x В)
146.4 x 115 x 178.5 мм
Вес
0.85 кг
Поддержка языков
• Samba: Unicode
• FTP-клиент: Unicode, корейский, турецкий, хорватский, кириллица (Республика Киргизия), Чешский, датский, немецкий, английский, финский, французский, греческий, венгерский, итальянский, норвежский, польский, португальский, румынский, русский, упрощенный китайский, словенский, испанский, шведский, традиционный китайский, корейский, иврит
1Жесткие диски не входят в комплект поставки. RAID 1 требует использования двух внутренних SATA-дисков. Во избежание несовместимости в работе RAID 1 используйте диски SATA от одного производителя. Объем отформатированного диск для работы RAID 1 зависит от объема диска наименьшего размера. Может не работать со старшими поколениями дисков SATA. За списком дисков SATA, проверенных для работы с ShareCenter Pulse, обратитесь на Web-сайт технической поддержки D-Link.
2D-Link не может гарантировать полную совместимость или точное воспроизведение со всеми кодеками. Возможность воспроизведения зависит от поддержки кодека медиаплеером UPnP AV.
*Списки совместимости жестких дисков
Настройка DNS на маршрутизаторах Cisco
Целью этого документа является сведение воедино некоторых данных об использовании DNS маршрутизаторами Cisco.
Требования
Читатели данного документа должны обладать знаниями по следующим темам:
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
Условные обозначения
Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.
Можно настраивать конфигурацию маршрутизатора для использования поиска DNS, если вы хотите использовать команды ping или traceroute с именем хоста, а не IP адресом. Используйте для этого следующие команды:
| Команда | Описание |
|---|---|
| команда ip domain lookup | Включает преобразование имени хоста в адрес на основе DNS. Эта команда включена по умолчанию. |
| ip name-server | Задает адрес одного или более сервера доменных имен. |
| ip domain list | Задает список доменов, для каждого из которых выполняется попытка использования. Примечание. Если список доменов отсутствует, используется доменное имя, заданное с помощью команды глобальной кофигурации ip domain name. При наличии списка доменов доменное имя по умолчанию не используется. |
| ip domain name | Задает доменное имя по умолчанию, которое используется ПО Cisco IOS для дополнения неполных имен хоста (имен без доменных имен в виде десятичного представления с точкой). Не включайте первую точку, которая отделяет неполное имя от доменного имени. |
| ip ospf name-lookup | Настраивает протокол OSPF для поиска имен DNS, которые необходимо использовать во всех выводах команды OSPF show EXEC. Эта функция упрощает идентификацию маршрутизатора, потому что маршрутизатор называется по имени, а не по идентификатору маршрутизатора или соседа. |
Здесь приведен пример конфигурации на маршрутизаторе, конфигурированном для основного поиска DNS:
| Пример основной конфигурации поиска в DNS |
|---|
Router# show running-config Building configuration... Current configuration : 470 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log uptime no service password-encryption ! hostname Router ! ! ip subnet-zero ip name-server 192.168.1.100 !--- Configures the IP address of the name server. !--- Domain lookup is enabled by default. ! ! interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ! ! !--- Output Suppressed. end |
Router# ping www.cisco.com Translating "www.cisco.com"...domain server (192.168.1.100) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 224/228/236 ms
Устранение неисправностей
Довольно редко можно увидеть одну из следующих ошибок:
Router# debug ip udp UDP packet debugging is on Router# ping www.yahoo.com Translating "www.yahoo.com"...domain server (129.250.35.250) *Mar 8 06:26:41.732: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 *Mar 8 06:26:44.740: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 *Mar 8 06:26:47.744: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 % Unrecognized host or address, or protocol not running. Router#undebug allAll possible debugging has been turned off Router# ping www.yahoo.co.kr Translating "www.yahoo.co.kr"...domain server (169.140.249.4) ¡¦ Not process Router# ping www.novell.com Translating "www.novell.com"...domain server (255.255.255.255) % Unrecognized host or address, or protocol not running.
Для того чтобы устранить эту проблему, выполните следующие шаги:
Убедитесь, что маршрутизатор может достичь сервера DNS. Отправьте на сервер DNS эхозапрос от маршрутизатора с помощью его IP-адреса и убедитесь, что для настройки IP-адреса сервера DNS на маршрутизаторе используется команда ip name-server.
Используйте эти шаги, чтобы проверить, перенаправляет ли маршрутизатор запросы поиска:
Задайте список контроля доступа (ACL), совпадающий на пакетах DNS:
access-list 101 permit udp any any eq domain access-list 101 permit udp any eq domain any
Используйте команду debug ip packet 101.
Примечание. Убедитесь, что задан ACL. При выполнении без ACL объем выходных данных команды debug ip packet в консоли может оказаться слишком большим, что приведет к перезагрузке маршрутизатора.
Убедитесь, что на маршрутизаторе включена команда ip domain-lookup.
В редких случаях доступ к определенным веб-сайтам по имени невозможен. Обычно проблема возникает из-за недоступных сайтов, выполняющих обратный поиск DNS на исходном IP адресе с целью проверки того, что адрес не имитируется. При возврате неверной записи или отсутствии записей (иными словами, при отсутствии cвязанного названия для диапазона IP-адресов) запрос HTTP будет заблокирован.
Получив доменное имя в Интернете, следует также обратиться за получением домена inaddr.arpa. Этот специальный домен иногда называют обратным доменом. Домен обратного преобразования осуществляет преобразование цифровых IP-адресов в доменные имена. Если интернет-провайдер предоставляет вам сервер имен или назначил вам адрес из блока своих адресов, не требуется самостоятельно обращаться за получением домена in-addr.arpa. Консультация Интернет-провайдера.
Давайте Давайте Рассмотрим пример, в котором используется www.cisco.com. Приведенные ниже выходные данные были получены от рабочей станции UNIX. Использовались программы nslookup и dig. Обратите внимание на различия в выходных данных:
sj-cse-280% nslookup www.cisco.com Note: nslookup is deprecated and may be removed from future releases. Consider using the 'dig' or 'host' programs instead. Run nslookup with the '-sil[ent]' option to prevent this message from appearing. Server: 171.68.226.120 Address: 171.68.226.120#53 Name: www.cisco.com Address: 198.133.219.25 sj-cse-280% nslookup 198.133.219.25 Note: nslookup is deprecated and may be removed from future releases. Consider using the 'dig' or 'host' programs instead. Run nslookup with the '-sil[ent]' option to prevent this message from appearing. Server: 171.68.226.120 Address: 171.68.226.120#53 25.219.133.198.in-addr.arpa name = www.cisco.com.
Программа dig дает более детальную информацию о DNS пакетах:
sj-cse-280% dig 198.133.219.25 ; <<>> DiG 9.0.1 <<>> 198.133.219.25 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5231 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;198.133.219.25. IN A ;; AUTHORITY SECTION: . 86400 IN SOA A.ROOT-SERVERS.NET. nstld.verisign-grs.com. ( 2002031800 1800 900 604800 86400 ) ;; Query time: 135 msec ;; SERVER: 171.68.226.120#53(171.68.226.120) ;; WHEN: Mon Mar 18 09:42:20 2002 ;; MSG SIZE rcvd: 107
В зависимости от уровня сетевой активности маршрутизатор может запросить несколько серверов имен, перечисленных в конфигурации. Ниже представлен пример:
router> test002 Translating ?test002?...domain server (172.16.33.18) (171.70.10.78) (171.100.20.78) (172.16.33.18) (171.70.10.78) (171.10.20.78) Translating ?test002?...domain server (172.16.33.18) [OK] Trying test002.rtr.abc.com (171.68.23.130)... Open
Это поведение весьма вероятно и имеет место, когда маршрутизатору требуется создать запись протокола разрешения адресов (ARP) для сервера DNS. По умолчанию маршрутизатор поддерживает ARP-запись в течение четырех часов. В периоды низкой активности маршрутизатору требуется дополнить ARP-запись и затем выполнить запрос DNS. Если ARP-запись для сервера DNS отсутствует в ARP-таблице маршрутизатора, при передаче только одного запроса DNS произойдет сбой. Поэтому отправляются два запроса: один для получения ARP-записи, если необходимо, а второй — для отправки запроса DNS. Такое поведение является обычным для приложений TCP/IP.
Это DNS TCP или UDP порт 53?
По мере того, как все больше и больше людей внедряют новые функции, такие как IPv6, предотвращение спама и DNSSEC, DNS с большей вероятностью переключится на TCP из-за большего размера ответа.
Что произойдет, если TCP заблокирован?
В любом случае, когда размер сообщения превышает 512 байт, он запускает установку бита «TC» (усечение) в DNS, информируя клиента о том, что длина сообщения превышает допустимый размер. В этих ситуациях клиенту необходимо повторно передать данные по протоколу TCP, который не имеет ограничений по размеру.Если DNS-серверы и сетевая среда не могут поддерживать большие пакеты UDP, это вызовет повторную передачу по TCP; если TCP заблокирован, большой ответ UDP либо приведет к фрагментации IP, либо будет полностью отброшен. Конечным признаком для конечного клиента обычно является медленное разрешение DNS или вообще неспособность разрешить определенные доменные имена.
Размер имеет значение: EDNS
Вам может быть интересно, откуда берется ограничение на размер в 512 байт. Размер полезной нагрузки UDP в 512 байт зависит от IPv4.Стандарт IPv4 2 определяет, что каждый хост должен иметь возможность повторно собирать пакеты размером 576 байтов или меньше, удалять заголовок и другие параметры, что оставляет 512 байтов для данных полезной нагрузки. По этой причине изначально существует ровно 13 корневых серверов DNS 3 : 13 доменных имен и 13 адресов IPv4 прекрасно вписываются в один пакет UDP.
Это ограничение размера давно было признано проблемой. В 1999 году был предложен механизм расширения для DNS (EDNS), который с годами обновлялся, увеличивая размер до 4096 байтов или 4 килобайт.Итак, если вы используете достаточно современный DNS-сервер, шансы его переключения на TCP должны быть невелики (mer).
Однако, несмотря на то, что EDNS существует уже давно, его поддержка не была такой универсальной, как должна быть 4 . Некоторое сетевое оборудование, такое как межсетевые экраны, может по-прежнему делать предположения о размере пакета DNS. Брандмауэр может отбросить или отклонить большой пакет DNS, думая, что это атака. Такое поведение могло не вызывать видимых проблем в прошлом (или это было, но никто не понимал почему), но поскольку данные DNS продолжают увеличиваться в размере, важно, чтобы все сетевое оборудование было правильно настроено для поддержки больших размеров пакетов DNS.Если сетевая среда не полностью поддерживает большие сообщения DNS, это может привести к тому, что сообщение DNS будет отклонено сетевым оборудованием или частично отброшено во время фрагментации. Для конечного пользователя это выглядит так: запросы DNS остаются без ответа или занимают очень много времени, создавая впечатление, что «DNS / сеть очень медленная».
Хотя EDNS необходим для работы современных DNS, возможность отправки более крупных сообщений способствовала объемным атакам, таким как Amplification и Reflection .
Как мне настроить брандмауэр для DNS?
Существуют две основные категории межсетевых экранов:
1) Программный брандмауэр — фильтрация сетевого трафика на локальный компьютер и с него
Последние версии Windows включают программный брандмауэр («Брандмауэр Windows» / «Брандмауэр Защитника Windows»). При установке Simple DNS Plus автоматически добавляются «правила» брандмауэра Windows, позволяющие Simple DNS Plus взаимодействовать.
Также доступны многие сторонние программные брандмауэры.При использовании этого типа межсетевого экрана на том же компьютере, что и Simple DNS Plus, обычно требуется только «разрешить» доступ в Интернет для модулей приложения Simple DNS Plus (файлов .exe).
2) Аппаратные / серверные межсетевые экраны — фильтрация сетевого трафика между Интернетом и локальной сетью
Этот тип межсетевого экрана часто встроен в маршрутизаторы и фильтрует трафик TCP / IP по протоколу (UDP, TCP, IGMP и т. Д.), К / от IP-адреса и к / от номера порта.
DNS в основном использует протокол UDP — за исключением зональной передачи, использующей TCP.
Номера портовTCP / IP часто классифицируются как «порты сервера» (от 1 до 1023) или «порты приложений» (> 1023).
Большинство серверных программ прослушивают запросы на «порте сервера», а клиентские программы (приложения) связываются с сервером через случайный «порт приложения».
DNS-сервер прослушивает запросы на порте 53 (как UDP, так и TCP).
Таким образом, все запросы DNS отправляются на порт 53, обычно из порта приложения (> 1023).
Вы можете указать, с какого порта Simple DNS Plus отправляет исходящие DNS-запросы, в диалоговом окне «Параметры» / «DNS» / «Исходящие запросы».
ответов DNS возвращаются с порта 53 обратно на исходный исходящий порт (> 1023).
Многие брандмауэры по умолчанию настроены на прием всего трафика, отправляемого на номера портов приложений, поэтому вам не нужно беспокоиться об ответах DNS.
Таким образом, вы должны разрешить весь трафик (входящий и исходящий), отправляемый на порт 53 (запросы), и, возможно, весь трафик (входящий и исходящий) с порта 53 на любой порт приложения (ответы).
Это может означать до 8 «правил брандмауэра» (UDP / TCP, In / Out, To / From 53).
ПРИМЕЧАНИЕ. Некоторые старые микропрограммы межсетевого экрана (например, Cisco PIX) будут блокировать все пакеты DNS с включенным EDNS0. При необходимости вы можете отключить EDNS0 в диалоговом окне Simple DNS Plus Options / DNS / Miscellaneous, но мы настоятельно рекомендуем вам обновить прошивку брандмауэра вместо этого.
ПРИМЕЧАНИЕ. Некоторые брандмауэры имеют специальные фильтры, которые блокируют определенные типы DNS-запросов. Одним из примеров является программное обеспечение межсетевого экрана «NG» от «Check Point Software Technologies», которое также встроено в некоторые аппаратные решения.Это программное обеспечение имеет функцию «Проверка / проверка DNS», которая блокирует весь трафик DNS, кроме самого простого. Необходимо отключить эту функцию для работы некоторых функций DNS, таких как уведомления об обновлении зоны на вторичных серверах.
[Глава 8] 8.10 Система доменных имен (DNS)
DNS — это система распределенных баз данных, переводит имена хостов в IP-адреса и IP-адреса в имена хостов (например, он переводит имя хоста miles.somewhere.net с до IP-адрес 192.168.244.34). DNS также является стандартным Интернет-механизмом для хранения и доступа несколько других видов информации о хостах; это обеспечивает информация о конкретном хосте для мира в целом. Для Например, если хост не может получать почту напрямую, а другая машина получит почту за это и передаст ее, эта информация общался с записью MX в DNS.
DNS-клиенты включают любую программу, которая должна выполнять любое из следующего:
Преобразование имени хоста в IP-адрес
Преобразование IP-адреса в имя хоста
Получение другой опубликованной информации о хосте (например, его MX запись)
По сути, любая программа, использующая имена хостов, может быть DNS-клиент.Сюда входят практически все программы это имеет какое-либо отношение к сети, включая как клиент, так и серверные программы для Telnet, SMTP, FTP и почти любая другая сеть услуга. Таким образом, DNS является фундаментальной сетью. сервис, на который полагаются другие сетевые сервисы.
Для предоставления такой информации могут использоваться другие протоколы. Для Например, NIS / YP используется для предоставления информации о хосте. внутри сети. Однако DNS — это служба, используемая для этого. цель в Интернете, и клиенты, которым нужен доступ в Интернет хосты должны будут использовать DNS напрямую или косвенно.В сетях, использующих NIS / YP или другие внутренние методы, сервер для другого протокола обычно действует как DNS-прокси для клиента. Многие клиенты также могут быть настроенным на использование нескольких сервисов, чтобы при поиске хоста не удается, он повторит попытку, используя другой метод. Таким образом, это может начаться с ищу в NIS / YP, который покажет только местные хосты, но попробуйте DNS, если это не удается, или он может запуститься просмотрев DNS, а затем попробуйте файл самостоятельно диск, если это не удается (чтобы вы могли указать личные любимые имена, Например).
В UNIX DNS реализуется доменное имя в Интернете Беркли (BIND). На клиентская сторона — преобразователь, библиотека подпрограмм, вызываемая сетью процессы. На стороне сервера есть демон с именем с именем (также известный как in. С именем на некоторых системы).
DNS предназначен для пересылки запросов и ответов между клиентами и серверами, чтобы серверы могли действовать от имени клиенты или другие серверы. Эта возможность очень важна для вашего возможность создать брандмауэр, который обрабатывает DNS услуги безопасно.
Как работает DNS? По сути, когда клиенту нужно конкретная информация (например, IP-адрес хоста ftp.somewhere.net ), он запрашивает у местного DNS-сервер для этой информации. Местный DNS-сервер сначала проверяет свой кеш, чтобы убедиться, что он уже знает ответ на запрос клиента. Если нет, то локальный DNS-сервер запрашивает другой DNS серверы, в свою очередь, обнаруживают ответ на запрос клиента. Когда локальный DNS-сервер получает ответ (или решает что он не может по какой-то причине), он кеширует любую информацию, которую он получил [34] и отвечает клиенту.Например, чтобы найти IP адрес ftp.somewhere.net , местный DNS-сервер сначала запрашивает у одного из публичных корневых серверы имен какие машины являются серверами имен для net домен. Затем он спрашивает одного из тех net серверов имен который машины являются серверами имен для где-то. net домен, а затем он запрашивает у одного из этих серверов имен для IP адрес ftp.somewhere.net .
Все эти вопросы и ответы прозрачны для клиента.Поскольку клиент обеспокоен, он общался только с локальным сервером. Он не знает и не заботится о том, что локальный сервер мог связаться несколько других серверов в процессе ответа на исходный вопрос.
8.10.1 Характеристики фильтрации пакетов DNS
Существует два типа сетевой активности DNS: поиск и перенос зон. Поиски происходят, когда DNS-клиент (или DNS-сервер действует от имени клиента) запрашивает DNS-сервер для информации, e.g., IP-адрес для данного имя хоста, имя хоста для данного IP-адреса, сервер имен для данный домен или почтовый обменник для данного хоста. Зона трансферов возникают, когда DNS-сервер (вторичный сервер) запросы от другого DNS-сервера (основного server) все, что первичный сервер знает о данной части Дерево именования DNS (зона). Зональные трансферы случаются только среди серверов, которые должны предоставлять такие же Информация; сервер не будет пытаться выполнить перенос зоны из случайного другой сервер при нормальных обстоятельствах.Люди иногда делают зону переводы с целью сбора информации (это ОК, когда они подсчитывают, что самое популярное имя хоста в Интернете есть, но плохо, когда они пытаются узнать какие хосты атаковать на вашем сайте).
По соображениям производительности поиск DNS обычно выполняется с использованием UDP. Если часть данных потеряна в транзитом по UDP (помните, что UDP не гарантирует доставку) поиск будет переделал с помощью TCP. Могут быть и другие исключения. На рис. 8.13 показан поиск по DNS-имени.
Рисунок 8.13: Поиск имени DNS
DNS-сервер использует хорошо известный порт 53 для всех своих UDP-активности и в качестве порта сервера для TCP. Он использует случайный порт выше 1023 для Запросы TCP. Клиент DNS использует случайный порт выше 1023 для UDP и TCP. Таким образом, вы можете различать следующее:
Запрос клиент-сервер — исходный порт больше 1023, пункт назначения порт 53.
Ответ от сервера к клиенту — порт источника — 53, порт назначения выше 1023.
Межсерверный запрос или ответ — по крайней мере, с UDP, где порт источника и порт назначения 53; с TCP запрашивающий сервер будет использовать порт выше 1023.
Передача зоны DNS выполняется с использованием TCP. Соединение инициируется со случайного порта выше 1023 на вторичном сервере (который запрашивает данные) для порта 53 на основном сервере (который отправляет данные, запрошенные вторичный). Вторичный сервер также должен выполнять регулярные DNS-запрос первичного сервера, чтобы решить, когда делать зонная передача.На рисунке 8.14 показан Перенос зоны DNS.
| Direc- | Source | Dest. | Pro- | Источник | Цел. | ACK | |||
|---|---|---|---|---|---|---|---|---|---|
| ция | Адр. | Адр. | tocol | Порт | Порт | Набор | Примечания | ||
Внутр. | Внешний | Внутр. | [35] | Входящий запрос через UDP, от клиента к серверу | |||||
Out | Int | Ext | [35] | Ответ на входящий UDP-запрос, сервер клиенту | |||||
In | Ext | Int | 82 | 53 | [36] | Входящий запрос через TCP, клиент для доступа rver | |||
Out | Int | Ext | TCP | 53 | > 1023 | > 1023 | |||
Out | Int | Ext | UDP | > 1023 | 53 | UDP запрос , от клиента к серверу||||
In | Ext | Int | UDP | 53 | > 1023 | ||||
Out | Int | Внешний | TCP | > 1023 | 53 | [36] | Исходящий запрос через TCP, клиент-сервер42 | Внутр. | TCP | 53 | > 1023 | Да | Ответ на исходящий запрос TCP, от сервера к клиенту | Int | UDP | 53 | 53 | [35] | Запрос или ответ между двумя серверами | UDPВнутр. | Внешний | UDP | 53 | 53 | [35] | Запрос или ответ между двумя серверами через UDP |
In | Ext | Int | 53 | [36] | Запрос от внешнего сервера к внутреннему серверу через TCP; также запрос передачи зоны от внешнего вторичного сервера через TCP | ||||
Out | Int | Ext | TCP | 53 | Ответ внутреннего сервера на внешний сервер по TCP; также ответ на передачу зоны внешнему вторичному серверу через TCP | ||||
Out | Int | Ext | TCP | > 1023 | 53 | Запрос от внутреннего сервера к внешнему серверу через TCP | |||
In | Ext | Int | TCP | 82 5383 Да | Ответ внешнего сервера внутреннему серверу по TCP |
Рисунок 8.14: Перенос зоны DNS
8.10.2 Характеристики проксирования DNS
DNS структурирован таким образом, что серверы всегда действуют как прокси для клиентов. Также можно использовать Функция DNS называется , перенаправляя , чтобы DNS-сервер фактически является прокси для другого сервер. Остальная часть этого DNS обсуждение описывает использование этих встроенные функции проксирования DNS.
В большинстве реализаций можно было бы изменить Библиотеки DNS для использования прокси-сервера с модифицированным клиентом.На машины, которые не поддерживают динамическое связывание, с использованием модифицированного клиента прокси для DNS потребует перекомпиляции каждые сетевая программа. Поскольку пользователи не указывают сервер напрямую информация для DNS, прокси с модифицированной процедурой кажется почти невозможным.
8.10.3 Данные DNS
DNS — это древовидная база данных с серверами. для различных поддеревьев, разбросанных по всему Интернету. Есть количество определенных типов записей в дереве, включая: [37]
| Тип записи | Использование |
|---|---|
A | Преобразует имя хоста в IP-адрес |
Преобразует IP-адрес в имя хоста | |
CNAME | Преобразует псевдоним хоста в имя хоста («каноническое» имя) |
Программное обеспечение HINFO | Предоставляет информацию об аппаратном обеспечении хоста |
NS | Делегирует зону дерева DNS другому серверу |
SOA | Обозначает начало полномочий для зоны дерева DNS |
Неструктурированные текстовые записи |
Фактически, есть два отдельных дерева данных DNS: одно для получения информации по имени хоста (например, IP-адрес, запись CNAME, Запись HINFO или запись TXT, соответствует заданному имени хоста), и один для получения информации IP-адрес (имя хоста для данного адреса).
Например, вот образец данных DNS для поддельный домен something.net :
some.net. В SOA tiger.somebody.net. root.tiger.somebody.net. (
1001; серийный номер
36000; обновить (10 часов)
3600; повторить попытку (1 час)
3600000; истекает (1000 часов)
36000; ttl по умолчанию (10 часов)
)
В НС тигр.some.net.
В НС lion.somebody.net.
тигр В А 192.168.2.34
В MX 5 tiger.somebody.net.
В MX 10 lion.somebody.net.
В HINFO INTEL-486 BSDI
ftp IN CNAME tiger.somebody.net.
лев В А 192.168.2.35
В MX 5 lion.somebody.net.
В MX 10 tiger.somebody.net.
В HINFO SUN-3 SUNOS
www IN CNAME лев.some.net.
wais В CNAME lion.somebody.net.
аляска IN NS bear.alaska.somebody.net.
bear.alaska В А 192.168.2.81
Для этого домена также потребуется соответствующий набор Записи PTR для сопоставления IP-адресов вернемся к именам хостов. Чтобы преобразовать IP-адрес в имя хоста, вы меняете компоненты IP адрес, добавьте .IN-ADDR.ARPA и найдите Запись DNS PTR для этого имени. Например, чтобы переведите IP-адрес 1.2.3.4, вы увидите Запись PTR для 4.3.2.1.IN-ADDR.ARPA .
2.168.192.IN-ADDR.ARPA. В SOA tiger.somebody.net.root.tiger.somebody.net. (
1001; серийный номер
36000; обновить (10 часов)
3600; повторить попытку (1 час)
3600000; истекает (1000 часов)
36000; ttl по умолчанию (10 часов)
)
В НС тигр.some.net.
В НС lion.somebody.net.
34 В ПТР tiger.somebody.net.
35 В ПТР lion.somebody.net.
81 НА ПТР bear.alaska.somebody.net.
8.10.4 Проблемы безопасности DNS
Есть некоторые проблемы безопасности с DNS, которые описаны ниже.
8.10.4.1 Поддельные ответы на запросы DNS
Первая проблема безопасности с DNS заключается в том, что DNS-серверы и клиенты могут быть обмануты злоумышленник может поверить в ложную информацию.Множество клиентов и серверов не проверяйте, все ли ответы, которые они получают, относятся к вопросы, которые они на самом деле задали, или ответы, которые они получают, приходя с сервера они спросили. В частности, серверы могут кэшировать эти «лишние» ответы, даже не задумываясь об этом, и отвечать на последующие запросы с помощью этих фиктивных кэшированных данных. Это отсутствие проверка может позволить злоумышленнику предоставить ложные данные вашим клиентам и серверы. Например, злоумышленник может использовать эту возможность для загрузки кеш вашего сервера с информацией о том, что его IP-адрес сопоставляется с именем хоста, которому вы доверяете для доступа без пароля через rlogin .(Это только одна из нескольких причин, по которым вы не должны разрешать BSD команды «r» через брандмауэр; см. полное обсуждение из этих команд ранее в этой главе.)
ПРИМЕЧАНИЕ: Более поздние версии DNS для UNIX (BIND 4.9 и новее) проверьте ложные ответы и менее подвержены этим проблемам. Более ранние версии и DNS-клиенты и серверы для других платформ могут все еще быть восприимчивым.
8.10.4.2 Несоответствие данных между именем хоста и IP-адреса DNS-деревья
Атака, описанная в предыдущем разделе, указывает на проблему несоответствие данных между именем хоста и IP-адресом деревья в DNS.В случае, подобном тому, который мы описан, если вы посмотрите имя хоста, соответствующее злоумышленнику IP-адрес (это называется обратным адресом ). поиск ), вы получите обратно имя хоста, которому доверяете. Если ты тогда найдите IP-адрес этого имени хоста (который называется двойным обратным поиском ), вы должны увидеть, что IP-адрес не соответствует тому, который использует злоумышленник. Это должно предупредить вас о том, что происходит что-то подозрительное. Обратный и двойной обратный поиск более подробно описан в разделе, называемом «Настройте поддельный DNS-сервер на хост-бастион для внешнего мира «позже в этом Обсуждение DNS.
Любая программа, которая принимает решения об аутентификации или авторизации на основе информация об имени хоста, полученная от DNS, должна будьте очень осторожны, чтобы проверить данные с помощью этого обратного поиск / метод двойного обратного просмотра. В некоторых операционные системы (например, SunOS 4.x и новее), эта проверка автоматически выполняется за вас gethostbyaddr () библиотечная функция. В большинстве другие операционные системы, вы должны выполнить проверку самостоятельно. Убедись что вы знаете, какой подход использует ваша собственная операционная система, и делаете убедитесь, что демоны, которые принимают такие решения в вашей системе, делают соответствующая проверка.(И убедитесь, что вы сохраняете это функциональность, если вы изменяете или заменяете libc .) Еще лучше не выполнять никакой аутентификации или авторизация, основанная исключительно на имени хоста или даже на Айпи адрес; нет никакого способа быть уверенным, что пакет приходит с IP-адреса, который, как он утверждает, пришел от, если в пределах пакет, который мог сгенерировать только истинный источник.
Некоторые реализации двойного обратного поиска не работают на хостах с несколько адресов, e.g., хосты с двойным подключением, используемые для прокси. Если оба адреса прописаны на одно имя, DNS поиск по имени вернет их оба, но многие программы будут читать только первый. Если соединение пришло со второго адрес, двойной реверс будет неправильно работать, даже если хост правильно прописан. Хотя вам следует избегать использования двойного реверса реализации, которые имеют этот недостаток, вы также можете захотеть убедитесь, что на ваших видимых извне многодомных хостах поиск по адрес возвращает разные имена для каждого адреса, и эти при поиске имен возвращается только один адрес.Для Например, для хоста с именем «foo» с двумя интерфейсами с именем «e0» и «e1» ищите «foo» вернуть оба адреса, поиск «foo-e0» и «foo-e1» вернуть только адрес этого интерфейса, и поиск по IP-адрес возвращает «foo-e0» или «foo-e1» (но не просто «foo») в зависимости от ситуации.
ПРИМЕЧАНИЕ: Для внутренних многодомных хостов вы, вероятно, не захотите ничего настраивать вверх так, как мы описали; если вы это сделаете, вам может потребоваться перечислить их по нескольким именам в любом месте вы хотите дать им разрешения, например, в / etc / экспортирует файлов.
8.10.4.3 Предоставление слишком большого количества информации атакующие
Еще одна проблема, с которой вы можете столкнуться при поддержке DNS с брандмауэром может выявить информация, которую вы не хотите раскрывать. Некоторые организации просматривают внутренние имена хостов (а также другую информацию о внутренних хостах) как конфиденциальную информацию. Они хотят защищают эти имена хостов так же, как они делают их внутренний телефон каталоги. Они нервничают, потому что внутренние имена хостов могут показывать названия проектов или другие сведения о продукте, или потому, что эти названия может выявить тип хостов (которые могут атаковать Полегче).Например, несложно догадаться, что это за система что-то, если его имя «lab-sun» или «Cisco-GW».
Даже самая простая информация об имени хоста может быть полезна злоумышленнику. кто хочет проникнуть на ваш сайт с помощью блефа, физически или в электронном виде. Использование информации таким образом — пример того, что обычно называется атакой социальной инженерии . В злоумышленник сначала исследует данные DNS, чтобы определить имя ключевого хоста или хостов на вашем сайте. Такие хосты часто будут указаны как DNS-серверы для домена или как MX-шлюзы для множества других хостов.Далее злоумышленник звонит или посещает ваш сайт, выдавая себя за специалиста по обслуживанию, и говорит, что ему нужно поработать на этих хостах. Он попросит пароли для хозяев (если он звонит по телефону), или попросить показать его машинный зал (если он заходит на площадку). Потому что злоумышленник кажется законным и, похоже, содержит инсайдерскую информацию о сайте — после все, он знает имена ваших ключевых хозяев — он часто получает доступ. Подобные атаки социальной инженерии требуют большой наглости со стороны злоумышленника, особенно если он действительно посещает ваш site, но вы удивитесь, насколько часто такие атаки оказываются успешными.
Помимо внутренних имен хостов, внутри DNS; информация, которая полезна на местном уровне, но к которому вы бы предпочли, чтобы у злоумышленника не было доступа к. DNS HINFO и Записи ресурсов TXT особенно показательны:
- HINFO: Информационные записи хоста
Они называют версию аппаратного обеспечения и операционной системы, которую выполняет машина. работает: это очень полезная информация для системы и сети администраторов, но также сообщает злоумышленнику, какой именно список ошибки, чтобы попробовать на этой машине.
- TXT: Записи текстовой информации
Это, по сути, короткие, неформатированные текстовые записи, используемые различными службами для предоставления различных Информация. Например, некоторые версии Kerberos и связанных инструментов использовать эти записи для хранения информации, которая на другом сайте может быть обрабатывается NIS / YP.
Злоумышленники часто получают информацию DNS о ваш сайт оптом, связавшись с вашим DNS-сервером и запрашивают перенос зоны, как если бы они были вторичным сервером для твой сайт.Вы можете предотвратить это с помощью фильтрации пакетов ( блокировка на основе TCP DNS-запросы, которые, к сожалению, заблокируют больше чем просто зональные передачи) или через xfernets директива текущих реализаций BIND (см. документацию BIND для получения дополнительной информации).
Вопрос, который следует иметь в виду при рассмотрении того, что Данные DNS, которые необходимо раскрыть: «Зачем злоумышленникам больше информации, чем необходимо? »Следующие разделы дать несколько советов, которые помогут раскрыть только те данные, которые вам нужны люди должны иметь.
8.10.5 Настройка DNS для скрытия Информация
Мы упоминали, что DNS имеет переадресацию запросов. возможности. [38] Воспользовавшись этой возможностью, вы можете дать внутренние хосты неограниченный просмотр как внутренних, так и внешних Данные DNS, ограничивая внешние хосты очень ограниченный («продезинфицированный») взгляд на внутреннее Данные DNS. Возможно, вы захотите сделать это для таких причины как:
Потому что ваши внутренние данные DNS слишком чутко показать всем.
Потому что вы знаете, что ваши внутренние DNS-серверы не все работают идеально, и вам нужен более удобный вид для внешний мир.
Потому что вы хотите предоставить определенную информацию внешним хостам и различная информация для внутренние хосты (например, вы хотите, чтобы внутренние хосты отправляли почту напрямую на внутренние машины, но внешние хосты, чтобы увидеть Запись MX, направляющая почту на хост-бастион).
На рис. 8.15 показано, как настроить DNS для скрытия информации; следующие разделы опишите все подробности.
Рисунок 8.15: Для сокрытия информации DNS можно использовать брандмауэр
8.10.5.1 Настройка подделки DNS-сервер на бастионном хосте для извне world to use
Первый шаг в сокрытии информации DNS от внешний мир — настроить поддельный DNS-сервер на хозяин бастиона. Этот сервер утверждает, что является авторитетным для вашего домен. Сделайте его сервером для вашего домена, названного по имени Записи сервера, поддерживаемые вашим родительским доменом. Если у вас несколько такие серверы для внешнего мира (которые вам следует — некоторые или все остальное может принадлежать вашему поставщику услуг), сделайте свой поддельный сервер — основной сервер из множества авторитетных серверов; остальные сделайте вторичными по отношению к этому первичному серверу.
Насколько знает этот фальшивый сервер на хосте-бастионе, он знает все о вашем домене. На самом деле все, о чем он знает, это любую информацию, которую вы хотите раскрыть внешнему миру. Этот информация обычно включает только базовое имя хоста и Информация об IP-адресах следующих хостов:
Машины в вашей сети периметра (т. Е. Машины, которые делают ваш брандмауэр).
Любые машины, которые нужны кому-то во внешнем мире, чтобы иметь возможность свяжитесь напрямую.Одним из примеров такой машины является внутренний Usenet. сервер новостей (NNTP), доступный с вашего поставщик услуг. (См. Раздел о NNTP в другом месте этой главы для примера того, почему вы можете захотеть разрешить это.) Другой пример — любой хост, доступный через Интернет. от проверенных аффилированных лиц. Внешние машины нуждаются в видимом снаружи название такой внутренней машины; это не должно быть внутренним настоящее имя машины, однако, если вы чувствуете, что настоящее имя конфиденциальная информация, или вы просто хотите изменить это по прихоти.
Кроме того, вам необходимо опубликовать записи MX для любые имена хостов или доменов, которые используются как часть адресов электронной почты в сообщения электронной почты и сообщения новостей Usenet, чтобы люди могли отвечать на эти сообщения. Имейте в виду, что люди могут отвечать на сообщения дней, через несколько недель, месяцев или даже лет после их отправки. Если данный хост или доменное имя широко используется как часть адреса электронной почты, вы можете необходимо сохранить запись MX для этого хоста или домен навсегда, или, по крайней мере, до тех пор, пока он не умрет и не исчезнет, поэтому что люди по-прежнему могут отвечать на старые сообщения.Если он появился в print, «навсегда» может быть слишком точным; сайты все еще получать электронную почту для машин, списанных на 5 и 10 лет назад.
Вам также необходимо будет публиковать поддельную информацию о любых машинах, которые может напрямую связываться с внешним миром. Множество серверов в Интернете (например, большинство основных анонимных FTP-серверов) настаивайте на знании имени хоста (а не только IP адрес) любых машин, которые связываются с ними, даже если они ничего не делают с именем хоста, но зарегистрируйте его. В ресурсе DNS записи, записи A (преобразование имени в адрес) и Дескриптор записей PTR (преобразование адреса в имя) поиск имен и адресов.
Как мы упоминали ранее, машины с IP адреса и нужные имена хостов выполняют обратный поиск. С реверсом поиск, сервер запускается с удаленного IP адрес входящего соединения и ищет имя хоста, которое соединение исходит от. Требуется IP-адрес (например, 172.16.19.67), переставляет его определенным образом (меняет частей и добавляет .IN-ADDR.ARPA , чтобы получить 67.19.16.172.IN-ADDR.ARPA и ищет PTR-запись для этого имени.В Запись PTR должна возвращать имя хоста для хоста с этим адресом (например, mycroft.somewhere.net ), который сервер затем использует для своих журналов или чего-то еще.
Как можно справиться с этим обратным поиском? Если все эти серверы хотел было имя для входа, вы можете просто создать подстановочный знак Запись PTR. Эта запись будет означать, что весь диапазон адресов принадлежит неизвестному хосту в конкретном домен. Например, вы можете искать * .19.16.172.IN-АДРЕС.ARPA возврат unknown.somewhere.net ). Вернув это информация была бы довольно полезной; по крайней мере, он скажет серверу администратор, чья это была машина (Где-то .net -е). Всем, у кого были проблемы с машина могла бы продолжить это через опубликованные контакты для где-то ..net домен .
Однако есть проблема с выполнением только этого. В попытке проверить данные, возвращаемые DNS, многое другое и больше серверов (особенно анонимных FTP-серверов) теперь выполняют двойной обратный поиск и не будут разговаривать с вами, если двойной обратный поиск завершается успешно.Это тот же поиск, который мы упомянутый выше; это, безусловно, необходимо для людей, которые предоставляют сервис, где им нужна любая степень аутентификации запрашивающего хозяин. Является ли анонимный FTP такой сервис это другой вопрос. Некоторые люди считают, что если поставить файл для анонимного FTP, у вас больше нет причина попытаться аутентифицировать хосты; в конце концов, вы пытаетесь дать информация прочь. Люди, использующие анонимный FTP серверы, которые выполняют двойной обратный поиск, утверждают, что люди, которые хотят службы несут ответственность за то, чтобы быть членами сетевого сообщества а для этого нужно быть идентифицируемым.Какая бы сторона аргумента вы согласны, это, конечно, правда, что сопровождающие некоторых из крупнейшие и самые известные анонимные FTP-серверы находятся на сторона, которая поддерживает двойной обратный поиск и не предоставляет сервис для вас, если двойной обратный поиск не увенчается успехом.
При двойном обратном поиске клиент DNS:
Выполняет обратный поиск для преобразования IP-адреса. адрес к имени хоста.
Выполняет регулярный поиск этого имени хоста для определения его номинального IP-адреса. адрес.
Сравнивает этот номинальный IP-адрес с исходным. Айпи адрес.
Ваш поддельный сервер должен предоставлять согласованные поддельные данные для всех хостов. в вашем домене, чьи IP-адреса будут видит внешний мир. Для каждого IP-адреса вы собственный, поддельный сервер должен опубликовать запись PTR с поддельное имя хоста, а также соответствующая запись A, которая отображает поддельное имя хоста обратно на IP-адрес. Например, для адреса 172.16.1.2 вы можете опубликовать PTR запись с именем хост-172-16-1-2.где-то.net и соответствующий Запись, которая отображает host-172-16-1-2.somewhere.net вернуться к соответствующему IP-адресу (172.16.1.2). Когда вы подключаетесь к какой-либо удаленной системе, которая пытается выполните обратный поиск своего IP-адреса (например, 172.16.1.2), чтобы определить ваше имя хоста, эта система вернет поддельное имя хоста (например, host-172-16-1-2 ). Если затем система пытается выполнить двойной обратный поиск, чтобы перевести это имя хоста на IP-адрес, он вернется 172.16.1.2, что соответствует исходному IP-адресу и удовлетворяет проверке согласованности.
Если вы строго используете прокси для подключения внутренних хостов к внешний мир, вам не нужно настраивать фальшивую информацию для вашего внутренние хосты; вам просто нужно разместить информацию для хозяина или хосты, на которых запущен прокси-сервер. Внешний мир увидит только адрес прокси-сервера. Для большой сети это само по себе может сделать использование прокси-сервера для FTP имеет смысл.
8.10.5.2 Настройка настоящего DNS сервер во внутренней системе для использования внутренних хостов
Ваши внутренние машины должны использовать настоящий DNS информация о ваших хозяевах, а не поддельная информация, представленная внешний мир. Вы делаете это через стандартную Настройка DNS-сервера в какой-то внутренней системе. Ваш внутренние машины также могут захотеть узнать о внешних машинах, хотя, например, чтобы перевести имя хоста удаленного анонимного FTP-сайт на IP-адрес.
Один из способов добиться этого — предоставить доступ к внешним Информация DNS путем настройки вашего внутреннего DNS-сервер для запроса удаленного DNS серверам напрямую, в зависимости от ситуации, для разрешения запросов из внутренних клиенты о внешних хостах.Однако такая конфигурация требовать открытия фильтрации пакетов, чтобы позволить вашему внутреннему DNS-сервер для связи с этими удаленными DNS-серверы (которые могут быть на любом хосте в Интернет). Это проблема, потому что DNS На основе UDP, и, как мы обсудим в главе 6, вам необходимо заблокировать UDP, чтобы заблокировать внешний доступ к уязвимые службы на основе RPC, такие как NFS и NIS / YP.
К счастью, самый распространенный DNS-сервер ( UNIX под названием ) предоставляет решение этой дилеммы: форвардеры в каталоге / etc / named.загрузка сервера конфигурационный файл. Директива по форвардерам сообщает серверу, что, если он не знает самой информации уже (либо из собственной информации о зоне, либо из своего кеша), он должен перенаправить запрос на конкретный сервер и позволить этому другому сервер выяснит ответ, а не пытается связаться со всеми серверами через Интернет в попытке определить сам ответ. в /etc/ named.boot файл конфигурации, вы настроили линия пересылки , указывающая на поддельный сервер на бастионе хозяина; файл также должен содержать «подчиненная» строка, чтобы указать ему использовать только серверы на форвардеры линейка, даже если серверы пересылки медленно отвечают.
Использование механизма форвардеров действительно не имеет что-либо, связанное с сокрытием информации во внутреннем DNS-сервер; это имеет прямое отношение к созданию как можно более строгая фильтрация пакетов (т. е. с применением принципа наименьших привилегий), сделав так, чтобы внутренние DNS-серверу нужно только иметь возможность разговаривать с DNS-сервер хоста бастиона, а не DNS-серверы по всему Интернету.
Если внутренние узлы не могут связаться с внешними узлами, возможно, вы не захотите потрудитесь настроить все так, чтобы они могли разрешать имена внешних хостов.Прокси-клиенты SOCKS могут быть настроены для использования внешний сервер имен напрямую. Это упрощает вашу службу имен конфигурация несколько, но это усложняет ваше проксирование конфигурации, и некоторые пользователи могут захотеть разрешить имена хостов даже если они не могут связаться с ними (например, они могут быть интересно знать, является ли имя хоста в адресе электронной почты действительный).
На рисунке 8.16 показано, как работает DNS. с пересылкой; На рис. 8.17 показано, как это работает без переадресации.
Рисунок 8.16: DNS с пересылкой
Рисунок 8.17: DNS без пересылки
8.10.5.3 Внутренний DNS клиенты запрашивают внутренний сервер
Следующим шагом является настройка вашего внутреннего DNS клиенты могут задавать все свои запросы внутреннему серверу. На В системах UNIX вы делаете это через /etc/resolv.conf файл. Возможны два случая:
Когда внутренний сервер получает запрос о внутренней системе, или о внешней системе, которая находится в ее кеше, он отвечает напрямую и сразу, потому что он уже знает ответы на такие вопросы.
Когда внутренний сервер получает запрос о внешней системе которого нет в его кеше, внутренний сервер пересылает этот запрос на хост-сервер бастиона (из-за пересылки строка описано выше). Хост-сервер бастиона получает ответ от соответствующие DNS-серверы в Интернете и реле ответ на внутренний сервер. Тогда внутренний сервер отвечает исходному клиенту и кеширует ответ.
В любом случае, что касается клиента, он задал вопрос внутреннего сервера и получил ответ от внутреннего сервер.Клиент не знает, есть ли уже на внутреннем сервере знал ответ или должен был получить ответ от других серверов (косвенно через сервер-бастион). Следовательно /etc/resolv.conf файл будет выглядеть отлично стандарт на внутренних клиентов.
8.10.5.4 Bastion DNS клиенты также запрашивают внутренний сервер
Ключ ко всей этой конфигурации скрытия информации заключается в том, что DNS-клиенты на хосте-бастионе должны запрашивать внутренний сервер для информации, а не сервер на бастионе хозяин.Таким образом, DNS-клиенты на хосте-бастионе (например, Sendmail) могут использовать настоящие имена хостов и т. д. для внутренних хостов, но клиенты во внешнем мире не могут получить доступ к внутренние данные.
DNS сервер и конфигурации клиента полностью отдельный. Многие считают, что у них должны быть файлы конфигурации. в общем, что клиенты автоматически узнают о локальный сервер, и указание их в другом месте также будет указывать на сервер в другом месте. На самом деле перекрытия нет.Клиенты никогда не читают /etc/ named.boot , который сообщает серверу, что do, и сервер никогда не читает /etc/resolv.conf , который сообщает клиентам, что им делать.
Опять же, есть два случая:
Когда DNS-клиент на узле бастиона спрашивает о внутренняя система, она получает реальный ответ прямо из внутренней сервер.
Когда DNS-клиент на узле бастиона спрашивает о внешняя система, внутренний DNS-сервер перенаправляет запрос на DNS-сервер бастиона.В сервер бастиона получает ответ от соответствующего DNS-серверы в Интернете, а затем ретранслирует ответ на внутренний сервер. Внутренний сервер, в свою очередь, отвечает исходному клиенту на хосте бастиона.
DNS-клиенты на хосте бастиона могли получить информацию о внешних хостах напрямую, задав запрос DNS-сервер на бастионном хосте вместо одного на внутреннем хосте. Однако, если бы они это сделали, они не смогли бы получить «настоящую» внутреннюю информацию, которую только сервер на внутреннем хосте есть.Им понадобится эта информация, потому что они общаются с внутренними хостами, а также с внешними хосты.
8.10.5.5 Какая у вас система фильтрации пакетов необходимо разрешить
Чтобы эта схема переадресации DNS работала, любая система фильтрации пакетов между хостом-бастионом и внутренним системы должны позволять все нижеперечисленное (см. таблицу ниже для подробностей):
DNS-запросы от внутреннего сервера к бастиону хост-сервер: UDP-пакеты с порта 53 на внутренний сервер к порту 53 на хосте бастиона (правило A), и Пакеты TCP с портов выше 1023 на внутреннем сервер на порт 53 на хосте-бастионе (правило B).
Ответы на эти запросы от хоста-бастиона к внутреннему сервер: UDP-пакеты с порта 53 на хост бастиона на порт 53 на внутреннем сервере (правило C), и Пакеты TCP с битом ACK, установленным с порта 53 на хост-бастион к портам выше 1023 на внутреннем сервере (правило D).
DNS-запросы от хоста-бастиона DNS-клиенты на внутренний сервер: Пакеты UDP и TCP из портов выше 1023 на хосте бастиона на порт 53 на внутреннем сервере (правила E и F).
Ответы внутреннего сервера на этот хост-бастион DNS-клиенты: UDP пакеты и пакеты TCP с битом ACK, установленным из порт 53 на внутреннем сервере к портам выше 1023 на хосте бастиона (Правила G и H).
| Direc- | Source | Dest. | Pro- | Источник | Цел. | ACK | |||
|---|---|---|---|---|---|---|---|---|---|
| Правило | ция | Адр. | Адр. | tocol | Порт | Порт | Набор | Действие | |
A | Выход | Внутренний сервер | 9182 Хост53 | [39] | Разрешение | ||||
B | Out | Внутренний сервер TCP | 53 | Любой | Разрешение | ||||
C | In | Bastion Host | Внутренний сервер | 53 | [39] | Разрешение | |||
D | In | Bastion Host | Внутренний сервер | TCP | 8 | Разрешение | |||
E | В | Хост Bastion | Внутренний сервер | UDP | ] | Разрешение | |||
F | In | Bastion Host | Внутренний сервер | TCP | Разрешение | ||||
G | Выход | Внутренний сервер | Хост бастиона | UDP | 53 | > 1023 | |||
> 1023 | H | Out | Внутренний сервер | Bastion Host | TCP | 53 | > 1023 |
8.10.6 Настройка DNS без скрытия Информация
Описанный выше подход — не единственный вариант. Предполагать что вы не чувствуете необходимости скрывать свои внутренние Данные DNS из мира. В этом случае ваш Конфигурация DNS аналогична той, что мы описано выше, но это несколько проще. На рисунке 8.18 показано, как работает DNS. без сокрытия информации.
Рисунок 8.18: DNS без сокрытия информации
При таком альтернативном подходе у вас все еще должен быть бастион. хост DNS-сервер и внутренний DNS-сервер; однако один из них может быть вторичный сервер другого.Как правило, проще сделать DNS-сервер Bastion вторичный по отношению к внутреннему DNS-сервер, а также для поддержания вашего Данные DNS на внутреннем сервере. Вы все еще должны настроить внутренний DNS-сервер для пересылки запросы к DNS-серверу хоста-бастиона, но DNS-клиенты хоста бастиона могут быть настроены для запроса хост-сервер бастиона вместо внутреннего сервера.
Нужно настроить любую систему фильтрации пакетов между бастионами. хост и внутренний сервер, чтобы разрешить следующее (см. в таблице ниже):
DNS-запросы из внутреннего DNS сервер к бастиону DNS сервер: UDP-пакеты с порта 53 на внутренний сервер на порт 53 на хосте бастиона (правило A) и Пакеты TCP с портов выше 1023 на внутреннем сервер на порт 53 на хосте-бастионе (правило B).
Ответы DNS-сервера бастиона на внутренний DNS-сервер: UDP-пакеты с порта 53 на хосте-бастионе на порт 53 на внутреннем сервере (правило C) и TCP пакеты с битом ACK, установленным с порта 53 на хосте-бастионе на порты выше 1023 на внутреннем сервере (правило D).
Если хост-бастион также является вторичным сервером DNS а внутренний хост — это соответствующий DNS первичный сервер, вы также должны разрешить следующее:
DNS-запросы от хоста-бастиона DNS-сервер во внутренний DNS сервер: UDP-пакеты с порта 53 на хост бастиона на порт 53 на внутреннем сервере (обратите внимание, что это то же, что и правило C), и TCP-пакеты с портов выше 1023 на хосте-бастионе на порт 53 на внутреннем сервере (правило E).
Ответы внутреннего DNS-сервера на DNS-сервер бастиона: UDP пакеты с порта 53 на внутреннем сервере на порт 53 на бастионе хост (обратите внимание, что это то же самое, что и правило A), и Пакеты TCP с битом ACK, установленным с порта 53 на внутренний сервер к портам выше 1023 на хосте-бастионе (правило F).
Запросы на передачу зоны DNS от хоста-бастиона к внутренний сервер: пакеты TCP от порты выше 1023 на хосте бастиона на порт 53 на внутреннем сервере (обратите внимание, что это то же самое, что и правило E).
Ответы на передачу зоны DNS от внутреннего сервер к хосту бастиона: пакеты TCP с битом ACK, установленным с порта 53 на внутреннем сервере на порты выше 1023 на хосте бастиона (обратите внимание, что это то же самое, что и правило F).
| Direc- | Source | Dest. | Pro- | Источник | Цел. | ACK | ||
|---|---|---|---|---|---|---|---|---|
| Правило | ция | Адр. | Адр. | tocol | Порт | Порт | Набор | Действие |
A | Выход | Внутренний сервер | 9182 Хост53 | [40] | Разрешение | |||
B | Out | Внутренний сервер TCP | 53 | Любой | Разрешение | |||
C | In | Bastion Host | Внутренний сервер | 53 | [40] | Разрешение | ||
D | In | Bastion Host | Внутренний сервер | TCP | 8 | Разрешение | ||
E | In | Bastion Host | Внутренний сервер | TCP | Разрешение | |||
F | Out | Внутренний сервер | Bastion Host | TCP |
8.10.7 Обзор DNS Рекомендации
Настройте внешний DNS-сервер на хосте-бастионе для внешний мир для доступа.
Не делать записи HINFO видимыми снаружи Мир; либо не используйте их, либо настройте DNS для сокрытия информации, как описано выше.
Используйте последнюю версию BIND и двойной обратный поиск, чтобы избежать спуфинга.
Рассмотрите возможность сокрытия всех внутренних данных DNS и использования пересылка и поддельные записи; это не имеет смысла для всех сайтов, но может и для тебя.
Отключить передачу зон кому-либо, кроме ваших вторичных, с использованием пакета фильтрация или директива xfernets . Даже если вы решили не прятаться ваша информация DNS, вероятно, нет действительной причина для кого-либо, кроме ваших подчиненных, сделать перенос зоны, и запрет на перенос зон усложняет жизнь злоумышленники.
GRC | Администрация порта, для Интернет-порта 53
Трудно представить себе практическое использование Интернета без удобного сопоставления имен и IP-адресов, обеспечиваемого DNS.Фактически, единственная реальная угроза работе Интернета — это скрытая возможность масштабной распределенной атаки типа «отказ в обслуживании» (DoS), используемой для удержания первичного и вторичного DNS-серверов Интернета от сети достаточно долго для всех кэшированных копий DNS. записи, срок действия которых истекает по всему Интернету. (Это займет около недели.) Хотя такая согласованная атака на DNS не приведет к отключению самого Интернета, она лишит мир удобного именования доменов DNS, которое мы все считаем само собой разумеющимся, и фактически убьет Интернет из-за продолжающегося продолжительность приступа.Поскольку все используют DNS, практически все машины работают как клиенты DNS-серверов. Наши машины запрашивают и получают результаты «DNS-поисков», которые предоставляют IP-адрес, связанный с доменным именем и конкретной машиной, с которой мы хотим общаться. Точно так же на компьютере конечного пользователя довольно редко работает общедоступный DNS-сервер. Хотя опытные пользователи иногда запускают свои собственные локальные преобразователи DNS или кеши для повышения производительности и надежности Интернета, эти серверы не должны предоставлять свои службы DNS в Интернет.
Если наш анализ порта показывает, что порт 53 вашей системы открыт и прослушивает входящий трафик, вы должны определить, что происходит. Несмотря на то, что известно лишь несколько троянских программ, открывающих порт 53, точное поведение вредоносного ПО является постоянно изменяющейся целью . . . , поэтому периодические проверки безопасности здесь всегда имеют смысл.
Если вам интересно узнать больше о работе системы DNS в Интернете, следующие ссылки и документы расскажут всю историю:
DNS RFC:
Доменные имена — концепции и возможности:
http: // www.ietf.org/rfc/rfc1034.txt
http://www.faqs.org/rfcs/rfc1034.html
Доменные имена — реализация и спецификация:
http://www.ietf.org/rfc/rfc1035.txt
http://www.faqs.org/rfcs/rfc1035.html
RFC, связанные с DNS:
http://www.dns.net/dnsrd/rfc/
Троянские наблюдения: червь ADM, Lion
Все содержимое этой страницы защищено авторским правом © 2008 Gibson Research Corporation.Обзор DNS через порт 80/443
]> Обзор DNS через порт 80/443 Пекинский институт Интернета
2 / F, Building 5, № 58 Jinghai Road, BDABeijing 100176 [email protected] http://www.biigroup.com/ Пекинский институт Интернета Комната 2508, 25-й этаж, башня A, Time FortuneBeijing 100028 P. R. [email protected] http://www.biigroup.com/ Пекинский институт Интернета Комната 2508, 25-й этаж, башня A, Time FortuneBeijing 100028 П.Р. Чинар[email protected] http://www.biigroup.com/ Интернет-зона
Инженерная группа Интернет-задачhttp
DNS-транспорт по умолчанию использует UDP на порту 53. Есть много
мотивы, по которым пользователи или операторы могут предпочесть избегать отправки
DNS-трафик таким образом. Распространенное решение — использовать порт 80.
или 443; с обычным TCP, TCP с шифрованием TLS или полным HTTP (S).
В этой памятке рассматриваются возможные подходы и предлагаются некоторые
полезная информация для разработчиков.Серверы имен используют порт 53 как для UDP, так и для TCP.
. Тем не мение,
пользователи или операторы иногда считают полезным использовать
альтернативный способ доставки информации DNS и частого выбора порта
80 (порт HTTP по умолчанию) или 443 (порт HTTPS по умолчанию) для
с этой целью.
Есть несколько вариантов использования:
Случай 1. Брандмауэры или другие промежуточные ящики могут мешать нормальной работе DNS.
движение . Кроме того,
некоторые интернет-провайдеры и отели блокируют внешний DNS и выполняют
Перезапись DNS для отправки пользователей на рекламные или другие страницы, которые
они действительно предназначались, или сети могут использовать IP-адреса, которые вызывают
вводящее в заблуждение географическое положение пользователя.Пользователям может потребоваться поддержка DNSSEC, которая не развернута локально в
такой случай и так далее.
Случай 2. Пользователи могут использовать DNS через TLS или HTTPS для защиты конфиденциальности.
Это также позволяет DNS-клиенту аутентифицировать DNS-сервер.
Случай 3. Разработчикам может потребоваться DNS API более высокого уровня. Веб-разработчики могут
предпочитаете разные абстракции или знакомые инструменты, такие как JSON или
XML, передаваемый по протоколу HTTP или HTTPS.
Эта памятка не ставит своей целью разработку стандартов или инструментов.В
цель — рассмотреть различные варианты реализации в качестве
ссылка для разработчиков. Однако это может быть полезно для всех
надеясь разработать спецификации или реализации для DNS через
80/443.
Обратите внимание, что большинство реализаций, описанных в этом документе, являются
на порт 80/443 и в сочетании с TCP / TLS / HTTP (S). Основное внимание
здесь находится между преобразователями заглушек и рекурсивными серверами, а
обсуждение идет о преобразователе заглушек для рекурсивного сервера
коммуникация.Самый простой подход — просто переместить DNS-трафик на порт 80.
или 443 из 53. Этот подход обслуживает вариант использования требований 1.
Таким образом, весь протокол такой же, как и текущий DNS.
транспорт в TCP, за исключением того, что транспортный порт перемещен на порт 80
или 443. Разница между портами 80 и 443 в том, что
трафик порта 80 часто перехватывается как HTTP-трафик для
целей более глубокого осмотра, в то время как
трафик порта 443 обычно считается зашифрованным,
и обычно игнорируется средними полями.Один пример, когда
DNS транспортируется через порт 80/443 — один из резервных
случаи триггера DNSSEC NLnetLabs
.
Транспортировку DNS через порт 80/443 реализовать легко.
Разработчики могут просто запустить существующий DNS-сервер и настроить
программное обеспечение DNS для прослушивания портов 80/443. Клиент также может
применить это изменение без каких-либо существенных изменений.
Одним из недостатков этого подхода является то, что он может ввести в заблуждение
клиент из-за используемого порта.Например, клиенты могут
Считайте DNS over 443 безопасным протоколом, потому что обычно
сеанс будет зашифрован. Однако в данном случае это не так.
Другой подход — DNS через TLS на порт 443, который также
реализован в триггере DNSSEC.
DNS через TLS задокументирован, в котором
использует хорошо известный порт 853. Использование порта 443 для переноса
трафик вместо этого по-прежнему служит цели в варианте использования 1, поскольку некоторые
средние блоки могут блокировать трафик на порту 853.также обсуждает
профили аутентификации и конфиденциальности.
TLS дает много преимуществ для DNS. Во-первых, это значительно
снижает уязвимость беседы DNS для взлома.
Во-вторых, как и обычные файлы cookie TCP или DNS, он предотвращает распознавание
от использования в атаках усиления или отражения.
Кроме того, он обеспечивает конфиденциальность за счет шифрования разговора.
между клиентом и сервером.
Одна из проблем DNS over TLS — это его стоимость. По сравнению с UDP,
DNS-over-TCP требует дополнительного времени приема-передачи (RTT)
задержка для установления TCP-соединения (хотя TCP быстро открывается
может устранить это в некоторых случаях).Использовать
алгоритмов шифрования TLS добавляет дополнительный RTT, и результаты
при немного более высокой загрузке процессора. Сохранение сеанса открытым может
амортизировать задержку дополнительного RTT, но за счет состояния на
как на стороне клиента, так и на стороне распознавателя. Другая проблема заключается в том, что DNS
пакет через TLS на новом порту может быть сброшен каким-то средним
коробки. Еще одна проблема TLS — сложность развертывания, когда
аутентификация сервера. Если серверы аутентифицированы,
требуется управление сертификатами.В отличие от необработанного DNS через TCP с использованием порта 80/443, другой
опция инкапсулирует данные формата проводов DNS в тело HTTP
и отправляя его как трафик HTTP (S). Это тихо полезно в использовании
случаи 1 и 2 описаны во введении. Этот подход
имеет то преимущество, что HTTP обычно проходит даже через
худшие брандмауэры кафе или гостиничного номера, так как работающая сеть
просмотр ожидается пользователями Интернета.
Использование HTTP также выигрывает от постоянного TCP-соединения HTTP.
концепция бассейна (см. раздел 6.3 дюйма),
какой DNS на TCP-порту 53 не имеет. Обратите внимание, что если HTTP / 2 (см.
), тогда могут быть параллельные
потоки, и ответы на разные потоки могут приходить
не работает.
Наконец, как и DNS через TLS, HTTPS обеспечивает целостность данных и
Конфиденциальность. Рекомендуется использовать такое шифрование.
Основная методика работает следующим образом:
Клиент создает сообщение с запросом DNS. Клиент инкапсулирует сообщение DNS в протоколе HTTP (S).
тело сообщения и назначает параметры с помощью HTTP
заголовок.Клиент подключается к серверу и выдает HTTP (S)
Метод запроса POST. Сервер декапсулирует пакет HTTP в запрос DNS и
разрешает DNS-запрос. Сервер инкапсулирует DNS-ответ в HTTP (S) и
отправляет его обратно через сеанс HTTP (S).
Обратите внимание, что если исходный запрос DNS отправляется TCP, первые два
бит пакета — это длина сообщения, и его следует удалить.
(Это верно только в том случае, если какое-то программное обеспечение переводит из DNS
протокол к DNS через HTTP, например, через прокси.Родные
реализациям это, конечно, не понадобится.)
реализация данной методологии на языке программирования Go
(https://github.com/BII-Lab/DNSoverHTTPinGO), а также C
(https://github.com/BII-Lab/DNSoverHTTP), поддерживается лабораторией BII.
Помимо преимуществ, упомянутых ранее, заголовок HTTP
упрощает расширение проводного формата DNS через HTTP (S). По сравнению с
создание новой опции в EDNS0 с использованием новых параметров в HTTP
заголовок гораздо проще развернуть, поскольку сообщения DNS с EDNS0
может не проходить некоторые средние коробки.Преимущество проводного формата DNS в том, что любое будущее
изменения в протоколе DNS будут прозрачно поддерживаться
как клиент, так и сервер, даже продолжая использовать HTTP.
Одним из недостатков упаковки DNS в HTTP является его стоимость. Упаковка
и распаковка использует ЦП и может привести к увеличению времени отклика.
Сообщения DNS через HTTP также могут быть сброшены
брандмауэры, которые перехватывают HTTP-пакеты. И следует отметить
что если используется HTTPS, то все обсуждение затрат,
преимущества и рекомендации по безопасности TLS в предыдущем
раздел также применим здесь.Как упоминалось в варианте использования 3, одной из причин использования REST HTTP API является
для веб-разработчиков, которым нужна информация о DNS, но которые предпочитают
не создавать сырые запросы. Они могут работать, создавая HTTP
запросы, отличные от реальных DNS-запросов.
В этом стиле реализации обмен данными DNS осуществляется в других
форматы, чем формат провода, например JSON
, или XML
. Также есть много
REST DNS API, разработанный поставщиками DNS или облачных сервисов.
Большинство этих API разрабатываются в рамках собственных
система с другой спецификацией.Но типичный запрос
клиент будет запрашивать URI в специальном формате. Это может быть
через команду HTTP POST, или он может кодировать содержимое
DNS-запрос в URI напрямую. Обычно есть HTTP (S) сервер
прослушивание порта 80/443, который проанализирует запрос и
создать DNS-запрос или команду операции DNS для реального
DNS. В отличие от DNS в проводном формате через HTTP (S), когда HTTP (S)
сервер получает ответ, он создает ответ, помещая
Данные DNS в различные структурированные форматы, такие как JSON, XML, YAML,
или даже обычный текст.Однако у такого подхода могут быть проблемы, потому что это не так.
основан на традиционном протоколе DNS. Так что нет никакой гарантии
полнота и правильность протокола. Поддержка DNSSEC
также может быть проблемой, потому что ответ обычно не
содержат записи RR с ответом, что делает невозможным
клиент для проверки ответа.
Как и в случае с DNS, использующим формат передачи DNS через HTTP, использование шифрования
поощряется.
Спасибо Jinmei Tatuya за обзор.Спасибо Роберту Эдмондсу за
настаивая на шифровании. Спасибо Марку Делани за то, что он поднял
выдача не по порядку ответов. Спасибо Теду Харди за
упоминание идеи кодирования DNS-запроса непосредственно в URI.
& RFC1035; & RFC3234; & RFC5625; & RFC5966; & RFC7230;
& RFC7413; & RFC7540; & RFC7858; & RFC7871;
& I-D.dprive-dns-over-tls;
& I-D.hoffman-dns-in-json;
& I-D.mohan-dns-query-xml; Тесты DNSSEC потребительских широкополосных маршрутизаторов Влияние DNSSEC на широкополосные маршрутизаторы и брандмауэры Консультативный комитет по безопасности и стабильности ICANN Dnssec-Triggerbind — Bind9 не отвечает на внешние запросы DNS, пока порт 53 открыт
Я установил DNS-сервер bind9 на virtualmin и создал зону DNS для следующего домена со следующими серверами имен.
домен = thecrystalsms.com Сервер имен ns5.crystalhost.net ns6.crystalhost.net
И ns5, и ns6 разрешаются правильно до 182.93.78.27
И на моем сервере, когда я запускаю следующую команду
хост -t ns thecrystalsms.com
показывает
сервер имен thecrystalsms.com ns6.crystalhost.net.
Сервер имен thecrystalsms.com ns5.crystalhost.net.
Но когда я запрашиваю dns для thecrystalsms.com извне, он терпит неудачу.
Ниже приведены мои записи зоны DNS
$ ТТЛ 38400
@ В SOA ns5.crystalhost.net. root.ns5.crystalhost.net. (
1559739241
10800
3600
604800
38400)
@ IN NS ns5.crystalhost.net.
@ IN NS ns6.crystalhost.net.
thecrystalsms.com. IN A 182,93,78,27
www.thecrystalsms.com. IN A 182,93,78,27
ftp.thecrystalsms.com. IN A 182,93,78,27
m.thecrystalsms.com. IN A 182,93,78,27
localhost.thecrystalsms.com. IN A 127.0.0.1
webmail.thecrystalsms.com. IN A 182,93,78,27
admin.thecrystalsms.com. IN A 182,93,78,27
mail.thecrystalsms.com. IN A 182,93,78,27
thecrystalsms.com. В MX 5 mail.thecrystalsms.com.
thecrystalsms.com. IN TXT "v = spf1 a mx a: thecrystalsms.com ip4: 182.93.78.27 ip4: 182.93.78.27 ip6: fe80 :: 250: 56ff: fe8c: d4ad -all"
_dmarc.thecrystalsms.com. IN TXT "v = DMARC1; pct = 100; ruf = mailto: [email protected]; rua = mailto: [email protected]; p = отклонить"
Не могу понять, в чем проблема.
Сервер также перезагружался несколько раз.
Вывод netstat -an | grep: 53 дает
tcp 0 0 182.93.78.27:53 0.0.0.0:* СЛУШАТЬ
tcp 0 0 127.0.0.1:53 0.0.0.0:* СЛУШАТЬ
tcp6 0 0 ::: 53 ::: * СЛУШАТЬ
UDP 0 0 182.93.78.27:53 0.0.0.0:*
UDP 0 0 127.0.0.1:53 0.0.0.0:*
udp6 0 0 ::: 53 ::: *
Результаты сканера портов
Не показано: 840 закрытых портов, 142 фильтрованных порта
ПОРТОВАЯ ГОСУДАРСТВЕННАЯ СЛУЖБА
21 / tcp открыть ftp
22 / TCP открыть SSH
25 / tcp открыть smtp
53 / tcp открытый домен
80 / tcp открыть http
110 / tcp открытый pop3
143 / tcp открыть imap
443 / TCP открыть https
465 / tcp открыть smtps
587 / tcp открытое представление
993 / tcp открыть imaps
995 / tcp открыть pop3s
2222 / tcp открыто неизвестно
8000 / tcp открыть http-alt
8001 / tcp открыт неизвестно
8002 / tcp открыть teradataordbms
10000 / tcp открыть snet-sensor-mgmt
20000 / tcp открыто неизвестно
Выполнено Nmap: 1 IP-адрес (1 хост включен) просканирован за 20.40 секунд
Я запустил инструмент zenmap и нашел следующий результат
nmap -sS -sU -T4 -A -v thecrystalsms.com
Запуск Nmap 7.70 (https://nmap.org) в 2019-06-11 12:02 Стандартное время Непала
NSE: загружено 148 скриптов на сканирование.
NSE: предварительное сканирование сценария.
Запуск NSE в 12:02
Завершено NSE в 12:02, прошло 0,00 с.
Запуск NSE в 12:02
Завершено NSE в 12:02, прошло 0,00 с.
Запуск сканирования Ping в 12:02
Сканирование thecrystalsms.com (182.93.78.27) [4 порта]
Завершено сканирование Ping в 12:02, 0.Прошло 75 с (всего хостов: 1)
Запуск параллельного разрешения DNS для 1 хоста. в 12:02
Завершено параллельное разрешение DNS для 1 хоста. в 12:02, прошло 0,01 с
Запуск скрытого сканирования SYN в 12:02
Сканирование thecrystalsms.com (182.93.78.27) [1000 портов]
Обнаружен открытый порт 443 / tcp на 182.93.78.27
Обнаружен открытый порт 995 / tcp на 182.93.78.27
Обнаружен открытый порт 80 / tcp на 182.93.78.27
Обнаружен открытый порт 21 / tcp на 182.93.78.27
Обнаружен открытый порт 53 / tcp на 182.93.78.27
Обнаружен открытый порт 143 / tcp на 182.93,78,27
Обнаружен открытый порт 993 / tcp на 182.93.78.27
Обнаружен открытый порт 587 / tcp на 182.93.78.27
Обнаружен открытый порт 22 / tcp на 182.93.78.27
Обнаружен открытый порт 110 / tcp на 182.93.78.27
Обнаружен открытый порт 10000 / tcp на 182.93.78.27
Обнаружен открытый порт 20000 / tcp на 182.93.78.27
Обнаружен открытый порт 8007 / tcp на 182.93.78.27
Обнаружен открытый порт 465 / tcp на 182.93.78.27
Обнаружен открытый порт 8002 / tcp на 182.93.78.27
Обнаружен открытый порт 8000 / tcp на 182.93.78.27
Обнаружен открытый порт 2222 / tcp на 182.93,78,27
Завершено скрытое сканирование SYN в 12:02, прошло 2,04 с (всего 1000 портов)
Запуск сканирования UDP в 12:02
Сканирование thecrystalsms.com (182.93.78.27) [1000 портов]
Обнаружил открытый порт 53 / udp на 182.93.78.27
Увеличение задержки отправки для 182.93.78.27 с 0 до 50 из-за увеличения max_successful_tryno до 5
Увеличение задержки отправки для 182.93.78.27 с 50 до 100 из-за увеличения max_successful_tryno до 6
Предупреждение: 182.93.78.27 отказывается от порта из-за срабатывания ограничения повторной передачи (6).
Время сканирования UDP: около 31.Готово на 30%; ETC: 12:04 (осталось 0:01:08)
Время сканирования UDP: выполнено около 37,70%; ETC: 12:05 (осталось 0:01:41)
Кажется, у моего сервера тоже открыт порт udp. Кроме того, когда я ищу ns через командную строку, он показывает следующий результат
нс поиск thecrystalsms.com 182.93.78.27
Сервер: Неизвестный
Адрес: 182.93.78.27
Имя: thecrystalsms.com
Адрес: 182.93.78.27
Но когда я бегу nslookup thecrystalsms.com 8.8.8.8 ответ
Истекло время ожидания запроса DNS.таймаут составил 2 секунды.
Сервер: неизвестно
Адрес: 192.93.78.27
Истекло время ожидания DNS-запроса.
таймаут составил 2 секунды.
Истекло время ожидания DNS-запроса.
таймаут составил 2 секунды.
Истекло время ожидания DNS-запроса.
таймаут составил 2 секунды.
Истекло время ожидания DNS-запроса.
таймаут составил 2 секунды.
*** Истекло время ожидания запроса на неизвестное
Не удалось решить проблему с bind9 или где-то еще.
Сеть— Моя запись DNS может указывать только на IP-адрес. Как мне заставить его добраться до порта?
Простой ответ, связанный с уровнем вопроса
Игнорирование экзотических видов использования DNS, а также обратный поиск в DNS (не имеет отношения к вопросу), почти все виды использования DNS имеют вид:
- Клиент отправляет доменное имя (полное или иное) на DNS-сервер
- DNS-сервер возвращает информацию о домене из своих записей.Обычно запрашиваемая ключевая информация — это либо IP-адрес для связи с Интернетом / электронной почтой в этом домене, либо IP-адрес другого DNS-сервера, который лучше может предоставить эту информацию.
После того, как клиент связался с сервером, сервер перейдет к нему, и система DNS исчезнет из поля зрения.
Это означает, что системе DNS не требуется предоставлять информацию о портах, и она почти никогда этого не делает. Таким образом, хотя цель вопроса верна и часто выполняется, на самом деле это не система DNS, которая делает это.Поэтому ничего не получается 🙂
Идея состоит в том, что как только ваш клиент может найти конкретную машину или сервер, который он ищет, он должен прослушивать любые порты, которые он выбирает, и принимать / отклонять / отвечать на любые протоколы на любых настроенных портах.
Например, веб-службы HTTP обычно предоставляются через порт 80. Это означает, что, когда клиент знает IP-адрес машины, он может предположить, что отправка сообщения на порт 80 приведет к тому, что это сообщение будет прочитано / получено веб-службой этой машины.Но так быть не должно. Если сервер настроен на прослушивание входящих веб-запросов на порт 9000, любой клиент, имеющий доступ к порту 9000, сможет подключиться к своей веб-службе. Если сервер находится за прокси / NAT / маршрутизатором, который перенаправляет порт 10000 на порт 9000, а клиент отправляет веб-запрос на порт 10000, сервер получит его на порт 9000 и также ответит.
Вы спрашивали про отображение редиректа или переписывание в комментарии. Это функции, которые может выполнять веб-сервер. По сути, вы можете настроить веб-сервер (или большинство / множество веб-серверов), чтобы управлять тем, как он обрабатывает URL-адрес, полученный в запросе.Таким образом, он может внутренне изменять URL-адрес при получении, чтобы разные URL-адреса обрабатывались одинаково, или исправлять общие опечатки (сопоставление), или он может фактически ответить, чтобы сам клиент попросил второй раз, используя другой, заменяющий, URL-адрес. (перенаправление).
Они имеют свое применение и, в принципе, могут справиться с вашим вариантом использования, но они не кажутся вам «правильным» решением по следующим причинам:
- Я не думаю, что картографирование вообще поможет . Сопоставление почти полностью является внутренним для веб-сервера, в нем говорится, что «относитесь к этому URL-адресу так, как если бы это было URL-адресом ».Например, вы можете использовать сопоставление URL-адресов веб-сервера, чтобы позволить пользователю запрашивать форум, используя очень старые, старые и текущие URL-адреса (для удобства пользователя), используя «https://example.com/index.php?area-=forum&topic = 2 «, также» https://example.com/forum.php?topic=2 «и также» https://forum.example.com?topic=2 «, и обрабатывать это только один раз, сопоставляя первый два из них на третий URL-адрес внутренне, в качестве первого шага в обработке запроса. Поскольку эта цель влияет на путь запроса, а не на IP / порт, сопоставление не очень полезно для управления портами, и в вашем случае клиент вообще никогда не запрашивает 8080.
- Перенаправление будет работать, но может быть не тем, что вам нужно . Перенаправление на веб-сервере зависит от фактического получения запроса веб-сервером (поскольку это внутренние функции веб-сервера). Таким образом, веб-сервер в любом случае должен будет прослушивать порт 80, чтобы получить исходный запрос, чтобы ответить перенаправлением / картой. также должен был бы прослушивать порт 8080. Функционально ему потребуется правило перенаправления, чтобы сообщать любому клиенту, запрашивающему порт 80, чтобы он снова запрашивал его, используя URL-адрес «: 8080», что не похоже на то, что вы хочу сделать.Пользователь также увидит новый URL с «: 8080» в нем, хотя похоже, что вы хотите, чтобы он был «прозрачным» и не отображался.
- Также перенаправление будет работать только для перенаправления стандартного порта (80 или 443). — вы не можете перенаправить порт 2000 на 8080, скажем, потому что клиент не будет запрашивать 2000 по умолчанию, в первую очередь, поэтому он не будет никогда не доберусь до веб-сервера, даже если он слушал на 2000. Но это может не быть проблемой для вас.
Однако, если вы хотите «интеллектуальное» перенаправление, при котором только определенные запросы перенаправляются на 8080, это может быть подходящим вариантом, потому что перенаправление может включать логику, определяющую, какие URL-адреса следует перенаправить, тогда как отображение портов (ниже) будет отображать все .
Ответ на ваш вопрос: вы хотите, чтобы веб-сервер отвечал на веб-запросы, которые клиент отправляет на порт по умолчанию (80/443), но которые сервер фактически получает на порт 8080.
Это означает, что, как видите, вам нужно что-то среднее: сопоставляет порты между клиентом и сервером . Таким образом, клиент отправляет через порт 80 (порт по умолчанию, используемый веб-браузерами), но на самом деле он получает его через порт 8080 веб-сервером. Конечно, вам придется настроить веб-сервер для прослушивания порта 8080, поскольку это не стандартно, но это просто, и любой веб-сервер должен иметь возможность указывать свои прослушивающие порты.
Чаще всего это можно сделать внутри маршрутизатора / брандмауэра через сопоставление портов.
Проще говоря, для этого маршрутизатору дается правило, согласно которому все полученное, имеющее IP-адрес назначения и порт назначения = 80, должно передаваться в локальную сеть с изменением порта назначения на 8080. Ни веб-сервер, ни клиент не узнают об изменении (оно на 100% обрабатывается маршрутизатором), поэтому оно будет на 100% прозрачным для них обоих. У клиента не будет «: 8080» в URL-адресе, и ему не нужно будет ничего перенаправлять, поскольку он запрашивает порт 80, а веб-сервер может игнорировать порт 80 и прослушивать только 8080, поскольку он никогда не получает запросы на порт 80. .
Если вам нужен простой и понятный способ, похожий на то, что делает «DNS для портов», это, вероятно, самый близкий эквивалент тому, что вы просите в своем вопросе.
.