Re: Trying to track down malformed TXT sources

(* Reply-to: dev-nulled *)

Hi Tom.

Thomas Cross wrote:

> Here are some examples that you can easily check yourself with
> nslookup or dig:
> 
> whitebusfamily.co.nz - In this case the string length for the TXT string
> appears to have been sent through a hex to decimal conversion when it
> should have been sent through a decimal to hex conversion.
> 
> democracynow.org - In this case the string length for the TXT string is too
> short.
> 
> wrongdiagnosis.com - In this case the second response simply has no string
> length.

Note that two of these domains, whitebusfamily.co.nz and wrongdiagnosis.com,
return SOAs with decidedly non-tinydns serial numbers (i.e., they don't look
like Unix epoch time stamps), so these can probably be ruled out (it's not
impossible to have the serial number return YYYYMMDDnn, just unlikely).
democracynow.org does look tinydns-ish.

> I used fpdns [2] to fingerprint the authoritative nameservers for each of
> these domains and they all come back as TinyDNS 1.05. If you suspect that
> fpdns does not properly identify TinyDNS then please let me know, but I am
> operating under the assumption that this result is accurate.

I had a quick look at fpdns, but my perl-fu isn't what it used to be (or
probably never was :-).  The heuristic looks a little ... open, but I
can't say definitively until I get a bit of spare time to poke at it.

>       The fact that each of these examples is malformed in a different way
> suggests that different software may be responsible for causing each of
> them to be malformed. There appears to be an ecosystem of different
> administration tools that allow users to manage TinyDNS database files.

The problem appears to be length based (I haven't packet sniffed yet, but dig
here is reporting extra and short lengths).  I don't think it's possible to
specify the length of a text record from the source config, so it's either
someone producing the data files directly themselves (I haven't checked if
this is feasible) or patching gone awry.

> If this analysis is correct, there are several potential courses
> of action that could be taken, including a patch to TinyDNS that sanity
> checks these string lengths before serving them.

If using the correct tools, this shouldn't be required (or even made
possible) by tinydns.

> Of course, if you feel
> that fpdns may have incorrectly identified these DNS servers it would also
> be helpful to know that so that I can continue to investigate this problem.

Like I said, two domains don't appear to be tinydns driven, but I guess that
will require confirmation from the content servers themselves.

Cheers.

-- 
Regards,
  Daryl Tester

"Oh Christmas tree, oh Christmas tree!  From hell's heart I stab at thee."
  -- A very Kaaahn! Christmas