Wenn ich unter Debian 7 zu meinem lokalen Portbereich gehe, kann ich sehen, dass mein temporärer Portbereich wie folgt lautet:
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
Meins /etc/sysctl.confist leer.
Normalerweise würde das bedeuten, dass alle Anfragen, die von diesem Nameserver-Resolver kommen, Ports in diesem Bereich verwenden sollten. tcpdumpWenn ich mir jedoch eine mit erstellte DNS-Anfrage und -Antwort ansehe dig, kann ich sehen, dass die Anfrage einen Sendeport von nur 1500 verwenden kann.
Im folgenden tcpdumpBeispiel ( tcpdump udp and port 53 and host server.domain) beispielsweise kam die Anforderung von Port 15591. Dieser Wert liegt weit unter der niedrigsten Portgrenze des Servers für temporäre Ports, die wir zuvor gesehen haben: 32768. Mit anderen Worten: Bei Verwendung von liegen digDNS-Anforderungen außerhalb des lokalen Portbereichs.
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)
Ich frage mich, was den Portbereich der temporären Ports auf meinem Debian 7 und 8 geändert haben könnte. Das Einzige, was vielleicht erwähnenswert ist. Ich habe einen davon verwendet ifenslaveund einer dient ifenslavezum Verbinden von zwei Ethernet-Ports.
Der Resolver ist der Server selbst und
#cat /etc/resolv.conf
nameserver ::1
aber es macht genau das gleiche mit nameserver 127.0.0.1weil ipv4 & ipv6 Freigaben /proc/sys/net/ipv4/ip_local_port_range(Referenz) und ich habe es auch versucht.
Um Verwechslungen mit IPv6 zu vermeiden, habe ich mich entschieden, nur IPv4 zu verwenden. Ich habe nur nameserver 127.0.0.1hinzugefügt /etc/resolv.conf.
Die folgenden Ergebnisse gelten nur nameserver 127.0.0.1innerhalb der Tabelle /etc/resolv.conf.
Dann habe ich rndc flushden DNS-Cache vom Resolver geleert unddig google.com
Ich öffnete ein zweites Terminalfenster und gab ein tcpdump udp and port 53:
Viele Einträge, aber mir ist aufgefallen, dass DNS-Anfragen unabhängig von der Anfrage (A, PTR...) und dem empfangenden Host von einem Port unter 32768 gesendet werden KÖNNEN.
>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
Dieses Problem hängt mit meiner Firewall zusammen. Da temporäre Ports von (meiner eigenen Schätzung nach) 1024 bis 65000 vergeben werden können, bedeutet dies, dass ich eingehenden Datenverkehr von Ports über 1024 nicht wie früher blockieren kann. Wenn ich dies tue, verlangsame oder blockiere ich die DNS-Auflösung.
UPDATE: Danke, ich verstehe, dass ich, wenn ich einen Server als DNS-Resolver verwenden möchte, berücksichtigen muss, dass der UDP-Portbereich 1024:65535 der temporäre Portbereich ist.
Antwort1
Ich glaube nicht, dass mit Ihrer Einstellung etwas nicht stimmt ip_local_port_rangeoder dass sie auf diese Art von Szenario normalerweise nicht anwendbar wäre. Ich bin eher der Meinung, dass dies in direktem Zusammenhang damit steht, das Fälschen von DNS-Antworten zu erschweren.
Wir sehen in Ihrer straceAusgabe, dass Sie digein Datagramm an 127.0.0.1(einen dort laufenden Resolver-Server) gesendet haben, aber die tcpdumpAusgabe scheint sich auf den Datenverkehr von diesem Resolver-Server zu beziehen, nicht auf den Datenverkehr digselbst.
Einfaches altes DNS (ohne DNSSEC) verlässt sich nur auf die [Transaktions-ID (16 Bit)](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) und die Daten im Abschnitt *Frage*, um die über UDP empfangene Antwort der zuvor gesendeten Abfrage zuzuordnen.
Da UDP-Datagramme leicht zu fälschen sind und nur 16 Zufallsbits erraten werden müssen, wenn das Ziel einen bestimmten Namen hat, ist es durchaus möglich, die richtige Transaktions-ID zu erraten (im Durchschnitt 32.000 Versuche), bevor die echte Antwort eintrifft.
Daher alle modernen Resolver-Serverwerden sich alle Mühe geben, einen Quellport zufällig auszuwählenum die Anzahl der zu erratenden Zufallsbits zu erhöhen.
Sie möchten wirklich eine möglichst große Bandbreite an Ports, also wird vermutlich der gesamte Portbereich >1024 zufällig ausgewählt, was im Vergleich zu der Standardverarbeitung Ihres Betriebssystems eine erhebliche Anzahl an Zufälligkeitsbits hinzufügt.
Ich denke, es gilt einfach als „Best Practice“, die normale Handhabung lokaler Ports für Sockets durch das Betriebssystem zu ignorieren.