On 20180410 18: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
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
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
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.
and executed while you are still on the page? SELinux isn't particularly going
to solve that issue very well. If the http(s) connection stays alive while you
are on the page to support updates it can also support mining results through
the same link.
users mailing list -- email@example.com
To unsubscribe send an email to users-le...@lists.fedoraproject.org