On 04/11/18 09:46, Rick Stevens wrote: > On 04/10/2018 06:13 PM, Ed Greshko wrote: >> On 04/11/18 07:27, Rick Stevens wrote: >>> I seem to recall the same thing, that iptables opens incoming UDP port >>> 53 for some period of time if it saw an outgoing UDP port 53 request. >>> And I, like you, can't recall what that period was--although I think >>> it was 60 seconds. That's still more than the the basic Linux resolver >>> library's limit. >> >> That isn't how DNS requests work. >> >> When a client makes a DNS request the destination port is 53 and the source port is a >> random high port. >> >> Frame 3: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) >> Ethernet II, Src: PcsCompu_16:b2:62 (08:00:27:16:b2:62), Dst: Synology_76:13:a8 >> (00:11:32:76:13:a8) >> Internet Protocol Version 4, Src: 192.168.1.191, Dst: 192.168.1.1 >> User Datagram Protocol, Src Port: 43629, Dst Port: 53 >> Domain Name System (query) >> >> The client then listens on that same random port and the sever response is from >> source port 53 >> >> Frame 4: 253 bytes on wire (2024 bits), 253 bytes captured (2024 bits) >> Ethernet II, Src: Synology_76:13:a8 (00:11:32:76:13:a8), Dst: PcsCompu_16:b2:62 >> (08:00:27:16:b2:62) >> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.191 >> User Datagram Protocol, Src Port: 53, Dst Port: 43629 >> Domain Name System (response) > Yes, I probably didn't say it well. I was inferring that if an outgoing > UDP destination port 53 request was sent, then I think the iptables > conntrack plugin opens incoming UDP traffic with a source port of 53 > for some period of time, since this was (theoretically) a DNS request > that's expecting an answer. > > Sorry if I wasn't clear and I'm not 100% sure if conntrack actually does > the heavy lifting. I've never looked at the code. OK, you had originally said "opens incoming UDP port 53" when it should have been the "random port". Yes, conntrack is the module which controls this. I believe you can modify the time by changing the value of /proc/sys/net/netfilter/nf_conntrack_udp_timeout or maybe nf_conntrack_udp_timeout_stream. I'm guessing the former. The little documentation I found with a quick search was.... nf_conntrack_udp_timeout - INTEGER (seconds) default 30 nf_conntrack_udp_timeout_stream2 - INTEGER (seconds) default 180 This extended timeout will be used in case there is an UDP stream detected. -- Conjecture is just a conclusion based on incomplete information. It isn't a fact.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
