<font size=2 face="sans-serif">How does the </font><tt><font size=2>max-recursion-queries</font></tt><font size=2 face="sans-serif">
counter interact with DNSSEC validation and RPZ validation?   Are
the queries for these checks included in the </font><tt><font size=2>max-recursion-queries</font></tt><font size=2 face="sans-serif">
count or are they in a separate queue?</font>
<br>
<br>
<br><font size=2 face="sans-serif">Why I am asking:</font>
<br><font size=2 face="sans-serif">I've been running through my test of
the new code and getting a few hits on domains that I think resolve without
these limits.   I've have more work to do on validating if these domains
didn't resolve because of some momentary network or external DNS resolution
issue or something related to these new thresholds.  (or in the case
of 4842b.y.dotnxdomain.net, Cricket out registering new domains just to
mess with us.) </font>
<br>
<br><font size=2 face="sans-serif">My test is ~5 million unique A record
lookups I'm pushing to a test server at ~300 q/s.</font>
<br><font size=2 face="sans-serif">It has a lengthy RPZ enabled and DNSSec
validation on.</font>
<br><font size=2 face="sans-serif">After reading this thread, I'm flushing
the cache every 30 mins.</font>
<br>
<br><font size=2 face="sans-serif">I'm getting a handful of these messages,
some are just broken domains but a handful of them seem to resolve on DNS
servers on older bind code.  They do not seem to be timed with the
cache clearing.</font>
<br>
<br><font size=2 face="sans-serif">Dec  9 13:59:11 198.206.x.x named[13525]:
exceeded max queries resolving 'growthcentre.org/A'</font>
<br><font size=2 face="sans-serif">Dec  9 14:15:05 198.206.x.x named[13525]:
exceeded max queries resolving 'megadeth.rockmetal.art.pl/A'</font>
<br><font size=2 face="sans-serif">Dec  9 14:22:33 198.206.x.x named[13525]:
exceeded max queries resolving 'ns3.iplay.net/A'</font>
<br><font size=2 face="sans-serif">Dec 10 03:18:54 198.206.x.x named[13525]:
exceeded max queries resolving '4842b.y.dotnxdomain.net/DNSKEY'</font>
<br><font size=2 face="sans-serif">Dec 10 03:59:02 198.206.x.x named[13525]:
exceeded max queries resolving 'dsl-188-34-202-200.asretelecom.net/A'</font>
<br><font size=2 face="sans-serif">Dec 10 03:59:03 198.206.x.x named[13525]:
exceeded max queries resolving 'ns1.asretelecom.com/A'</font>
<br><font size=2 face="sans-serif">Dec 10 08:19:15 198.206.x.x named[13525]:
exceeded max queries resolving 'knurow.eu.org/A'</font>
<br><font size=2 face="sans-serif">Dec 10 08:27:36 198.206.x.x named[13525]:
exceeded max queries resolving 'lb.z.optimix.asia/NS'</font>
<br><font size=2 face="sans-serif">Dec 10 08:31:04 198.206.x.x named[13525]:
exceeded max queries resolving 'NS4-AUTH.ALLTEL.NET/A'</font>
<br>
<br>
<br>
<br><font size=5 color=blue><b>David A. Evans</b></font>
<br><font size=3><b>Enterprise IP/DNS Management</b></font>
<br><font size=3><b>Network Infrastructure Tools and Services</b></font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Evan Hunt <each@isc.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Stuart Henderson <stu@spacehopper.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">Tony Finch <dot@dotat.at>,
bind-users@lists.isc.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">12/09/2014 01:41 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: Problem
with BIND 9.10.1-P1 recursion limits</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">bind-users-bounces@lists.isc.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Tue, Dec 09, 2014 at 05:51:58PM +0000, Evan Hunt
wrote:<br>
> That's unexpected. I'll see if I can reproduce it.<br>
<br>
Okay, I can.<br>
<br>
Part of the problem is the somewhat crazypants DNS configuration<br>
of </font></tt><a href=www.ibm.com:/><tt><font size=2>www.ibm.com:</font></tt></a><tt><font size=2><br>
<br>
  $ dig +noall +answer </font></tt><a href=www.ibm.com><tt><font size=2>www.ibm.com</font></tt></a><tt><font size=2><br>
  </font></tt><a href=www.ibm.com><tt><font size=2>www.ibm.com</font></tt></a><tt><font size=2>.
           3600    IN    
 CNAME   </font></tt><a href=www.ibm.com.cs186.net><tt><font size=2>www.ibm.com.cs186.net</font></tt></a><tt><font size=2>.<br>
  </font></tt><a href=www.ibm.com.cs186.net><tt><font size=2>www.ibm.com.cs186.net</font></tt></a><tt><font size=2>.
 60      IN      CNAME   china-cdn.san.ibm.com.edgekey.net.<br>
  china-cdn.san.ibm.com.edgekey.net. 21600 IN CNAME china-cdn.san.ibm.com.edgekey.net.globalredir.akadns.net.<br>
  china-cdn.san.ibm.com.edgekey.net.globalredir.akadns.net. 900 IN
