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 over TLS — Шифруем наши DNS запросы с помощью Stunnel и Lua / Habr

источник изображения

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах.

TLS (англ. transport layer security — Протокол защиты транспортного уровня) — обеспечивает защищённую передачу данных между Интернет узлами.

После новости «Google Public DNS тихо включили поддержку DNS over TLS» я решил попробовать его. У меня есть Stunnel который создаст шифрованный TCP туннель. Но программы обычно общаются с DNS по UDP протоколу. Поэтому нам нужен прокси который будет пересылать UDP пакеты в TCP поток и обратно. Мы напишем его на Lua.

Вся разница между TCP и UDP DNS пакетами:

4.2.2. TCP usage
Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it.

RFC1035: DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION

То есть делаем туда:

1. берём пакет из UDP
2. добавляем к нему в начале пару байт в которых указан размер этого пакета
3. отправляем в TCP канал

И в обратную сторону:

1. читаем из TCP пару байт тем самым получаем размер пакета
2. читаем пакет из TCP
3. отправляем его получателю по UDP

Настраиваем Stunnel

1. Скачиваем корневой сертификат Root-R2.crt в директорию с конфигом Stunnel
2. Конвертируем сертификат в PEM

   openssl x509 -inform DER -in Root-R2.crt -out Root-R2.pem -text

3. Пишем в stunnel.conf:

   [dns]
   client = yes
   accept  = 127.0.0.1:53
   connect = 8.8.8.8:853
   CAfile = Root-R2.pem
   verifyChain = yes
   checkIP = 8.8.8.8

   
   

То есть Stunnel:

1. примет не шифрованное TCP по адресу 127.0.0.1:53
2. откроет шифрованный TLS туннель до адреса 8.8.8.8:853 (Google DNS)
3. будет передавать данные туда и обратно

Запускаем Stunnel

Работу тунеля можно проверить командой:

nslookup -vc ya.ru 127.0.0.1

Опция ‘-vc’ заставляет nslookup использовать TCP соединение к DNS серверу вместо UDP.

Результат:

*** Can't find server name for address 127.0.0.1: Non-existent domain
Server:  UnKnown
Address:  127.0.0.1

Non-authoritative answer:
Name:    ya.ru
Address:  (здесь IP яндекса)

Пишем скрипт

Я пишу на Lua 5.3. В нём уже доступны бинарные операции с числами. Ну и нам понадобится модуль Lua Socket.

Имя файла: simple-udp-to-tcp-dns-proxy.lua

local socket = require "socket" -- подключаем lua socket

--[[--

Напишем простенькую функцию которая позволит отправить дамп пакета в консоль. Хочется видеть что делает прокси.

--]]--

function serialize(data)
    -- Преобразуем символы не входящие в диапазоны a-z и 0-9 и тире в HEX представление '\xFF'
    return "'"..data:gsub("[^a-z0-9-]", function(chr) return ("\\x%02X"):format(chr:byte()) end).."'"
end

--[[--

UDP в TCP и обратно

Пишем две функции которые будут оперировать двумя каналами передачи данных.

--]]--

