[conspire] Stupid (DNS) software/bots

[Michael Paoli]

Ah, so "of course", not at all surprising that we find lots of
really stupid bot software out there attempting things.

And of course, such stupidity doesn't exclude itself
from DNS - software/clients/resolvers/whatever.

So, anyway, recent peek at my logs from named (BIND 9),
and at least hour(s) or so, over 98% of those log lines are ...

Yeah, seems some stupid bot traffic or otherwise significantly
flawed DNS client/resolver software out there.

So, CNAME.  Not supposed to have CNAME to CNAME,
but, well, such is in fact permissible, and is in practice even fairly
commonly seen - at least in moderation, and that's all reasonably
okay.  But, what if the chain of CNAME records is too long,
or loops?  Well, sane software deals with that.  It has a limit,
and in common practice that limit is 8 or 16 (at least among what
I've read and observed).  And that should be more than ample, as in
practice up to 3 CNAME chain should be more than ample to
cover most if not all real world scenarios/needs.

Well, anyway, ... I test.  :-)  I have a bunch of CNAME records in the
balug.org zone (for the curious, one can dump the zone with AXFR).
And among the entries, are some that in fact loop, anywhere from
directly right back to themselves, or through a fairly long chained
loop back to self.

Well, yeah, ... some DNS software / bots are ... stupid, or at least
very badly flawed.  Yep, peek at bit of recent log data from named,
and what sticks out as >98% of the most recent line entries?
query iterations limit reached
But I notice bit of pattern.  Most or all of those are entries of
general form (case insensitive):
cl-/base-36-digit-string/-test.balug.org.
Uhm, yeah, that cl- prefix on those ... those are Cname Loops!
And the digits correlate to the number of entries in the loop,
and position in the loop.
So, e.g. (from logs) we have:
CL-789abC0123456-Test.balUG.oRg
That's a C+1 (13 decimal) element loop, on the (7+1)th (8th) element
(starting point is effectively arbitrary - it is a loop, after all).
So, yeah ... stupid bot (or otherwise badly flawed) DNS software.
And from the mixed case, looks like that software probably randomly
varies the case (fair bit of DNS software will do that, notably to check
that things are in fact behaving case insensitive as required per RFCs,
even letsencrypt.org does that with their DNS verification)
the actual RR entries on those are all lower case.
Anyway, here's typical log entry (in at least part):
client 2607:f8b0:4004:1002::127#59077
(CL-789abC0123456-Test.balUG.oRg): query iterations limit reached

And in bit abbreviated form and symbolically, this is what those
CNAME loops look like:
cl-0-test -> cl-0-test
cl-01-test -> cl-10-test -> cl-01-test
...
cl-0123456789abcdefgh-test -> cl-h0123456789abcdefg-test ->
cl-gh0123456789abcdef-test ... cl-23456789abcdefgh01-test ->
cl-123456789abcdefgh0-test -> cl-0123456789abcdefgh-test

I do also have set of cc- entries, for Cname Chains - of various
lengths, which do end.

And for reasonably sane DNS software, should be able to test against
them fine, and they should generally resolve, or fail to resolve,
in an exceedingly timely manner.  DNS software should not
indefinitely loop on them - even in the case where there's a
CNAME loop.

Well, at least BIND 9 is more than "smart" enough to throttle
the particularly egregious clients.  Hmmm, of course I could
also add a bit more to fail2ban to cut 'em off for longer periods.

And not bad for a "little" (balug) VM, with only 1GiB of RAM, handling
all that DNS and the web sites, etc.

Hmmm... maybe I ought reverse the order of my loops on those
so they'd be slightly more intuitive?  But the order seems
right and intuitive for the chains, though, as for those,
the digit + 1 gives the CNAME hop(s) away from the end.

And if one wants some entries to test/play with ...
note that the cl- ones will never resolve to an address,
whereas the cc- ones will ... to the extent your resolver
or the like can follow "enough" hops (though it should give
up before the chain / hop count is too long/high).
cc-0-test.balug.org.
cc-1-test.balug.org.
...
cc-a-test.balug.org.
...
cc-j-test.balug.org.
cl-0-test.balug.org.
cl-01-test.balug.org.
...
cl-0123456789abcdefgh-test.balug.org.