Когда я перехожу к своему локальному диапазону портов в 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 является временным диапазоном портов.
решение1
Я не думаю, что с вашими настройками что-то не так ip_local_port_rangeили что они не применимы к такому типу сценариев. Я скорее полагаю, что это напрямую связано с усложнением подделки DNS-ответов.
В ваших straceвыходных данных мы видим, что вы digотправляете датаграмму 127.0.0.1(некоторому работающему там серверу-распознавателю), но tcpdumpвыходные данные, по-видимому, относятся к трафику с этого сервера-распознавателя, а не digк нему самому.
Обычный DNS (без DNSSEC) полагается только на [идентификатор транзакции (16 бит)](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) и данные в разделе *вопрос*, чтобы сопоставить ответ, полученный по UDP, с запросом, отправленным ранее.
Поскольку датаграммы UDP легко подделывать, а если в качестве цели указано конкретное имя, необходимо угадать всего 16 бит случайности, это делает вполне возможным угадать правильный идентификатор транзакции (в среднем 32 тыс. попыток) до того, как придет настоящий ответ.
Поэтому все современные серверы-резолверыприложат все усилия, чтобы рандомизировать исходный портдля увеличения количества случайных битов, которые необходимо угадать.
Вам действительно нужен как можно больший диапазон портов, поэтому, по-видимому, он будет рандомизировать весь диапазон портов >1024, что добавит значительное количество бит случайности по сравнению с тем, что дала бы вам обработка по умолчанию в вашей ОС.
Т.е., я думаю, что просто считается «лучшей практикой» игнорировать обычную обработку ОС локальных портов для сокетов.