[LinuxBender]

These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Both my DNS daemon and the kernel know not to respond to any of it. They stopped before I restarted with debugging enabled. I also get a lot of scans looking for DKIM keys and other poor configurations coming from the providers on this list. I would never block any of it, too much fun to watch.

[simmons]

Weird! The decrementing TTLs almost sounds like the sender is trying to perform some strange variation on a traceroute. With the long interval, maybe they are sending such packets to many destinations, and trying to build an evolving picture of Internet routing infrastructure?

[LinuxBender]

It's a weird one for sure. It's a new TCP SYN packet in between each interval. I would say it's a whole new connection but every sequence number and source port is the same which is common with poorly / lazily coded scanning scripts yet they set an MSS of 1400 but then lacks SackOK. EDIT: Turns out NMAP also lacks SackOK

    eth0  In  IP (tos 0x0, ttl 3, id 0, offset 0, flags [none], proto TCP (6), length 44)
    209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0
    eth0  In  IP (tos 0x0, ttl 2, id 0, offset 0, flags [none], proto TCP (6), length 44)
    209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0
    eth0  In  IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto TCP (6), length 44)
    209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0

I've enabled logging of invalid packets. Hopefully they will try again.

[saurik]

nmap's --traceroute uses this technique (but I don't know if it has a way to cause this long gap; this is just a demonstration that this is an oft-used technique).

[LinuxBender]

I just tried that with nmap using --traceroute -p 53 and it used new sequence numbers for each connection, different source ports. It did decrement but never went to 1 and I received responses along the way. NMAP did not set SackOK but it used my home MSS. Maybe someone wrote their own implementation trying to copy NMAP but missed something. Perhaps those servers are good for people trying to learn to write scanners.

[scrps]

Zone transfer shenanigans? Only thing I know that DNS uses TCP for.

[LinuxBender]

No, I get those all day long. Both zone transfer requests and attempts to do dynamic DNS updates which my DNS does not support dynamic DNS. My daemon will respond to those with rejected and NotImpl. Neither my DNS daemon nor the OS even responded to these probes and it was not even my doing. No SynAck from me so the kernel knew these were malformed or something I've enabled logging of invalid packets. Maybe they will try again.

For completeness sake TCP is used for a few other things on DNS these days such as falling back to TCP when the client does not support EDNS and the packet is bigger than 512 bytes which is common with DNSSEC. I do not have any large records. TCP is also used when encryption is implemented (DNS Over TLS) but that is usually on port 853 though it can be supported on 53 encryption can be opportunistic.

[scrps]

It was a bit of a drive-by guess on my part, certainly is weird.