Debian 네임서버 해석기에서 dig를 사용하는 로컬 포트 ​​범위와 UDP 전송 포트의 차이점

Debian 네임서버 해석기에서 dig를 사용하는 로컬 포트 ​​범위와 UDP 전송 포트의 차이점

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보다 훨씬 낮습니다. 즉, 를 사용하면 digDNS 요청이 로컬 포트 ​​외부에 있습니다. 범위.

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두 개의 이더넷 포트를 결합하는 데 사용했습니다.

확인자는 서버 자체이며

#cat /etc/resolv.conf
nameserver ::1

하지만 nameserver 127.0.0.1ipv4 & ipv6이 공유하기 때문에 /proc/sys/net/ipv4/ip_local_port_range(참조) 그리고 나는 또한 그것을 시도했습니다.

IPv6과의 혼동을 피하기 위해 IPv4만 사용하기로 결정했습니다. 에만 nameserver 127.0.0.1추가 했습니다 /etc/resolv.conf.

아래 결과는 nameserver 127.0.0.1in /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출력 은 확인자 서버 자체 가 아닌 해당 확인자 서버의 트래픽과 관련된 것으로 보입니다 .dig127.0.0.1tcpdumpdig


DNSSEC가 없는 일반 기존 DNS는 [트랜잭션 ID(16비트)](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1)와 *질문*의 데이터에만 의존합니다. UDP를 통해 수신된 응답을 이전에 전송된 쿼리와 일치시키는 섹션입니다.

스푸핑하기 쉬운 UDP 데이터그램과 대상으로 특정 이름이 있는 경우 추측해야 하는 무작위성이 16비트에 불과하므로 실제 답변이 도착하기 전에 올바른 트랜잭션 ID(평균 32,000회 추측)를 추측하는 것이 가능합니다. .

따라서 모든 최신 리졸버 서버는소스 포트를 무작위로 지정하기 위해 최선을 다할 것입니다.추측해야 하는 임의의 비트 수를 늘리는 것입니다.

가능한 한 많은 포트 범위를 원하므로 아마도 1024보다 큰 포트 범위에서 무작위로 지정될 것입니다. 이는 OS의 기본 처리가 제공하는 것과 비교하여 상당한 수의 무작위성을 추가합니다.


즉, 소켓에 대한 로컬 포트의 일반적인 OS 처리를 무시하는 것이 단순히 "모범 사례"로 간주된다고 생각합니다.

관련 정보