Would this not be compensated in the end-to-end TCP checksumming? And couldn't the traffic to bit-squatting domains be accounted for by the myriad bots that constantly scan the web on port 80?
It can be either TCP or UDP. Regardless, UDP has a checksum as well.
The likelihood of a bit-flip is very uncommon. Even taking into account the volume of computers out there, the likelihood of a bit-flip at the exact spot (in the domain name) and moment of a DNS lookup (before the checksum is calculated) is astronomically uncommon. This article is garbage.
I wonder if there are more sources of error than just RAM bit-flipping. The bit could be flipped anywhere it's stored or passing through. If that is the case, the error rate would be orders of magnitude higher.
Comments
Would this not be compensated in the end-to-end TCP checksumming? And couldn't the traffic to bit-squatting domains be accounted for by the myriad bots that constantly scan the web on port 80?
DNS is not a TCP protocol.
It can be either TCP or UDP. Regardless, UDP has a checksum as well.
The likelihood of a bit-flip is very uncommon. Even taking into account the volume of computers out there, the likelihood of a bit-flip at the exact spot (in the domain name) and moment of a DNS lookup (before the checksum is calculated) is astronomically uncommon. This article is garbage.
I wonder if there are more sources of error than just RAM bit-flipping. The bit could be flipped anywhere it's stored or passing through. If that is the case, the error rate would be orders of magnitude higher.
TCP (or UDP) checksums only cover the packet when it is in transit & don't protect the information when it is stored in a device such as a DNS server.