I'm wondering if the string length or alignment could affect it, too. For example, if memory is allocated in 16byte chunks, longer domain names might have a larger chance for having a bit flipped in the active part of the string (instead of the padding). Just speculating wildly here.
There's no padding in DNS requests (having written my own DNS decoding routines). There's also very little that can change in a DNS packet that won't cause an error---basically, the only thing that can change without causing a DNS decoding error are text-related fields (say, the payload of a TXT or SPF record type) and even then, given the restrictions on character sets in DNS host names (and the crazy compression scheme used for domain names), it's actually surprising to see bit-6 errors, as that bit should cause more invalid domain names than not.
Edited because I thought bit-6 errors would flip letter case (upper to lower, lower to upper) when it's bit-5 that will do that.
I wasn't thinking about padding in the DNS packets as much as I was thinking about padding in string routines, for example if you malloc a block to hold "www.example.com", and then pass that string onto whatever resolver library you use.
I'm a little skeptical of this whole thing. Obviously, one other thing about bit errors in DNS packets is that they need to not break label compression.
Do you mean the whole article, or just the parent post? Because we're probably talking about bit errors while the domain name is still just a string in application memory, not when it's being assembled to a DNS packet or in transit. So I don't see how label compression comes into play.
