[Unbound-users] how to filter/reject incoming requests for invalid qdomain?

W.C.A. Wijngaards wouter at nlnetlabs.nl
Mon Sep 17 09:55:55 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gábor,

So, a long email where I want to try to tell you that you are trying
to fix the wrong problem.  Because, unbound is doing the 'right
thing', and you are caught 'in the middle' between two places doing
the 'wrong thing'.  But, as it may be, you can get away by doing
nothing, and both other ends are suffering because of their own
wrongdoing.

On 09/17/2012 11:10 AM, Gábor Lénárt wrote:
> Hi All,
> 
> I use unbound as recursive name server. However (it seems) some
> broken clients sends "odd" requests what - IMHO - unbound should
> reject at the first place.  But instead it tries to resolve anyway
> and administrators of the given authoritative nameservers
> complaining that I bomb them with invalid requests what I should
> (according to them) stop ASAP.  What they say (only two examples
> for now):

These authority server operators are wrong.  And they give you the
wrong task.  The authority servers are not RFC-compliant, and are the
cause of these problems.  They should change the authority server
software, and install RFC-compliant authority DNS server software
(BIND and NSD are RFC compliant on this issue, I believe, and other
new authority software may be as well).

> Received a malformed qdomain from xx.yy.zz.ww,
> 'http://BLAH.SOME.DOMAIN': sending servfail Received a malformed
> qdomain from xx.yy.zz.ww, 'máig.SOME.DOMAIN': sending servfail

The RFC standards say that domain labels are binary-strings with case
unimportant.  Thus, those are valid query names.  (but not valid
hostnames - names of hosts).  The authority server MUST send an
NXDOMAIN for these names (if they indeed do not exist).  Such an
NXDOMAIN would have a TTL in it, that would also stop unbound from
querying for this name again (for a long time).

Thus, if the authority server was to send NXDOMAINs, the query traffic
would stop (be magnitudes smaller).  The end-client would get a proper
response (that the strange name does not exist).

> This is from an authoritative nameserver which is responsible for 
> zone "SOME.DOMAIN". Afaik this is a PowerDNS, but it's not my
> server at all

I hope you have some power to change them, if not, well they are
causing their own problems (no NXDOMAIN, thus no cache, thus lots of
queries).  You should not take action then.

> (xx.yy.zz.ww is my unbound). The second example is even more
> interesting as it sends "á" in the request (in the log file I was
> sent to, it's UTF-8 char, I guess this should be sent as puny
> coded, if it's IDN thing). The first example is "funny" as well,
> sending an URL instead of only the name.

Yes it is likely wrong, a mistake from the end-client that should get
a 'name does not exist' error.

> For sure, the best solution would be locating the clients sending
> these abnormal requests however it's a bit hopeless as there are
> hundreds of IPs using my unbound and also I'd like to be sure it
> won't happen again, that's why I'd like to reject them by my
> unbound (also it would help not to try to do a recursive resolving
> process: not wasting my resources on the unbound server).

If an NXDOMAIN was received, not much effort is expended by unbound,
and it can properly cache that result as well.

The servfail that you get now, also is fairly limited effort for your
unbound.  You could limit this effort further, if you really wanted
to, by caching the servfail for a longer time.

> What I (and the admins of that server) would like is to reject
> these kind of requests by unbound itself, instead of try to resolve
> with contacting the authoritative nameservers.

The admins of that server must fix their server.

Your must not fix your unbound for this. That makes the problems worse
as the authority server feels vindicated.  Some future development
will need people to adhere to standards and be 'future compatible',
also for things that are failures today.

> The issue is serious for me, as administrators of various
> authoritative name servers started to filter out my unbound because
> of getting "too much garbage" from it.

This is counterproductive.  Send the 'garbage' queries to your
upstream, they are the problem (nonstandard), and the place to fix it.
 If you do fix it in unbound somehow, then this is like putting
restrictive firewall policies in place that stop legitimate but
odd-looking traffic and these rules will then hamper future
development or have false positives and be the cause of other
problems.  And this is not actually a 'firewall' security issue, this
is a simple 'my server is nonstandard and using a lot of CPU'.

> This is unbound 1.4.17.
> 
> Please help me: how can I configure this?
> 
> Thanks for any help/advice in advance,

If this turns into a DoS attack, you could block individual names,
unbound will treat these names as valid names, also for blocking them
with local-zone and local-data statements.  (because, they are valid
names).  You may have to escape some characters when you configure
them, with a backslash.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQVvOrAAoJEJ9vHC1+BF+NNV0P/2PkLvHthqF1i9bBrFrIG9P5
Eu5oawMl8ZoFUalTXOH+W6JDK1ee0lKfutkIXSFYh6e0Sapn4fJ77S3rEzf9sHpD
ia00CUc8f+M39etTUMt+wLeyfrc+i5gPth3aRH/neWhlz7UcttEOf0Xs5XVsiVuL
1HBc3NFd00DrOzXllGgn93fqS6DAAOJvZt0SscX9y0WVPSH6SLnlnrurUdkPQ5dS
QsljXOxJnF7Q8ytX8h/8/EImFshysQriLBdP5x8+7vqAwPqC0M7BBmDgNVzBQCLw
6QqzW/MvqSlTmXZ8G38lTSDKp2bRBVStte4hHyXyKCwSyE9t3zNc9HV3ddFGSBxm
R3JeCy10F/oAvwapP3iPYOBoTpBddVSIac1aAhWDJwKz37HD1ybsVd1Q1N989hLZ
q2AwuPYVTxv3bw6ZTv1t3HfMfNCNq1IZF9pGnWTWR+QCxpd0ArvsCAKfJFBBZHNQ
ZYryfRQNFFhh3ImdoL0YT0AtktadrX2Ml2WpxPq7zmSi0eQDTrnyQSbw18i9Y2kL
KGUJ8sPofJksfBBinfCA/aoYY+wxnC60GRlw+Lv+akA0rMqMAU9qBG8rV9D9An6I
i4cbenQ/UlyhXUOn2CJ5D48g9JSkf1Srl9XO43KWmaNWuYSXt6335/q0b+Y9Kt0a
H4ue051js2AcBozm/waO
=tTYv
-----END PGP SIGNATURE-----



More information about the Unbound-users mailing list