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