2 ms·
I would rule out UDP vs TCP before testing DNS as they may have a bug in the network stack from a recent kernel update and that should be ruled out first. [Edi
by LinuxBender 4y ago
I would rule out UDP vs TCP before testing DNS as they may have a bug in the network stack from a recent kernel update and that should be ruled out first.
[Edit 3] I am seeing the same thing to 1.1.1.1. But I can also reproduce this to a few other places on the internet... Yet I do not see this to a handful of UDP listeners I have throughout the US. It seems to be route specific but not CF specific. Perhaps someone here has a 1thousand eyes account and happens to have TCP and UDP probes around the world? The "nc" tests should be performed against all the open resolvers and many authoritative servers around the world to compare results.
Simple tests can be done with "nc" to take dig out of the picture. netcat should be available in macports and homebrew. If not, nmap also has a version of netcat. I suggesting taking dig out of the picture as it overrides the OS tcp and socket default options.
time nc -vnz -w1 1.1.1.1 53
time nc -vnzu -w1 1.1.1.1 53
The same tests could also be done against any daemons listening for UDP on something other than port 53 to rule out mac or other devices on your network intercepting port 53 and trying to do something intelligent with it.
- xrayarx 4y ago% time nc -vnz 1.1.1.1 53 Connection to 1.1.1.1 port 53 [tcp/*] succeeded! nc -vnz 1.1.1.1 53 0,00s user 0,00s system 8% cpu 0,073 total % time nc -vnzu 1.1.1.1 53 Connection to 1.1.1.1 port 53 [udp/*] succeeded! nc -vnzu 1.1.1.1 53 0,00s user 0,00s system 61% cpu 0,009 total
- deleted 4y ago[deleted]
- LinuxBender 4y agoI think nc has changed behavior. Using nmap I get more consistent results. nmap -iL /dev/shm/list.txt -sU -p53 nmap -iL /dev/shm/list.txt -sT -p53 /dev/shm/list.txt being a list of open resolvers and other UDP listeners on the internet. Give nmap a shot if testing.