Когда я перехожу к своему локальному диапазону портов в Debian 7, я вижу, что мой временный диапазон портов:
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
Мой /etc/sysctl.conf пусто.
Обычно это означает, что все запросы, исходящие от этого преобразователя сервера имен, должны использовать порты из этого диапазона. Однако, используя tcpdump, когда я смотрю на запрос и ответ DNS, созданные с помощью dig, Я вижу, что запрос может использовать порт отправки до 1500.
Например, в следующих tcpdump пример (tcpdump udp and port 53 and host server.domain), запрос пришел с порта 15591. Это намного ниже минимального лимита порта сервера для эфемерных портов, который мы видели раньше: 32768. Другими словами, использование dig, Запросы DNS выходят за пределы диапазона локальных портов.
11:57:33.704090 IP baremetal.15591 > M.ROOT-SERVERS.NET.domain: 41939% [1au] A? r.arin.net. (39)
11:57:33.704400 IP baremetal.41573 > M.ROOT-SERVERS.NET.domain: 40945% [1au] A? t.arin.net. (39)
11:57:33.704541 IP baremetal.22658 > M.ROOT-SERVERS.NET.domain: 44090% [1au] AAAA? t.arin.net. (39)
11:57:33.705295 IP baremetal.13277 > M.ROOT-SERVERS.NET.domain: 42356% [1au] A? v.arin.net. (39)
11:57:33.705499 IP baremetal.48755 > M.ROOT-SERVERS.NET.domain: 32253% [1au] A? w.arin.net. (39)
11:57:33.705639 IP baremetal.55309 > M.ROOT-SERVERS.NET.domain: 64660% [1au] AAAA? w.arin.net. (39)
11:57:33.705812 IP baremetal.56652 > M.ROOT-SERVERS.NET.domain: 43023% [1au] A? y.arin.net. (39)
11:57:33.706012 IP baremetal.26383 > M.ROOT-SERVERS.NET.domain: 42377% [1au] AAAA? y.arin.net. (39)
11:57:33.706172 IP baremetal.12895 > M.ROOT-SERVERS.NET.domain: 13206% [1au] AAAA? z.arin.net. (39)
Интересно, что могло изменить диапазон эфемерных портов на моем Debian 7 и 8. Единственное, что, пожалуй, стоит упомянуть. Я использовал на одном из них ifenslave и один использует ifenslave для соединения двух портов Ethernet.
Резолвер - это сам сервер и
#cat /etc/resolv.conf
nameserver ::1
но он делает то же самое с nameserver 127.0.0.1 потому что ipv4 и ipv6 разделяют /proc/sys/net/ipv4/ip_local_port_range (ссылка) И я тоже пробовал.
Чтобы избежать путаницы с IPv6, я решил использовать только Ipv4. Я только добавил nameserver 127.0.0.1 к /etc/resolv.conf.
Результаты ниже с nameserver 127.0.0.1 в /etc/resolv.conf только.
Затем я выдал rndc flush очистить кеш DNS от преобразователя и dig google.com
Я открыл второе окно терминала и набрал tcpdump udp and port 53:
Много записей, но я заметил, что независимо от запроса (A, PTR ...) и принимающего хоста, DNS-запросы МОГУТ быть отправлены с порта ниже 32768
>strace -f dig www.google.com 2>&1 | egrep 'sendmsg|recvmsg|connect|bind'
open("/usr/lib/libbind9.so.80", O_RDONLY) = 3
[pid 10651] bind(20, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 10651] recvmsg(20, 0x7f5dd95cab60, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 10651] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\1\0\1", 32}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...>
[pid 10651] <... sendmsg resumed> ) = 32
[pid 10651] recvmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\201\200\0\1\0\1\0\4\0\4\3www\6google\3com\0\0\1\0\1"..., 65535}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 184
Эта проблема связана с моим брандмауэром. Поскольку временные порты могут быть выданы от (мое собственное предположение) от 1024 до 65000, это означает, что я не могу блокировать входящий трафик, поступающий с портов выше 1024, как в старые времена. Если я сделаю это, я замедлю или заблокирую разрешение DNS.
ОБНОВЛЕНИЕ: спасибо, я понимаю, что если я хочу использовать сервер в качестве преобразователя DNS, это означает, что я должен учитывать, что диапазон портов UDP 1024: 65535 является временным диапазоном портов.
Я не думаю, что с твоим ip_local_port_range или что это обычно неприменимо к этому типу сценария, я скорее считаю, что это напрямую связано с усложнением подделки ответов DNS.
Мы видим в вашем strace вывод, который у вас есть dig отправка дейтаграммы на 127.0.0.1 (там работает какой-то сервер-преобразователь), но tcpdump вывод, похоже, относится к трафику с этого сервера распознавателя, а не dig сам.
Обычный старый DNS (без DNSSEC) полагается только на идентификатор транзакции (16 бит) и данные в вопрос раздел, чтобы сопоставить ответ, полученный по UDP, с запросом, который был отправлен ранее.
Благодаря тому, что дейтаграммы UDP легко подделать, и только с 16 битами случайности, которые необходимо угадать, если у вас есть конкретное имя в качестве цели, это дает возможность угадать правильный идентификатор транзакции (в среднем 32k предположений) до получения реального ответа .
Следовательно, все современные серверы-резолверы будут изо всех сил стараться рандомизировать исходный порт для увеличения количества случайных битов, которые необходимо угадать.
Вам действительно нужен как можно больший диапазон портов, поэтому, по-видимому, он будет рандомизирован во всем диапазоне портов> 1024, что добавит значительное количество битов случайности по сравнению с тем, что дает вам стандартная обработка вашей ОС.
То есть, я думаю, что просто считается «лучшей практикой» игнорировать обычную обработку ОС локальных портов для сокетов.