Re: QNAME minimisation question
On 6/3/25 11:29, Nick Tait wrote:
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 ), and even
if I specify "-6" on the command-line it makes no difference? So if I
add one extra 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 = " 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 = 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.
Happy to help!
I've created
https://gitlab.isc.org/isc-projects/bind9/-/issues/5351
so we can improve logging. Your input on what sort of information is
useful would be much appreciated.
--
Petr Špaček
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
h
Re: QNAME minimisation question
On 3 Jun 2025, at 10:29, Nick Tait via bind-users wrote: > But I also noticed that delv only makes A queries (not ), and even if I > specify "-6" on the command-line it makes no difference? Have yo tried using an IPv6 address with the -x option? delv -x :::45.90.5.195 +ns +qmin +maxqueries=100 -- Stace -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: QNAME minimisation question
On 03/06/2025 22:06, Petr Špaček wrote: I've created https://gitlab.isc.org/isc-projects/bind9/-/issues/5351 so we can improve logging. Your input on what sort of information is useful would be much appreciated. Thanks very much for that. I've added a comment. :-) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: QNAME minimisation question
Hi Stace. The transport protocol used to ask the question is (or should be) independent of the question being asked. So in this case asking for a PTR record for an IPv6 address wouldn't change whether IPv4 or IPv6 is used to make the recursive queries. I've done a bit more testing on this, and it seems like if you use the +ns option, delv ignores the -4, -6 and -b options. I'm not sure if that is by design or not, but it would be useful to be able to control which source IP address delv uses for queries and whether delv queries for A or records? (It would also be good if it queried for both by default -- i.e. if neither -4 or -6 were specified?) Can anyone advise whether this something I should raise a bug report for? Nick. P.S. Using +ns also causes delv to ignore a server specified with the @ option, and in this case it logs a message like: ";; WARNING: using internal name server mode: '@8.8.8.8' will be ignored" On 03/06/2025 22:36, Stacey Marshall wrote: On 3 Jun 2025, at 10:29, Nick Tait via bind-users wrote: But I also noticed that delv only makes A queries (not ), and even if I specify "-6" on the command-line it makes no difference? Have yo tried using an IPv6 address with the -x option? delv -x :::45.90.5.195 +ns +qmin +maxqueries=100 -- Stace -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: QNAME minimisation question
The help text for delv says you can specify a source using -b, the same as
you can with dig:
Usage: delv [@server] {q-opt} {d-opt} [domain] [q-type] [q-class]
Where: domain is in the Domain Name System
q-class is one of (in,hs,ch,...) [default: in]
q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]
q-optis one of:
-4 (use IPv4 query transport only)
-6 (use IPv6 query transport only)
-a anchor-file (specify root trust anchor)
-b address[#port] (bind to source address/port)
etc...
The rest I don't know, yet.
Hope that helps, Greg
On Wed, 4 Jun 2025 at 07:46, Nick Tait via bind-users <
bind-users@lists.isc.org> wrote:
> Hi Stace.
>
> The transport protocol used to ask the question is (or should be)
> independent of the question being asked. So in this case asking for a
> PTR record for an IPv6 address wouldn't change whether IPv4 or IPv6 is
> used to make the recursive queries.
>
> I've done a bit more testing on this, and it seems like if you use the
> +ns option, delv ignores the -4, -6 and -b options. I'm not sure if that
> is by design or not, but it would be useful to be able to control which
> source IP address delv uses for queries and whether delv queries for A
> or records? (It would also be good if it queried for both by
> default -- i.e. if neither -4 or -6 were specified?)
>
> Can anyone advise whether this something I should raise a bug report for?
>
> Nick.
>
> P.S. Using +ns also causes delv to ignore a server specified with the @
> option, and in this case it logs a message like: ";; WARNING: using
> internal name server mode: '@8.8.8.8' will be ignored"
>
> On 03/06/2025 22:36, Stacey Marshall wrote:
> > On 3 Jun 2025, at 10:29, Nick Tait via bind-users wrote:
> >
> >> But I also noticed that delv only makes A queries (not ), and even
> if I specify "-6" on the command-line it makes no difference?
> > Have yo tried using an IPv6 address with the -x option?
> >
> >
> > delv -x :::45.90.5.195 +ns +qmin +maxqueries=100
> >
> >
> > --
> > Stace
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: QNAME minimisation question
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 ), and even
if I specify "-6" on the command-line it makes no difference? So if I
add one extra 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 = " 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 = 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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: QNAME minimisation question
On 6/3/25 12:06, Petr Špaček wrote: On 6/3/25 11:29, Nick Tait wrote: 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... I want to underline this happens with totally empty cache. If you try, get SERVFAIL (limits exceeded), and try again in 5 seconds, you will get an answer. As for number of serves involved and all that... well ... have a look at this graph: https://trans-trust.verisignlabs.com/?z=195.5.90.45.in-addr.arpa. It's not exactly trivial tree to walk through if you don't know where you are going and have max. 50 steps available. (BTW the chart does not not show A/ queries for NS names, only server names involved.) -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
