QNAME minimisation question

[Nick Tait]

On 02/06/2025 23:30, Petr Špaček wrote:
> In short, with an empty cache, BIND will exceed pre-configured limit 
> on number of queries it can do. This is protection from various 
> attacks which misuse DNS to attack itself.

Thanks for the explanation!

This particular recursive query doesn't seem especially 
out-of-the-ordinary to me, in terms of the number of name servers 
returned for each authoritative zone, so it was a little surprising to 
me that it would hit the default limit setting. However when I took a 
closer look at the combined impact that QNAME minimisation and DNSSEC 
and IPv4+IPv6 has on the number of queries it is actually not so 
surprising after all...

> Here's how I found out.
>
> To test cold-cache scenario, the easiest is to run:
>
> delv +ns +qmin -d99 195.5.90.45.in-addr.arpa. PTR &> log

Using this as a starting point, I created a mawk expression to count the 
queries being performed by delv to answer this recursive query. In this 
test delv made 47 queries to get an answer.

But I also noticed that delv only makes A queries (not AAAA), and even 
if I specify "-6" on the command-line it makes no difference? So if I 
add one extra AAAA query for every A query, to match what I can see in 
my original packet capture (from BIND), the total number of queries that 
BIND would make to get an answer would be 70!

    $ delv -x 45.90.5.195 +ns +qmin +maxqueries=100 | mawk -- 'BEGIN { count = 0; acount = 0; } /^;; sending packet to / { while ($0 != "") { getline; if ($0 == ";; QUESTION SECTION:") { getline; sub(/^;/, ""); print; count++; if (/\tIN\tA$/) acount++; break; } } } END { print "NUMBER OF QUERIES = " count; print "DOUBLE-COUNTING A QUERIES TO COMPENSATE FOR MISSING AAAA = " count + acount; }'
    .				IN	NS
    arpa.				IN	NS
    .				IN	DNSKEY
    arpa.				IN	DNSKEY
    arpa.				IN	DS
    a.ns.arpa.			IN	A
    b.ns.arpa.			IN	A
    c.ns.arpa.			IN	A
    d.ns.arpa.			IN	A
    e.ns.arpa.			IN	A
    .				IN	NS
    in-addr.arpa.			IN	NS
    f.ns.arpa.			IN	A
    g.ns.arpa.			IN	A
    h.ns.arpa.			IN	A
    i.ns.arpa.			IN	A
    45.in-addr.arpa.		IN	NS
    net.				IN	NS
    arin.net.			IN	NS
    r.arin.net.			IN	A
    u.arin.net.			IN	A
    x.arin.net.			IN	A
    y.arin.net.			IN	A
    z.arin.net.			IN	A
    90.45.in-addr.arpa.		IN	NS
    ripe.net.			IN	NS
    45.in-addr.arpa.		IN	DNSKEY
    authdns.ripe.net.		IN	NS
    arin.authdns.ripe.net.		IN	A
    45.in-addr.arpa.		IN	DNSKEY
    in-addr.arpa.			IN	DNSKEY
    in-addr.arpa.			IN	DNSKEY
    5.90.45.in-addr.arpa.		IN	NS
    netcup.net.			IN	NS
    systems.			IN	NS
    xaas.systems.			IN	NS
    acns01.xaas.systems.		IN	A
    acns02.xaas.systems.		IN	A
    acns03.xaas.systems.		IN	A
    acns04.xaas.systems.		IN	A
    acns05.xaas.systems.		IN	A
    root-dns.netcup.net.		IN	A
    third-dns.netcup.net.		IN	A
    second-dns.netcup.net.		IN	A
    195.5.90.45.in-addr.arpa.	IN	PTR
    90.45.in-addr.arpa.		IN	DS
    5.90.45.in-addr.arpa.		IN	DS
    NUMBER OF QUERIES = 47
    DOUBLE-COUNTING A QUERIES TO COMPENSATE FOR MISSING AAAA = 70

On that basis I've added this option to my BIND configuration:

    max-recursion-queries 100;

And when I repeated my original test, I get the expected answer. FYI My 
packet capture shows that the total number of queries transmitted on the 
wire was 46, which sounds about right considering that the root zone 
queries are answered from the mirror zone (and therefore don't appear in 
the packet capture).

Thanks again for helping to solve my problem.

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250603/4db6da0c/attachment.htm>