Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248839 > unrolled thread

Needless DNS queries

Back to article view | Back to linux.debian.user

Contents

  Needless DNS queries Dieter Rohlfing <dr-erc@gmx.net> - 2022-06-07 17:10 +0200
    Re: Needless DNS queries David Wright <deblis@lionunicorn.co.uk> - 2022-06-07 17:30 +0200
    Re: Needless DNS queries Dan Ritter <dsr@randomstring.org> - 2022-06-07 17:40 +0200
      Re: Needless DNS queries Tim Woodall <debianuser@woodall.me.uk> - 2022-06-07 18:10 +0200
      Re: Needless DNS queries Greg Wooledge <greg@wooledge.org> - 2022-06-07 19:00 +0200
        Re: Needless DNS queries Darac Marjal <mailinglist@darac.org.uk> - 2022-06-07 19:40 +0200
          Re: Needless DNS queries Lee <ler762@gmail.com> - 2022-06-08 00:10 +0200
        Re: Needless DNS queries Tim Woodall <debianuser@woodall.me.uk> - 2022-06-08 00:20 +0200
          Re: Needless DNS queries Lee <ler762@gmail.com> - 2022-06-08 03:00 +0200
            Re: Needless DNS queries Greg Wooledge <greg@wooledge.org> - 2022-06-08 03:10 +0200
              Re: Needless DNS queries Lee <ler762@gmail.com> - 2022-06-08 07:30 +0200
    Re: Needless DNS queries Dieter Rohlfing <dr-erc@gmx.net> - 2022-06-14 15:10 +0200

#248839 — Needless DNS queries

Hello everybody,

I've installed AdguardHome to serve the clients in my home network.

After checking AdguardHome's query logs I noticed a lot of needless DNS
queries.

When a client queries for a domain and the answer is NXDOMAIN, there is
immediately a second query with the original domain name, but suffixed
with the domain name of my home network.

Example:

1. query: www.example.com (result NXDOMAIN)
2. query: www.example.com.home.lan (result NXDOMAIN)

home.lan is the domain name of my home network, /etc/resolv.conf
contains the following line:

>search home.lan

