Silently drop queries for AAAA records
David A. Evans
Evans_David_A at cat.com
Tue Dec 14 21:25:28 UTC 2010
bind-users-bounces+evans_david_a=cat.com at lists.isc.org wrote on 12/13/2010
05:37:43 PM:
> Caterpillar: Confidential Green Retain Until: 01/12/2011
>
>
> In message <4D06A75F.7080400 at chrysler.com>, Kevin Darcy writes:
> > On 12/7/2010 5:31 PM, David A. Evans wrote:
> > >
> > > I'm in the mood to prove a point. I have a very poorly
> > > written application that is generating a few hundred queries per
> > > second of completely bogus AAAA records before attempting a lookup
of
> > > the correct A records. This is because the application was compiled
> > > with a IPv6 interface enabled on the severs so it assumes that v6 is
> > > available. It is not. The application owner does not see an issue
as
> > > they get the handful NXDOMAIN responses back in ~2 ms for each valid
> > > response and don't see any performance hit.
> > >
> > > I would like to silently drop the AAAA record lookups
instead
> > > of responding back with NXDOMAIN.
> >
> > NXDOMAIN? Is the application looking up a different *name* for its
AAAA
> > queries than for its A queries? If a single name owned A records but
no
> > AAAA records then the correct response from an AAAA-capable resolver
to
> > an AAAA query of the name, would be the so-called "NODATA" response
> > (NOERROR with 0 answers and an SOA RR in Authority Section for
negative
> > caching purposes, see RFC 2308 for details). NXDOMAIN, as another
poster
> > pointed out, could inhibit even A-record queries of the name, and
would
> > be the wrong response in that situation.
>
> It's likely to be applying the search list to AAAA queries and *not*
> stopping on NODATA then applying the search list to A queries. I've
> argued that this is wrong behaviour and that searches should stop
> on NODATA but some people are worried that this change in behaviour
> will break something that is depending on the searches skipping
> NODATA responses.
This is exactly what the app is doing, and they have a long search list,
and the application is walking through each suffix in the search list
chopping
off one domain at a time all the way down to .com so it is duplicating
many of the bogus queries several times on its way through the search
list.
I had them fully qualify the DNS names they put into the app with the
trailing
"." and it still appended the search list. (Even Microsoft gets that right
most of the time.)
>
> If you are worried about this then complain to the OS vendor to fix
> the resolver library.
>
> > > Thusly generating a performance hit as the application waits 2
seconds
> > > for the reply.
> > >
> > > I have found the filter-aaaa-on-v4 but it doesn't quiet do
> > > what I want. From the description and my testing it appears to
still
> > > reply with NXDOMAIN to these queries, it simply filters out the
> > > 'valid' AAAA records from IPV4 based replies. (which is a really
cool
> > > solution to other issues, but not what I need.)
> >
> > How nasty do you want to be? You could always add an AAAA record for
> > that name. Point it anywhere you want <evil laugh>
> >
> > If you point it to something simply non-existent, this solution seems
to
> > me only slightly ruder than silently dropping the queries.
> >
> > > Besides spinning up a bind 4.x box which google tells me did
> > > this by default, is there any way of doing this?
>
> BIND 4 did not block AAAA queries.
I wasn't seriously considering this. I just found a single google hit
when searching for solutions and it made me smile....
>
> > I think it would be a really *bad* idea to spin up a BIND 4.x
instance.
> > Do you really want a big ugly security hole on your network? What
about
> > the person that inherits this setup from you? Would they be conversant
> > in BIND 4.x setup and maintenance? I wouldn't wish BIND 4.x on
anyone...
> >
> > If you really want to go in the direction of dropping packets, I'd
look
> > at some sort of software-firewall intervention (iptables or whatever)
to
> > do the packet-dropping.
> >
> > On the other hand, if the app really is looking up a different name
for
> > AAAA than for A (see above), that opens up all sorts of options for
you.
> > You could set up that name as a zone by itself and simply return
REFUSED
> > for all of those queries (the response packet count, and potentially
the
> > application delay, would be the same, but the response packets would
be
> > smaller and your intent crystal clear). Or set up a forwarder and play
> > some games that way.
>
> Or stop worrying about this and realise that it will self correct
> as more sites start using IPv6 and AAAA records. IPv4 really has
> passed its "use by" date.
We have been pretty much ignoring the AAAA record lookups. The 'normal'
bad AAAA
records are about 15% of our total query count and so are not an issue in
any
way. However this application is generating ~30 queries per second with
spikes
over 100/s of AAAA queries per server it is deployed on. The environment
that
the application lives in has a load balancer in front of the bind servers
that
does have some capacity limits. Eliminating completely bogus queries
from this
environment should have been much easier and cheaper than increasing the
capacity
on the load balancer.
We were able to make some other changes to get the capacity that we needed
but
this is still a thorn in my side every time I look at my graphs and see
that
60% of the total query count is returning NXDOMAIN to a poorly formed AAAA
query.
>
> > - Kevin
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101214/da4f287f/attachment.html>
More information about the bind-users
mailing list