-- здесь пакеты из UDP пересылаются в TCP поток
function udp_to_tcp_coroutine_function(udp_in, tcp_out, clients)
    repeat
        coroutine.yield() -- возвращаем управление главному циклу
        packet, err_ip, port = udp_in:receivefrom() -- принимаем UDP пакет
        if packet then
            -- > - big endian
            -- I - unsigned integer
            -- 2 - 2 bytes size
            tcp_out:send(((">I2"):pack(#packet))..packet) -- добавляем размер пакета и отправляем в TCP
            local id = (">I2"):unpack(packet:sub(1,2))    -- читаем ID пакета
            if not clients[id] then
                clients[id] = {}
            end
            table.insert(clients[id] ,{ip=err_ip, port=port, packet=packet}) -- записываем адрес отправителя
            print(os.date("%c", os.time()) ,err_ip, port, ">", serialize(packet)) -- отображаем пакет в консоль
        end
    until false
end

-- здесь пакеты из TCP потока пересылаются к адресату по UDP
function tcp_to_udp_coroutine_function(tcp_in, udp_out, clients)
    repeat
        coroutine.yield() -- возврашяем управление главному циклу
        -- > - big endian
        -- I - unsigned integer
        -- 2 - 2 bytes size
        local packet = tcp_in:receive((">I2"):unpack(tcp_in:receive(2)), nil) -- принимаем TCP пакет
        local id = (">I2"):unpack(packet:sub(1,2))                            -- читаем ID пакета

        if clients[id] then
            for key, client in pairs(clients[id]) do
                -- сравниваем query в запросе и ответе
                if packet:find(client.packet:sub(13, -1), 13, true) == 13 then -- находим получателя
                    udp_out:sendto(packet, client.ip, client.port) -- отправляем пакет получателю по UDP
                    clients[id][key] = nil                         -- очищаем ячейку
                    -- отображаем пакет в консоль
                    print(os.date("%c", os.time()) ,client.ip, client.port, "<", serialize(packet))
                    break
                end
            end
            if not next(clients[id]) then
                clients[id] = nil
            end
        end
    until false
end

--[[--

Обе функции сразу после запуска выполняют coroutine.yield(). Это позволяет первым вызовом передать параметры функции а дальше делать coroutine.resume(co) без дополнительных параметров.

main

А теперь main функция которая выполнит подготовку и запустит главный цикл.

--]]--

function main()
    local tcp_dns_socket = socket.tcp() -- подготавливаем TCP сокет
    local udp_dns_socket = socket.udp() -- подготавливаем UDP сокет

    local tcp_connected, err = tcp_dns_socket:connect("127.0.0.1", 53) -- соединяемся с TCP тунелем
    assert(tcp_connected, err) -- проверяем что соединились
    print("tcp dns connected") -- сообщаем что соединились в консоль

    local udp_open, err = udp_dns_socket:setsockname("127.0.0.1", 53) -- открываем UDP порт
    assert(udp_open, err)      -- проверяем что открыли
    print("udp dns port open") -- сообщаем что UDP порт открыт

    -- пользуемся тем что таблицы Lua позволяют использовать как ключ что угодно кроме nil
    -- используем как ключ сокет чтобы при наличии данных на нём вызывать его сопрограмму
    local coroutines = {
        [tcp_dns_socket] = coroutine.create(tcp_to_udp_coroutine_function), -- создаём сопрограмму TCP to UDP
        [udp_dns_socket] = coroutine.create(udp_to_tcp_coroutine_function)  -- создаём сопрограмму UDP to TCP
    }

    local clients = {} -- здесь будут записываться получатели пакетов

    -- передаём каждой сопрограмме сокеты и таблицу получателей
    coroutine.resume(coroutines[tcp_dns_socket], tcp_dns_socket, udp_dns_socket, clients) 
    coroutine.resume(coroutines[udp_dns_socket], udp_dns_socket, tcp_dns_socket, clients)

    -- таблица из которой socket.select будет выбирать сокет готовый к получению данных
    local socket_list = {tcp_dns_socket, udp_dns_socket} 

    repeat -- запускаем главный цикл
        -- socket.select выбирает из socket_list сокеты у которых есть данные на получение в буфере
        -- и возвращает новую таблицу с ними. Цикл for последовательно возвращает значения из новой таблицы  
        for _, in_socket in ipairs(socket.select(socket_list)) do
            -- запускаем ассоциированную с полученным сокетом сопрограмму
            local ok, err = coroutine.resume(coroutines[in_socket])
            if not ok then
                -- если сопрограмма завершилась с ошибкой то
                udp_dns_socket:close() -- закрываем UDP порт
                tcp_dns_socket:close() -- закрываем TCP соединение
                print(err) -- выводим ошибку
                return     -- завершаем главный цикл
            end
        end
    until false
end
  

--[[--

Запускаем главную функцию. Если вдруг будет закрыто соединение мы через секунду установим его заново вызвав main.

--]]--

repeat
    local ok, err = coroutine.resume(coroutine.create(main)) -- запускаем main
    if not ok then
        print(err)
    end
    socket.sleep(1) -- перед рестартом ждём одну секунду
until false

проверяем

1. Запускаем stunnel

   
   

2. Запускаем наш скрипт

   lua5.3 simple-udp-to-tcp-dns-proxy.lua

   
   

3. Проверяем работу скрипта командой

   nslookup ya.ru 127.0.0.1

   На этот раз без ‘-vc’ так так мы уже написали и запустили прокси который заворачивает UDP DNS запросы в TCP тунель.

   
   

Результат:

*** Can't find server name for address 127.0.0.1: Non-existent domain
Server:  UnKnown
Address:  127.0.0.1

Non-authoritative answer:
Name:    ya.ru
Address:  (здесь IP яндекса)
 

Если всё нормально можно указать в настройках соедидения как DNS сервер «127.0.0.1»

заключение

Теперь наши DNS запросы под защитой TLS.

P.S. Не даём гуглу лишней информации о нас

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

Есть ещё запрос на time.windows.com. Он уже не такой личный но как его отключить я так и не нашёл. Автоматическая синхронизация времени отключена.

ссылки

1. RFC1035: DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION
2. DNS поверх TLS
3. simple-udp-to-tcp-dns-proxy.lua
4. Составляем DNS-запрос вручную

Устранение неполадок DNS-серверов | Microsoft Docs

• 8/8/2019
• Время чтения: 16 мин

В этой статье

В этой статье описывается, как устранять неполадки на DNS-серверах.This article discusses how to troubleshoot issues on DNS servers.

Проверка IP-конфигурацииCheck IP configuration

1. Запустите ipconfig /all из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.Run ipconfig /all at a command prompt, and verify the IP address, subnet mask, and default gateway.

2. Проверьте, является ли DNS-сервер полномочным для имени, которое ищется.Check whether the DNS server is authoritative for the name that is being looked up. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.If so, see Checking for problems with authoritative data.

3. Выполните следующую команду.Run the following command:

   nslookup <name> <IP address of the DNS server>
   

   ПримерFor example:

   nslookup app1 10.0.0.1
   

   Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.If you get a failure or time-out response, see Checking for recursion problems.

4. Очистка кэша сопоставителя.Flush the resolver cache. Для этого выполните следующую команду в окне командной строки с правами администратора:To do this, run the following command in an administrative Command Prompt window:

   dnscmd /clearcache
   

   Или в окне администрирования PowerShell выполните следующий командлет:Or, in an administrative PowerShell window, run the following cmdlet:

   Clear-DnsServerCache
   

5. Повторите шаг 3.Repeat step 3.

Проверка неполадок DNS-сервераCheck DNS server problems

Журнал событийEvent log

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:Check the following logs to see whether there are any recorded errors:

• РазвертываниеApplication

• «Системные»System

• DNS-серверDNS Server

Тестирование с помощью запроса nslookupTest by using nslookup query

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.Run the following command and check whether the DNS server is reachable from client computers.

nslookup <client name> <server IP address>

• Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.If the resolver returns the IP address of the client, the server does not have any problems.

• Если сопоставитель возвращает ответ «сбой сервера» или «Запрос отклонен», зона может быть приостановлена или сервер может быть перегружен.If the resolver returns a «Server failure» or «Query refused» response, the zone is probably paused, or the server is possibly overloaded. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.You can learn whether it’s paused by checking the General tab of the zone properties in the DNS console.

Если сопоставитель возвращает ответ «запрос на превышение времени ожидания сервера» или «нет ответа от сервера», возможно, служба DNS не запущена.If the resolver returns a «Request to server timed out» or «No response from server» response, the DNS service probably is not running. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:Try to restart the DNS Server service by entering the following at a command prompt on the server:

net start DNS

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup.If the issue occurs when the service is running, the server might not be listening on the IP address that you used in your nslookup query. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов.On the Interfaces tab of the server properties page in the DNS console, administrators can restrict a DNS server to listen on only selected addresses. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке.If the DNS server has been configured to limit service to a specific list of its configured IP addresses, it’s possible that the IP address that’s used to contact the DNS server is not in the list. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.You can try a different IP address in the list or add the IP address to the list.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра.In rare cases, the DNS server might have an advanced security or firewall configuration. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов.If the server is located on another network that is reachable only through an intermediate host (such as a packet filtering router or proxy server), the DNS server might use a non-standard port to listen for and receive client requests. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53.By default, nslookup sends queries to DNS servers on UDP port 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой.Therefore, if the DNS server uses any other port, nslookup queries fail. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS.If you think that this might be the problem, check whether an intermediate filter is intentionally used to block traffic on well-known DNS ports. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.If it’s not, try to modify the packet filters or port rules on the firewall to allow traffic on UDP/TCP port 53.

Проверка на наличие проблем с достоверными даннымиChecking for problems with authoritative data

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.Check whether the server that returns the incorrect response is a primary server for the zone (the standard primary server for the zone or a server that uses Active Directory integration to load the zone) or a server that’s hosting a secondary copy of the zone.

Если сервер является сервером-источникомIf the server is a primary server

Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону.The problem might be caused by user error when users enter data into the zone. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.Or, it might be caused by a problem that affects Active Directory replication or dynamic update.

Если на сервере размещается дополнительная копия зоныIf the server is hosting a secondary copy of the zone

1. Изучите зону на главном сервере (сервере, с которого этот сервер извлекает зоны).Examine the zone on the master server (the server from which this server pulls zone transfers).

   Примечание

   Чтобы определить, какой сервер является главным сервером, проверьте свойства дополнительной зоны в консоли DNS.You can determine which server is the master server by examining the properties of the secondary zone in the DNS console.

   Если на главном сервере указано неправильное имя, перейдите к шагу 4.If the name is not correct on the master server, go to step 4.

2. Если на главном сервере указано правильное имя, убедитесь, что серийный номер на главном сервере меньше или равен серийному номеру на сервере-получателе.If the name is correct on the master server, check whether the serial number on the master server is less than or equal to the serial number on the secondary server. Если это так, измените либо главный сервер, либо сервер-получатель так, чтобы серийный номер на главном сервере был больше, чем серийный номер на сервере-получателе.If it is, modify either the master server or the secondary server so that the serial number on the master server is greater than than the serial number on the secondary server.

3. На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:On the secondary server, force a zone transfer from within the DNS console or by running the following command:

   dnscmd /zonerefresh <zone name>
   

   Например, если зона — corp.contoso.com, введите: dnscmd /zonerefresh corp.contoso.com.For example, if the zone is corp.contoso.com, enter: dnscmd /zonerefresh corp.contoso.com.

4. Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона.Examine the secondary server again to see whether the zone was transferred correctly. В противном случае у вас, вероятно, возникает проблема с переносом зоны.If not, you probably have a zone transfer problem. Дополнительные сведения см. в статье проблемы зонных передач.For more information, see Zone Transfer Problems.

5. Если зона была передана правильно, проверьте, правильно ли указаны данные.If the zone was transferred correctly, check whether the data is now correct. В противном случае данные в основной зоне неверны.If not, the data is incorrect in the primary zone. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону.The problem might be caused by user error when users enter data into the zone. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.Or, it might be caused by a problem that affects Active Directory replication or dynamic update.

Проверка проблем с рекурсиейChecking for recursion problems

Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные.For recursion to work successfully, all DNS servers that are used in the path of a recursive query must be able to respond and forward correct data. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:If they can’t, a recursive query can fail for any of the following reasons:

• Время ожидания запроса истекло, прежде чем его можно будет завершить.The query times out before it can be completed.

• Сервер, используемый во время запроса, не отвечает.A server that’s used during the query fails to respond.

• Сервер, используемый во время запроса, предоставляет неверные данные.A server that’s used during the query provides incorrect data.

Начните устранение неполадок на сервере, который использовался в исходном запросе.Start troubleshooting at the server that was used in your original query. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS.Check whether this server forwards queries to another server by examining the Forwarders tab in the server properties in the DNS console. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы.If the Enable forwarders check box is selected, and one or more servers are listed, this server forwards queries.

Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы.If this server does forward queries to another server, check for problems that affect the server to which this server forwards queries. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера.To check for problems, see Check DNS Server problems. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере.When that section instructs you to perform a task on the client, perform it on the server instead.

Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.If the server is healthy and can forward queries, repeat this step, and examine the server to which this server forwards queries.

Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер.If this server does not forward queries to another server, test whether this server can query a root server. Для этого выполните следующую команду:To do this, run the following command:

nslookup
server <IP address of server being examined>
set q=NS

• Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить.If the resolver returns the IP address of a root server, you probably have a broken delegation between the root server and the name or IP address that you’re trying to resolve. Следуйте инструкциям по тестированию неработающей процедуры делегирования, чтобы определить, где находится неработающее делегирование.Follow the Test a broken delegation procedure to determine where you have a broken delegation.

• Если сопоставитель возвращает ответ «запрос на превышение времени ожидания сервера», проверьте, указывает ли корневые ссылки на работоспособность корневых серверов.If the resolver returns a «Request to server timed out» response, check whether the root hints point to functioning root servers. Для этого используйте для просмотра текущей процедуры корневых ссылок .To do this, use the To view the current root hints procedure. Если корневые ссылки указывают на работающие корневые серверы, возможно, возникла проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет арбитру конфликтов запрашивать сервер, как описано в разделе Проверка проблем DNS-сервера .If the root hints do point to functioning root servers, you might have a network problem, or the server might use an advanced firewall configuration that prevents the resolver from querying the server, as described in the Check DNS server problems section. Также возможно, что рекурсивное время ожидания по умолчанию слишком мало.It’s also possible that the recursive time-out default is too short.

Тестирование неработающего делегированияTest a broken delegation

Начните тесты в следующей процедуре, запросив допустимый корневой сервер.Begin the tests in the following procedure by querying a valid root server. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.The test takes you through a process of querying all the DNS servers from the root down to the server that you’re testing for a broken delegation.

1. В командной строке на тестируемом сервере введите следующее:At the command prompt on the server that you’re testing, enter the following:

   nslookup
   server <server IP address>
   set norecursion
   set querytype= <resource record type>
   <FQDN>
   

   Примечание

   Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).Resource record type is the type of resource record that you were querying for in your original query, and FQDN is the FQDN for which you were querying (terminated by a period).

2. Если ответ содержит список записей ресурсов «NS» и «A» для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов «A» в качестве IP-адреса сервера.If the response includes a list of «NS» and «A» resource records for delegated servers, repeat step 1 for each server and use the IP address from the «A» resource records as the server IP address.

   • Если ответ не содержит запись ресурса NS, делегирование будет разорвано.If the response does not contain an «NS» resource record, you have a broken delegation.

   • Если ответ содержит записи ресурсов «NS», но нет записей ресурсов «A», введите » задать рекурсию» и выполните запрос по отдельности для записей ресурсов «a» серверов, перечисленных в записях NS.If the response contains «NS» resource records, but no «A» resource records, enter set recursion, and query individually for «A» resource records of servers that are listed in the «NS» records. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса «A» для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.If you do not find at least one valid IP address of an «A» resource record for each NS resource record in a zone, you have a broken delegation.

3. Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса «A» в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.If you determine that you have a broken delegation, fix it by adding or updating an «A» resource record in the parent zone by using a valid IP address for a correct DNS server for the delegated zone.

Просмотр текущих корневых ссылокTo view the current root hints

1. Запустите консоль DNS.Start the DNS console.

2. Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.Add or connect to the DNS server that failed a recursive query.

3. Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.Right-click the server, and select Properties.

4. Щелкните корневые ссылки.Click Root Hints.

Проверьте наличие базовых подключений к корневым серверам.Check for basic connectivity to the root servers.

• Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.If root hints appear to be configured correctly, verify that the DNS server that’s used in a failed name resolution can ping the root servers by IP address.

• Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться.If the root servers do not respond to pinging by IP address, the IP addresses for the root servers might have changed. Однако нередко можно увидеть перенастройку корневых серверов.However, it’s uncommon to see a reconfiguration of root servers.

Проблемы с зонными ошибкамиZone Transfer Problems

Выполните следующие проверки:Run the following checks:

• Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.Check Event Viewer for both the primary and secondary DNS server.

• Проверьте главный сервер, чтобы узнать, не отклоняется ли отправка для обеспечения безопасности.Check the master server to see whether it’s refusing to send the transfer for security.

• Проверьте вкладку зонные передачи свойств зоны в консоли DNS.Check the Zone Transfers tab of the zone properties in the DNS console. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке.If the server restricts zone transfers to a list of servers, such as those listed on the Name Servers tab of the zone properties, make sure that the secondary server is on that list. Убедитесь, что сервер настроен на отправку зонных передач.Make sure that the server is configured to send zone transfers.

• Проверьте наличие проблем на главном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера .Check the master server for problems by following the steps in the Check DNS server problems section. Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.When you’re prompted to perform a task on the client, perform the task on the secondary server instead.

• Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND.Check whether the secondary server is running another DNS server implementation, such as BIND. Если это так, проблема может быть вызвана одной из следующих причин:If it is, the problem might have one of the following causes:

  • Главный сервер Windows может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны.The Windows master server might be configured to send fast zone transfers, but the third-party secondary server might not support fast-zone transfers. В этом случае отключите передачу данных на главном сервере в консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера.If this is the case, disable fast-zone transfers on the master server from within the DNS console by selecting the Enable Bind secondaries check box on the Advanced tab of the properties for your server.

  • Если зона прямого просмотра в Windows Server содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.If a forward lookup zone on the Windows server contains a record type (for example, an SRV record) that the secondary server does not support, the secondary server might have problems pulling the zone.

Проверьте, работает ли на главном сервере другая реализация DNS-сервера, например BIND.Check whether the master server is running another DNS server implementation, such as BIND. Если да, то возможно, что зона на главном сервере содержит несовместимые записи ресурсов, которые Windows не распознает.If so, it’s possible that the zone on the master server includes incompatible resource records that Windows does not recognize.

Если на главном или вторичном сервере используется другая реализация DNS-сервера, проверьте оба сервера, чтобы убедиться, что они поддерживают одни и те же функции.If either the master or secondary server is running another DNS server implementation, check both servers to make sure that they support the same features. Можно проверить Windows Server на консоли DNS на вкладке Дополнительно страницы Свойства сервера.You can check the Windows server in the DNS console on the Advanced tab of the properties page for the server. В дополнение к полю включить вторичные получатели привязок на этой странице содержится раскрывающийся список Проверка имен .In addition to the Enable Bind secondaries box, this page includes the Name checking drop-down list. Это позволяет выбрать принудительное соответствие требованиям RFC для символов в DNS-именах.This enables you to select enforcement of strict RFC compliance for characters in DNS names.

Настройка средствами iptables использования нестандартного порта для запросов DNS SkyDNS

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

eth0 — внутренний интерфейс
eth2 — внешний интерфейс

Если все уже настроено и работает, то должно быть достаточно поместить правила в начало таблицы

# Делаем перенаправление для запросов из внутренней сети 
iptables -t nat -I PREROUTING 1 -i eth0 -p udp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 
iptables -t nat -I PREROUTING 1 -i eth0 -p tcp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 
# Делаем перенаправление для запросов с этой машины 
iptables -t nat -I OUTPUT 1 -o eth2 -p udp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 
iptables -t nat -I OUTPUT 1 -o eth2 -p tcp --dport 53 -j DNAT --to-destination 193.58.251.251:1253

Минимальная конфигурация

# Включаем форвардинг 
echo 1 > /proc/sys/net/ipv4/ip_forward 

# Чистим таблицы 
iptables -F FORWARD 
iptables -t nat -F PREROUTING 
iptables -t nat -F OUTPUT 
iptables -t nat -F POSTROUTING 

# Выставляем политику ACCEPT 
iptables -P FORWARD ACCEPT 
iptables -t nat -P PREROUTING ACCEPT 
iptables -t nat -P OUTPUT ACCEPT 
iptables -t nat -P POSTROUTING ACCEPT 

# Делаем перенаправление для запросов из внутренней сети 
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 

# Делаем перенаправление для запросов с этой машины 
iptables -t nat -A OUTPUT -o eth2 -p udp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 
iptables -t nat -A OUTPUT -o eth2 -p tcp --dport 53 -j DNAT --to-destination 193.58.251.251:1253 

# Делаем MASQUERADE к IP-адресу на внешнем интерфейсе 
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

Команда nslookup, получение информации от DNS

Команда nslookup — инструмент сетевого администрирования для запросов в доменной системе имен (DNS) с целью получения доменного имени, IP-адреса или другой информации из записей DNS.

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

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

Синтаксис команды nslookup

nslookup [ОПЦИИ] [ИМЯ/АДРЕС] [СЕРВЕР ИМЕН]

Наиболее распространенные опции и типы аргументов мы рассмотрим ниже в соответствующих примерах.

Получение IP-адреса домена

Если указать в качестве аргумента команды nslookup доменное имя, она возвращает его «запись A» (A — address, IP-адрес).

$ nslookup yandex.ru

Здесь поле Server означает IP-адрес DNS-сервера, а затем выводится информация об IP-адресе домена «yandex.ru».

Авторитативный и неавторитативный ответы

В приведенном результате присутствует фраза «Non- Authoritative Answer» (неавторитативный ответ).

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

Запрос записи MX

Запись MX (Mail eXchange, обмен почтой) хранит соответствие доменного имени почтовому серверу этого домена. Например, для redhat.com в этих записях содержатся почтовые серверы домена, через которые должна отправляться вся электронная почта на адреса «@redhat.com». Получить запись MX можно при помощи опции -query=mx:

$ nslookup -query=mx redhat.com

В рассмотренном выше примере для домена «redhat.com» есть 2 записи MX. Число рядом с именем сервера (5, 10) означает его приоритет. Чем меньше число, тем выше приоритет. То есть при отправке письма на адрес «@redhat.com» сначала будет использоваться сервер mx1.redhat.com, а если он недоступен — mx2.redhat.com.

Запрос записи NS

Запись NS (Name Server, сервер имен) содержит соответствие доменного имени DNS-серверу, авторитативному для заданного домена. Ее можно получить при помощи опции -query=ns:

$ nslookup -query=ns yandex.ru

Запрос записи SOA

Запись SOA (Start of Authority, начальная запись зоны) содержит информацию о зоне домена, адрес его администратора, серийный номер и т.д. Ее можно получить при помощи опции -query=soa:

$ nslookup -query=soa yandex.ru

origin — имя первичного сервера зоны
mail addr – адрес администратора домена ([email protected], так как символ @ в описании зоны имеет собственное значение, в данном поле он заменен на точку)
serial – серийный номер файла зоны, используется для учета изменений. Здесь может быть любое целое число, но стандартный формат — «ГГГГММДДНН», то есть сначала указывается дата, а НН (в данном случае 01) увеличивается в случае нескольких обновлений в день
refresh – период времени (в секундах), через который вторичный DNS-сервер отправит запрос первичному, чтобы проверить, поменялся ли серийный номер. В случае изменения будет сделан новый запрос для получения информации о зоне
retry – указывает интервал для повторного соединения с первичным DNS-сервером, если он по каким-то причинам не смог ответить на запрос
expire – указывает время хранения кэша вторичным DNS-сервером, по истечении которого он будет считаться устаревшим
minimum – минимальное время хранения кэша вторичным DNS-сервером до повторного запроса

Просмотр всех имеющихся записей DNS

При помощи опции -query=any мы можем просмотреть все записи DNS, которые у нас есть для заданного доменного имени:

$ nslookup -type=any google.com

Обратный поиск DNS

Если вместо имени указать в качестве аргумента IP-адрес, будет выполнен обратный поиск DNS:

$ nslookup 5.255.255.70

Использование конкретного DNS-сервера

Для разрешения доменного имени можно использовать конкретный сервер имен (в данном случае ns1.redhat.com):

$ nslookup redhat.com ns1.redhat.com

Обратите внимание, что в результате отсутствует фраза «Non-authoritative answer», так как ns1.redhat.com обладает всей информацией о зоне для redhat.com.

Изменение номера порта

По умолчанию DNS-серверы используют порт 53, но при необходимости можно указать другой номер порта посредством опции -port:

$ nslookup port 56 yandex.ru

Изменение интервала ожидания ответа

Интервал ожидания ответа по умолчанию можно изменить, указав желаемое значение в секундах с опцией -timeout:

$ nslookup -timeout=10 google.com

Режим отладки

При помощи опции -debug вы можете включить режим отладки:

$ nslookup -debug redhat.com

В режиме отладки при поиске выводится информация о пакетах.

Интерактивный режим

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

$ nslookup

возвращают результат, аналогичный команде

$ nslookup -query=soa yandex.ru

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

Заключение

Мы рассмотрели основы работы с командой nslookup, а также основные типы записей DNS. Для более подробной информации о команде и ее опциях можно обратиться к соответствующей man-странице.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.