CNAME e7826.x.akamaiedge.net.<br>
  e7826.x.akamaiedge.net. 20      IN    
 A       23.59.201.136<br>
<br>
... like, *wow*.  A chain of five aliases with TTLs ranging from 20<br>
seconds to 6 hours, passing through five different zones (ibm.com,<br>
cs186.net, edgekey.net, akadns.net, akamaiedge.net), hosted by<br>
servers in three *more* zones (ihost.com, akam.net, and akadns.org,<br>
in addition to akadns.net and akamaiedge.net).  I had to almost<br>
double the maximum recursion queries to 99 to get this to work on<br>
an empty cache.  Yikes.<br>
<br>
Almost any non-empty cache will dodge the bullet. Preceeding the<br>
lookup of </font></tt><a href=www.ibm.com><tt><font size=2>www.ibm.com</font></tt></a><tt><font size=2>
with "dig @::1 ns com" causes the query to<br>
succeed.  Also, as previously noted, on 9.9 it will succeed without<br>
a five-minute delay if you just issue the query a second time.<br>
<br>
So, possible workarounds if this issue is causing problems for you:<br>
<br>
  - Ensure that the first query sent to a newly-primed recursive<br>
    resolver isn't quite as spectacular as this one;<br>
  - Add "max-recursion-queries 100;" to your options statement;<br>
  - Run 9.9.6-P1 instead of 9.10.1-P1<br>
<br>
The five-minute delay is still a bit of a puzzle. It happens because<br>
of this code in adb.c:<br>
<br>
        /* XXXMLG Don't pound on bad servers. */<br>
        if (address_type == DNS_ADBFIND_INET) {<br>
                name->expire_v4
= ISC_MIN(name->expire_v4, now + 300);<br>
                name->fetch_err
= FIND_ERR_FAILURE;<br>
                inc_stats(adb,
dns_resstatscounter_gluefetchv4fail);<br>
        } else {<br>
                name->expire_v6
= ISC_MIN(name->expire_v6, now + 300);<br>
                name->fetch6_err
= FIND_ERR_FAILURE;<br>
                inc_stats(adb,
dns_resstatscounter_gluefetchv6fail);<br>
        }<br>
<br>
The "now + 300" bit is where the five minutes comes from.  That's
code<br>
that's been around for years, and it is in 9.9, but apparently it's<br>
reached more easily in 9.10.  I'm looking into the reasons for this.<br>
<br>
The problem should be addressed in 9.10.2, which is likely to be<br>
released next month.<br>
<br>
-- <br>
Evan Hunt -- each@isc.org<br>
Internet Systems Consortium, Inc.<br>
_______________________________________________<br>
Please visit </font></tt><a href="https://lists.isc.org/mailman/listinfo/bind-users"><tt><font size=2>https://lists.isc.org/mailman/listinfo/bind-users</font></tt></a><tt><font size=2>
to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
bind-users@lists.isc.org<br>
</font></tt><a href="https://lists.isc.org/mailman/listinfo/bind-users"><tt><font size=2>https://lists.isc.org/mailman/listinfo/bind-users</font></tt></a><tt><font size=2><br>
</font></tt>
<br>