DNS-TXT: Use character-string instead of Null terminated C string.

[traud]

When you sniff the DNS TXT records via Wireshark, the responses from the dsn2tcp daemon, you see two so-called character-string in each TXT record. The first one has the data. The second one is null bytes long and contains no data. All length bytes/indicators are correct. However, today, I faced a DNS forwarder that does not like null-byte-long character-strings and discards the whole TXT response. Consequently, my dns2tcp client does not get any response either.

The root cause: dns2tcp works with C strings internally. It does null terminate each string in the TXT record. However, in RFC 1035, character-string is defined as a length-value pair rather than string<Null>. I am not sure whether I fixed all places which expect/send a C string via DNS. Tests showed that a patched server still works with unpatched clients. However, unpatched clients send to stderr: Error while decoding reply max_len was … Anyway, I do not think this will be included in the upstream project. I am just reporting for those interested, controlling both client/server. And perhaps the maintainer can provide a hint which other places expect/rely on C string.

Anyway, anyway, thanks for dns2tcp as it helped me to write an exploit for an Open DNS Resolver. And because of a confirmed DNS Tunneling attack the CVSS raised enough, worth reporting it.

[alex-sector]

Thank you very much the contribution !

This project is very old (2006), and unfortunately I no longer wish to add features / fix to it. I put it back to Github for backup because the site that hosted the project (www.hsc.fr) has disappeared, and I know that this tool may still be used.

May be you can try -T KEY to bypass the issue, but without guarantee.

[traud]

That is OK. The main purpose was to document the issue. And yes, your tool is in Linux distributions like Debian (and therefore Ubuntu). And I know a public service still using it … I simply used those for a quick and dirty test (and then was stuck because it did not work on the fourth Open DNS Resolver, I tested). However your idea continues with one of the alternatives, Iodine is quite active …