When I delete this line from /etc/resolv.conf, then the second query
doesn't appear, but I loose the ability to use unqualified hostnames to
refer to local clients. :-((

Up to now I thought, the domain names in the search option is appended
only to unqualified names and not to qualified names. This assumption
seems to be false.

My question: is it possible to apply the search list only to
unqualified names?

Thanks for reading and have a nice day.

Dieter

[toc] | [next] | [standalone]

#248840

On Tue 07 Jun 2022 at 17:01:21 (+0200), Dieter Rohlfing wrote:
> When a client queries for a domain and the answer is NXDOMAIN, there is
> immediately a second query with the original domain name, but suffixed
> with the domain name of my home network.
> 
> Example:
> 
> 1. query: www.example.com (result NXDOMAIN)
> 2. query: www.example.com.home.lan (result NXDOMAIN)
> 
> home.lan is the domain name of my home network, /etc/resolv.conf
> contains the following line:
> 
> >search home.lan
> 
> When I delete this line from /etc/resolv.conf, then the second query
> doesn't appear, but I loose the ability to use unqualified hostnames to
> refer to local clients. :-((

Try using just .home (or .corp or .mail) on its own, instead of .home.lan.

https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248841

Dieter Rohlfing wrote: 
> Hello everybody,
> 
> When a client queries for a domain and the answer is NXDOMAIN, there is
> immediately a second query with the original domain name, but suffixed
> with the domain name of my home network.
> 
> Example:
> 
> 1. query: www.example.com (result NXDOMAIN)
> 2. query: www.example.com.home.lan (result NXDOMAIN)
> 
> home.lan is the domain name of my home network, /etc/resolv.conf
> contains the following line:
> 
> >search home.lan
> 
> When I delete this line from /etc/resolv.conf, then the second query
> doesn't appear, but I loose the ability to use unqualified hostnames to
> refer to local clients. :-((
> 
> Up to now I thought, the domain names in the search option is appended
> only to unqualified names and not to qualified names. This assumption
> seems to be false.
> 
> My question: is it possible to apply the search list only to
> unqualified names?


search		Search list for host-name lookup.  By default, the search
list contains one entry, the local domain name.  It is determined from
the local hostname returned by gethostname(2); the local domain name is
taken to be everything after the first '.'. Finally, if the hostname
does not contain a '.', the root domain is assumed as the local domain
name

	This may be changed by listing the desired domain search
path following the search keyword with spaces or tabs separating the
names.  Resolver queries having fewer than ndots dots (default is
1) in them will be attempted using each component of the search path in
turn until a match is found.  For environments with multiple subdomains
please read options ndots:n below to avoid man-in-the-middle attacks
and unneces‐ sary traffic for the root-dns-servers.  Note that this
process may be slow and will generate a lot of network traffic if the
servers for the listed domains are not local, and that queries will time
out if no server is available for one of the domains.

==

so set ndots to 2, and try again.

-dsr-

[toc] | [prev] | [next] | [standalone]

#248843

On Tue, 7 Jun 2022, Dan Ritter wrote:

> Dieter Rohlfing wrote:
>> Hello everybody,
>>
>> When a client queries for a domain and the answer is NXDOMAIN, there is
>> immediately a second query with the original domain name, but suffixed
>> with the domain name of my home network.
>>
>> Example:
>>
>> 1. query: www.example.com (result NXDOMAIN)
>> 2. query: www.example.com.home.lan (result NXDOMAIN)
>>
>> home.lan is the domain name of my home network, /etc/resolv.conf
>> contains the following line:
>>
>>> search home.lan
>>
>> When I delete this line from /etc/resolv.conf, then the second query
>> doesn't appear, but I loose the ability to use unqualified hostnames to
>> refer to local clients. :-((
>>
>> Up to now I thought, the domain names in the search option is appended
>> only to unqualified names and not to qualified names. This assumption
>> seems to be false.
>>
>> My question: is it possible to apply the search list only to
>> unqualified names?
>
>
> search		Search list for host-name lookup.  By default, the search
> list contains one entry, the local domain name.  It is determined from
> the local hostname returned by gethostname(2); the local domain name is
> taken to be everything after the first '.'. Finally, if the hostname
> does not contain a '.', the root domain is assumed as the local domain
> name
>
> 	This may be changed by listing the desired domain search
> path following the search keyword with spaces or tabs separating the
> names.  Resolver queries having fewer than ndots dots (default is
> 1) in them will be attempted using each component of the search path in
> turn until a match is found.  For environments with multiple subdomains
> please read options ndots:n below to avoid man-in-the-middle attacks
> and unneces? sary traffic for the root-dns-servers.  Note that this
> process may be slow and will generate a lot of network traffic if the
> servers for the listed domains are not local, and that queries will time
> out if no server is available for one of the domains.
>
> ==
>
> so set ndots to 2, and try again.
>

I don't know what is going on here but that doesn't feel right unless
the OP has an options ndots:3 type setting already.

I'd suggest trying options ndots:1 - although that should be the default
anyway.

[toc] | [prev] | [next] | [standalone]

#248846

On Tue, Jun 07, 2022 at 11:22:34AM -0400, Dan Ritter wrote:
> 
> search		Search list for host-name lookup.  By default, the search
>  [...]
> 	This may be changed by listing the desired domain search
> path following the search keyword with spaces or tabs separating the
> names.  Resolver queries having fewer than ndots dots (default is
> 1) in them will be attempted using each component of the search path in
> turn until a match is found.

I've read this paragraph a few times, and as far as I can tell, it's
simply wrong.

If you go down farther in the page and look at:

              ndots:n
                     Sets a threshold for the number of dots which must appear
                     in a name given to res_query(3) (see resolver(3))  before
                     an  initial absolute query will be made.  The default for
                     n is 1, meaning that if there are any dots in a name, the
                     name  will  be tried first as an absolute name before any
                     search list elements are appended to it.  The  value  for
                     this option is silently capped to 15.

This one says that it simply determines whether the name will be tried
as is *before* appending the search domain(s) to it, or whether it just
skips straight to appending the search domains.

My experience, and the OP's experience, suggests that the description in
the ndots paragraph is correct, and the description in the search paragraph
is not.

To the best of my knowledge, there isn't any setting to *prevent* the
appending of search domains to a name, no matter how many dots you put
in the name.

[toc] | [prev] | [next] | [standalone]

#248847

[Multipart message — attachments visible in raw view] — view raw

On 07/06/2022 17:53, Greg Wooledge wrote:
> On Tue, Jun 07, 2022 at 11:22:34AM -0400, Dan Ritter wrote:
>> search		Search list for host-name lookup.  By default, the search
>>   [...]
>> 	This may be changed by listing the desired domain search
>> path following the search keyword with spaces or tabs separating the
>> names.  Resolver queries having fewer than ndots dots (default is
>> 1) in them will be attempted using each component of the search path in
>> turn until a match is found.
> I've read this paragraph a few times, and as far as I can tell, it's
> simply wrong.
>
> If you go down farther in the page and look at:
>
>                ndots:n
>                       Sets a threshold for the number of dots which must appear
>                       in a name given to res_query(3) (see resolver(3))  before
>                       an  initial absolute query will be made.  The default for
>                       n is 1, meaning that if there are any dots in a name, the
>                       name  will  be tried first as an absolute name before any
>                       search list elements are appended to it.  The  value  for
>                       this option is silently capped to 15.
>
> This one says that it simply determines whether the name will be tried
> as is *before* appending the search domain(s) to it, or whether it just
> skips straight to appending the search domains.
>
> My experience, and the OP's experience, suggests that the description in
> the ndots paragraph is correct, and the description in the search paragraph
> is not.
>
> To the best of my knowledge, there isn't any setting to *prevent* the
> appending of search domains to a name, no matter how many dots you put
> in the name.
I've wondered about that in the past. Is this maybe a bug in the 
application, then (I admit that it'll be a widespread bug if so). To my 
knowledge, DNS domains support "relative" names (e.g. "www.example.com") 
as well as "absolute" names (e.g. "www.example.com." - with the trailing 
dot). Should applications be querying for hostnames with the trailing 
dot and, if so, would that prevent the resolver from trying to append 
the search domains?

[toc] | [prev] | [next] | [standalone]

#248858

On 6/7/22, Darac Marjal <mailinglist@darac.org.uk> wrote:
>
> On 07/06/2022 17:53, Greg Wooledge wrote:
>>
>> To the best of my knowledge, there isn't any setting to *prevent* the
>> appending of search domains to a name, no matter how many dots you put
>> in the name.
>
> I've wondered about that in the past. Is this maybe a bug in the
> application, then (I admit that it'll be a widespread bug if so).

I'd go for a bug in the documentation.
Names ending with a dot don't get the search list appended to the name
on a lookup failure.

Think about it.. the trailing dot is the root of the DNS tree.  I
wouldn't make sense to add anything after that.

> To my
> knowledge, DNS domains support "relative" names (e.g. "www.example.com")
> as well as "absolute" names (e.g. "www.example.com." - with the trailing
> dot). Should applications be querying for hostnames with the trailing
> dot and, if so, would that prevent the resolver from trying to append
> the search domains?

You can always put the trailing dot in there yourself - eg
  ping foo.home.
if you don't want the search list appended on a lookup failure.

Lee

[toc] | [prev] | [next] | [standalone]

#248859

On Tue, 7 Jun 2022, Greg Wooledge wrote:

> On Tue, Jun 07, 2022 at 11:22:34AM -0400, Dan Ritter wrote:
>>
>> search		Search list for host-name lookup.  By default, the search
>>  [...]
>> 	This may be changed by listing the desired domain search
>> path following the search keyword with spaces or tabs separating the
>> names.  Resolver queries having fewer than ndots dots (default is
>> 1) in them will be attempted using each component of the search path in
>> turn until a match is found.
>
> I've read this paragraph a few times, and as far as I can tell, it's
> simply wrong.
>
Seems right to me:

$ cat /etc/resolv.conf
search home.woodall.me.uk
options ndots:3
nameserver 2001:8b0:bfcd:100:216:3eff:fee0:7102
nameserver 2001:8b0:bfcd:8100:216:3eff:fee1:7102

$ host ipv4.wlan.dirac
ipv4.wlan.dirac.home.woodall.me.uk has address 192.168.3.16
ipv4.wlan.dirac.home.woodall.me.uk has address 192.168.4.16

Change that 3 to a 2 and:

$ host ipv4.wlan.dirac
Host ipv4.wlan.dirac not found: 3(NXDOMAIN)


> If you go down farther in the page and look at:
>
>              ndots:n
>                     Sets a threshold for the number of dots which must appear
>                     in a name given to res_query(3) (see resolver(3))  before
>                     an  initial absolute query will be made.  The default for
>                     n is 1, meaning that if there are any dots in a name, the
>                     name  will  be tried first as an absolute name before any
>                     search list elements are appended to it.  The  value  for
>                     this option is silently capped to 15.
>
> This one says that it simply determines whether the name will be tried
> as is *before* appending the search domain(s) to it, or whether it just
> skips straight to appending the search domains.
>

Doesn't that say that, in my second example it will try ipv4.wlan.dirac.,
get NXDOMAIN, and pass that up the stack.

> My experience, and the OP's experience, suggests that the description in
> the ndots paragraph is correct, and the description in the search paragraph
> is not.
>
> To the best of my knowledge, there isn't any setting to *prevent* the
> appending of search domains to a name, no matter how many dots you put
> in the name.
>
>

[toc] | [prev] | [next] | [standalone]

#248862

On 6/7/22, Tim Woodall <debianuser@woodall.me.uk> wrote:
> On Tue, 7 Jun 2022, Greg Wooledge wrote:
>
>> On Tue, Jun 07, 2022 at 11:22:34AM -0400, Dan Ritter wrote:
>>>
>>> search		Search list for host-name lookup.  By default, the search
>>>  [...]
>>> 	This may be changed by listing the desired domain search
>>> path following the search keyword with spaces or tabs separating the
>>> names.  Resolver queries having fewer than ndots dots (default is
>>> 1) in them will be attempted using each component of the search path in
>>> turn until a match is found.
>>
>> I've read this paragraph a few times, and as far as I can tell, it's
>> simply wrong.
>>
> Seems right to me:
>
> $ cat /etc/resolv.conf
> search home.woodall.me.uk
> options ndots:3
> nameserver 2001:8b0:bfcd:100:216:3eff:fee0:7102
> nameserver 2001:8b0:bfcd:8100:216:3eff:fee1:7102
>
> $ host ipv4.wlan.dirac
> ipv4.wlan.dirac.home.woodall.me.uk has address 192.168.3.16
> ipv4.wlan.dirac.home.woodall.me.uk has address 192.168.4.16
>
> Change that 3 to a 2 and:
>
> $ host ipv4.wlan.dirac
> Host ipv4.wlan.dirac not found: 3(NXDOMAIN)
>
>
>> If you go down farther in the page and look at:
>>
>>              ndots:n
>>                     Sets a threshold for the number of dots which must
>> appear
>>                     in a name given to res_query(3) (see resolver(3))
>> before
>>                     an  initial absolute query will be made.  The default
>> for
>>                     n is 1, meaning that if there are any dots in a name,
>> the
>>                     name  will  be tried first as an absolute name before
>> any
>>                     search list elements are appended to it.  The  value
>> for
>>                     this option is silently capped to 15.
>>
>> This one says that it simply determines whether the name will be tried
>> as is *before* appending the search domain(s) to it, or whether it just
>> skips straight to appending the search domains.
>>
>
> Doesn't that say that, in my second example it will try ipv4.wlan.dirac.,
> get NXDOMAIN, and pass that up the stack.

host and dig are non-standard.  or use non-standard name lookups? library??
In any case, try your example with ping or ssh - the search list will
be applied after the initial NXDOMAIN

Lee

[toc] | [prev] | [next] | [standalone]

#248863

On Wed, Jun 08, 2022 at 12:56:52AM +0000, Lee wrote:
> host and dig are non-standard.  or use non-standard name lookups? library??
> In any case, try your example with ping or ssh - the search list will
> be applied after the initial NXDOMAIN

On Debian, the canonical tool for performing generic hostname lookups
according to the rules established by /etc/nsswitch.conf and other
local system config files would be:

getent hosts NAME

unicorn:~$ getent hosts www.google.com.
2607:f8b0:4009:80b::2004 www.google.com
unicorn:~$ host www.google.com
www.google.com has address 142.250.190.100
www.google.com has IPv6 address 2607:f8b0:4009:80b::2004

(Demonstrating the difference between canonical and useful.  My system
has no IPv6 capability.)

[toc] | [prev] | [next] | [standalone]

#248869

On 6/8/22, Greg Wooledge <greg@wooledge.org> wrote:
> On Wed, Jun 08, 2022 at 12:56:52AM +0000, Lee wrote:
>> host and dig are non-standard.  or use non-standard name lookups?
>> library??
>> In any case, try your example with ping or ssh - the search list will
>> be applied after the initial NXDOMAIN
>
> On Debian, the canonical tool for performing generic hostname lookups
> according to the rules established by /etc/nsswitch.conf and other
> local system config files would be:
>
> getent hosts NAME
>
> unicorn:~$ getent hosts www.google.com.
> 2607:f8b0:4009:80b::2004 www.google.com
> unicorn:~$ host www.google.com
> www.google.com has address 142.250.190.100
> www.google.com has IPv6 address 2607:f8b0:4009:80b::2004
>
> (Demonstrating the difference between canonical and useful.  My system
> has no IPv6 capability.)

I'm in the same boat :(  Verizon _still_ hasn't rolled out IPv6 in my area.

I like having DNSSEC enabled, so I'm running bind locally; here's the
bits from the bind log (with an 'rndc flush' between queries to clear
out any cached info)

$ getent hosts www.google.com
query: www.google.com IN AAAA + (127.0.0.1)

$ ping www.google.com
query: www.google.com IN A + (127.0.0.1)
query: www.google.com IN AAAA + (127.0.0.1)

$ host www.google.com
query: www.google.com IN A + (127.0.0.1)
query: www.google.com IN AAAA + (127.0.0.1)
query: www.google.com IN MX + (127.0.0.1)

Why getent doesn't look for an IPv4 address I don't know.  Same for
host .. no idea why it goes looking for an MX record.  Ping, ssh,
telnet all look for an IPv4 and an IPv6 address.   hrmm... Firefox
only looks for an ipv4 address ... ah! right - because I've got
network.dns.disableIPv6 set to true

I was under the impression there was a standard method for doing the
name -> address lookup but it seems that host, dig and even getent do
something non-standard - maybe to give you more control for debugging
purposes?

Lee

[toc] | [prev] | [next] | [standalone]

#249069

Thanks to everybody, who replied.

After some more reading and tinkering I've made the following
observations:

The response code NXDOMAIN means: domain name did not resolve. In
this case the search option becomes important. Whenever a domain name
does not resolve, the client's resolver (at least in Linux) suffixes the
original domain name with each item in the search list until the new
domain name resolves.

So this is regular behaviour and it explains the needless DNS queries.

AdguardHome uses the response code NXDOMAIN to signal the client "this
is a forbidden domain". For this signal "this is a forbidden domain"
you can configure AdguardHome to use the IPv4 0.0.0.0 and the response
code NOERROR. Now the (forbidden) domain is resolved without an error
and the IPv4 of 0.0.0.0. So there's no need to use the search list and
the needless DNS queries vanish.

Thanks for reading and have a nice day.

Dieter

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web