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:, Dst:
>> 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:, Dst:
>> 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 
by changing the value of /proc/sys/net/netfilter/nf_conntrack_udp_timeout or 
nf_conntrack_udp_timeout_stream.  I'm guessing the former.  The little 
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
Conjecture is just a conclusion based on incomplete information. It isn't a 

Attachment: signature.asc
Description: OpenPGP digital signature

users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Reply via email to