Discussion:
bind question
(too old to reply)
root
2018-06-18 19:48:01 UTC
Permalink
Am I correct in assuming that bind uses one of the nameservers
in /var/named/root.cache
to resolve any domain name that it doesn't know already?

If so, then the ping response times of those servers should
be of interest. I find the ping times of the best of
those servers is a little higher than those from the public
servers 1.1.1.1, 8.8.8.8, or 9.9.9.9. The worst of the
servers in root.cache has a ping time 10 times larger
than the public servers.

Is there some reason I shouldn't change /var/named/root.cache
to only point to the public servers?

Thanks.
Grant Taylor
2018-06-18 21:03:07 UTC
Permalink
Am I correct in assuming that bind uses one of the nameservers in
/var/named/root.cache to resolve any domain name that it doesn't know
already?
Not quit.

BIND (named) uses the contents of the root.cache file (presumably the
configured root-hint zone) to prime itself. BIND also has (a version
of) the same information compiled into itself.

BIND functioning as a recursive resolver will query root servers for the
nameserver of the next label, and then query that server for the next
label, repeating the process until it has the desired answer.

The contents of the root.cache file (root-hints zone) is not used for
more than initialization / priming as BIND starts up.

You can completely avoid this step by having a local slave of the root
DNS zone (file). }:-)
If so, then the ping response times of those servers should be of
interest. I find the ping times of the best of those servers is a
little higher than those from the public servers 1.1.1.1, 8.8.8.8,
or 9.9.9.9. The worst of the servers in root.cache has a ping time 10
times larger than the public servers.
Is there some reason I shouldn't change /var/named/root.cache to only
point to the public servers?
The root.cache (root-hints zone) is meant to be information about the
root name servers. It is not how you configure BIND to forward all
queries to specific servers.

Aside: Root name servers dot NOT answer recursive queries. Hence why
you can't use them in your clients.

There are other ways to have BIND forward queries to other servers, if
that's what you're wanting to do.
Thanks.
You're welcome.
--
Grant. . . .
unix || die
root
2018-06-19 00:52:17 UTC
Permalink
Post by Grant Taylor
Aside: Root name servers dot NOT answer recursive queries. Hence why
you can't use them in your clients.
There are other ways to have BIND forward queries to other servers, if
that's what you're wanting to do.
Thanks for responding. Yes, I wanted to direct BIND to faster servers.

It seems that updating the hint file (/var/named/root.cache) gives
a (human) noticeable speed improvement. I am going next to
change my resolv.conf to see how that works.
Henrik Carlqvist
2018-06-19 06:26:42 UTC
Permalink
It seems that updating the hint file (/var/named/root.cache) gives a
(human) noticeable speed improvement. I am going next to change my
resolv.conf to see how that works.
Usually editing of /etc/resolv.conf is all you need to do to be able to
do DNS queries. The primary use of bind is to act as a DNS server letting
others on the internet know about which computers you have and what
(public) IP-addresses they have in your domain.

If you for some reason need to have a private DNS server telling your
local network about your own machines as well as forwarding and possibly
caching DNS queris to internet you want some kind of DNS proxy. Bind can
be configured as a DNS proxy, but IMHO it is overkill for that task. I
prefer a more simple program for that task and have during many years
used pdnsd: http://members.home.nl/p.a.rombouts/pdnsd/

Pdnsd has a simple configuration file pointing out some upstream servers
to ask for internet DNS queries which it caches and that configuration
file can also point to your /etc/hosts (or another local file in the same
format) to serve information about machines in your local network.

It was a few years since the last version of pdnsd was released, there
are also other softwares like dnsmasq, but I have not tried any of those
myself.

Another way to tell your local network about your hosts is to configure a
NIS server, that one can also be used to share other maps like the
password file or automount maps of NFS disks. To use a NIS server you
might have to edit /etc/nsswitch.conf and most of all read some NIS
documentation. Configuring a NIS environment is probably more work than
configuring bind as a caching DNS server but it will give you more than
just the DNS host/ip loockups.

regards Henrik
root
2018-06-19 12:39:24 UTC
Permalink
Post by Henrik Carlqvist
It seems that updating the hint file (/var/named/root.cache) gives a
(human) noticeable speed improvement. I am going next to change my
resolv.conf to see how that works.
Usually editing of /etc/resolv.conf is all you need to do to be able to
do DNS queries. The primary use of bind is to act as a DNS server letting
others on the internet know about which computers you have and what
(public) IP-addresses they have in your domain.
If you for some reason need to have a private DNS server telling your
local network about your own machines as well as forwarding and possibly
caching DNS queris to internet you want some kind of DNS proxy. Bind can
be configured as a DNS proxy, but IMHO it is overkill for that task. I
prefer a more simple program for that task and have during many years
used pdnsd: http://members.home.nl/p.a.rombouts/pdnsd/
Pdnsd has a simple configuration file pointing out some upstream servers
to ask for internet DNS queries which it caches and that configuration
file can also point to your /etc/hosts (or another local file in the same
format) to serve information about machines in your local network.
It was a few years since the last version of pdnsd was released, there
are also other softwares like dnsmasq, but I have not tried any of those
myself.
Another way to tell your local network about your hosts is to configure a
NIS server, that one can also be used to share other maps like the
password file or automount maps of NFS disks. To use a NIS server you
might have to edit /etc/nsswitch.conf and most of all read some NIS
documentation. Configuring a NIS environment is probably more work than
configuring bind as a caching DNS server but it will give you more than
just the DNS host/ip loockups.
regards Henrik
Thanks for responding Henrik. I'm only interested in speed of response.
I will be running without bind for a while to see if I feel any
faster response. I am aware that many factors contribute to delay
and that DNS lookup may be only a tiny contributor. Each day I
send out robots to scrape data and once a week that scraping
is greatly increased. Daily the scraping takes about 1.5 hours,
but weekly it takes over five hours. I suppose that since my
operations involve repeated accesses to a handful of sites that
bind might be faster than a public DNS which would perform a
lookup for each access.
Robert Komar
2018-06-22 00:25:21 UTC
Permalink
When I used to use dial-up for internet, I used bind for caching
to speed up lookups. I used the default scripts for named, but
I added the following lines to /etc/named.conf:

forward first;
forwarders {
64.59.144.92;
64.59.150.138;
};

at the end of the "options" block. The IP addresses are for my
ISP's name servers, and you would replace them with the addresses
of your ISP's servers. After editing named.conf, you need to
restart the daemon using "/etc/rc.d/rc.bind restart".

To use the caching server, you have to put its address first in
in the list of servers in /etc/resolv.conf:

nameserver 127.0.0.1
nameserver 64.59.144.92
nameserver 64.59.150.138

(127.0.0.1 is for the caching bind server running on your
machine).

I would avoid trying to use servers higher up the chain
than your ISP's name servers because it will probably be
slower. I would especially not query root servers.

Cheers,
Rob Komar
Doug713705
2018-06-24 16:57:26 UTC
Permalink
Le 22-06-2018, Robert Komar nous expliquait dans
Post by Robert Komar
nameserver 127.0.0.1
nameserver 64.59.144.92
nameserver 64.59.150.138
(127.0.0.1 is for the caching bind server running on your
machine).
Having multiple "nameserver" entries in /etc/resolv.conf is not a good
idea.

In short:
If for some reason the first entry server answers "domain not found" to
a query, the second one will *not* be queried for verification.

The second one will be queried *only* if the first entry does not respond
(ie. server is unavailable) which may takes some precious time for a network
operation (IIRC bind default timeout is 5 seconds !).

In many ways such a configuration may cause some random huge network latencies
and/or unexpected network error (domain not found error while domain
exists).

If you want several DNS server, you have to configure bind as a resolver which
will query some eventually load balanced/failover-ed master servers.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Sylvain Robitaille
2018-06-26 18:14:07 UTC
Permalink
Post by Doug713705
Having multiple "nameserver" entries in /etc/resolv.conf is not a good
idea.
Huh??? That's nonsense ...

RESOLV.CONF(5) Linux Programmer's Manual RESOLV.CONF(5)

NAME
resolv.conf - resolver configuration file

SYNOPSIS
/etc/resolv.conf
...
nameserver Name server IP address
Internet address of a name server that the resolver
should query, ... Up to MAXNS (currently 3,
see <resolv.h>) name servers may be listed, one
per keyword. If there are multiple servers, the
resolver library queries them in the order listed.
If no name- server entries are present, the default
is to use the name server on the local machine. ...
Post by Doug713705
In many ways such a configuration may cause some random huge network
latencies and/or unexpected network error (domain not found error
while domain exists).
configure your "nameserver" entries to resolvers that are properly
configured to perform recursive queries, and that have stable network
connections.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Doug713705
2018-06-24 17:04:36 UTC
Permalink
Le 22-06-2018, Robert Komar nous expliquait dans
Post by Robert Komar
nameserver 127.0.0.1
nameserver 64.59.144.92
nameserver 64.59.150.138
(127.0.0.1 is for the caching bind server running on your
machine).
Having multiple "nameserver" entries in /etc/resolv.conf is not a good
idea.

In short:
If for some reason the first entry server answers "domain not found" to
a query, the second one will *not* be queried for verification.

The second one will be queried *only* if the first entry does not respond
(ie. server is unavailable) which may takes some precious time for a network
operation.

After re-reading the resolv.conf man page, the default DNS client timeout is 5
seconds (same as Bind default timeout).
You may lower the timeout value but the problem will persist.

In many ways such a configuration may cause some random huge network latencies
and/or unexpected network error (domain not found error while domain
exists).

If you want several DNS server, you have to configure bind as a resolver which
will query some eventually load balanced/failover-ed master servers.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Grant Taylor
2018-06-24 18:34:33 UTC
Permalink
Post by Doug713705
Having multiple "nameserver" entries in /etc/resolv.conf is not a
good idea.
What‽
Post by Doug713705
If for some reason the first entry server answers "domain not found"
to a query, the second one will *not* be queried for verification.
That is to be expected. The NXDOMAIN (domain not found) is an
authoritative response, not an error. That is working as intended, by
design, and as configured.
Post by Doug713705
The second one will be queried *only* if the first entry does not respond
(ie. server is unavailable) which may takes some precious time for a
network operation.
Again, working as intended, by design, and as configured.

Secondary & tertiary nameserver entries are a safety net for when the
primary nameserver entry is non-functional (or slow enough that it's
considered non-functional).
Post by Doug713705
After re-reading the resolv.conf man page, the default DNS client timeout
is 5 seconds (same as Bind default timeout). You may lower the timeout
value but the problem will persist.
What is "the problem" that is persisting? Are you referring to the fact
that subsequent nameservers aren't queried when a previous nameserver
responded NXDOMAIN as "the problem"?
Post by Doug713705
In many ways such a configuration may cause some random huge network
latencies and/or unexpected network error (domain not found error while
domain exists).
If your primary DNS server is returning NXDOMAIN when the domain does
exist, there is a problem with the DNS infrastructure or the way that
it's configured. Typically internal only systems don't forward
properly, something is installed and configured to filter, or external
DNS servers don't know about internal domain(s).

There should be exceptionally little between primary / secondary /
tertiary DNS servers. The only exception being that subsequent DNS
servers might not know about internal domains that previous nameservers
do know about. (I.e. if primary is internal and secondary & tertiary
are external.)
Post by Doug713705
If you want several DNS server, you have to configure bind as a resolver
which will query some eventually load balanced/failover-ed master servers.
No you do not. That is wrong. Quoting from resolv.conf's man page:

"""
Up to ... 3 ... name servers may be listed, one per keyword. If there
are multiple servers, the resolver library queries them in the order
listed. (The algorithm used is to try a name server, and if the query
times out, try the next, until out of name servers, then repeat trying
all the name servers until a maximum number of retries are made.)
"""

"Up to 3 name servers may be listed, one per keyword (line)." — That
specifically states that multiple nameserver entries are supported.

"If there are multiple servers, the resolver library queries them in the
order listed." — That clearly states that querying multiple are
supported and that they are queried in the order they are listed.

"The algorithm used is to try a name server, and if the query times out,
try the next, until out of name servers, then repeat trying all the name
servers until a maximum number of retries are made." — That clearly
states that all servers listed are tried in order and "*then* *repeat*
*trying* all the name servers *until* *a* *maximum* *number* of retriese
are made."

You do NOT have to configure BIND (or any other local name server (like)
daemon) to utilize multiple name servers.

Even that is not going to behave the way that you describe. BIND will
accept an NXDOMAIN from the first server that replies to it's query and
not (re)query subsequent servers in case they have a different answer.
(I am explicitly ignoring things that filter replies like RPZ and RPS.)

There are some knobs that you can tune with BIND to try to influence how
it queries the world. But it's still going to honor an NXDOMAIN.

The "nameserver" statement is specifically meant for querying multiple
nameservers in a fail-over (but not load balanced) manner.

Neither BIND nor the stub-resolver will do load balancing. It will have
a strict affinity to specific servers. BIND will prefer the fastest
responding server. The stub-resolver will prefer the first nameserver
entry, followed by the second and third entries. That is not load
balancing. That is fail-over redundancy.

The only slight change to that is if the preferred server is slow to
respond for some reason, BIND will switch it's preferred server to the
next fastest server if it was faster than the last query to the old
preferred server.
--
Grant. . . .
unix || die
Doug713705
2018-06-25 08:52:02 UTC
Permalink
Le 24-06-2018, Grant Taylor nous expliquait dans
Post by Grant Taylor
Post by Doug713705
Having multiple "nameserver" entries in /etc/resolv.conf is not a
good idea.
What‽
Post by Doug713705
If for some reason the first entry server answers "domain not found"
to a query, the second one will *not* be queried for verification.
That is to be expected.
Ok for that. Many people do not understand/know that point.
Post by Grant Taylor
The NXDOMAIN (domain not found) is an
authoritative response, not an error. That is working as intended, by
design, and as configured.
Yes.
Post by Grant Taylor
Post by Doug713705
The second one will be queried *only* if the first entry does not respond
(ie. server is unavailable) which may takes some precious time for a
network operation.
Again, working as intended, by design, and as configured.
This is your choice and you're right if you exactly know and expect some
behaviors such as extreme latency.
Post by Grant Taylor
Secondary & tertiary nameserver entries are a safety net for when the
primary nameserver entry is non-functional (or slow enough that it's
considered non-functional).
Yes, I know and perfectly understand that point.
Post by Grant Taylor
Post by Doug713705
After re-reading the resolv.conf man page, the default DNS client timeout
is 5 seconds (same as Bind default timeout). You may lower the timeout
value but the problem will persist.
What is "the problem" that is persisting? Are you referring to the fact
that subsequent nameservers aren't queried when a previous nameserver
responded NXDOMAIN as "the problem"?
The problem is the timeout delay.

If the first server timeouts (which may take 5 seconds) your DNS request
will take 5 seconds + the time needed to get the answer from the second
server for *each* DNS request. You can double these 5 seconds if the 2nd
server is also down.

This will surely and extremly slow down your connexion.
Post by Grant Taylor
Post by Doug713705
In many ways such a configuration may cause some random huge network
latencies and/or unexpected network error (domain not found error while
domain exists).
If your primary DNS server is returning NXDOMAIN when the domain does
exist, there is a problem with the DNS infrastructure or the way that
it's configured.
I agree with that. But what if your first server has lost it's external
connexion external and does not have the domain data in cache ?

It will send you back NXDOMAIN yet you don't have any misconfiguration.

But this is not the main point of what I'm trying to explain.
Post by Grant Taylor
Typically internal only systems don't forward
properly, something is installed and configured to filter, or external
DNS servers don't know about internal domain(s).
There should be exceptionally little between primary / secondary /
tertiary DNS servers. The only exception being that subsequent DNS
servers might not know about internal domains that previous nameservers
do know about. (I.e. if primary is internal and secondary & tertiary
are external.)
Yes, but we're talking about the opposite situation:
The first does _not_ know about a domain that the second server knows
about.
Post by Grant Taylor
Post by Doug713705
If you want several DNS server, you have to configure bind as a resolver
which will query some eventually load balanced/failover-ed master servers.
"""
Up to ... 3 ... name servers may be listed, one per keyword. If there
are multiple servers, the resolver library queries them in the order
listed. (The algorithm used is to try a name server, and if the query
times out, try the next, until out of name servers, then repeat trying
all the name servers until a maximum number of retries are made.)
"""
I didn't say that it was not possible to have several nameserver entries
in resolv.conf but I said thad this is usually a bad idea if you're
not aware of the exact behavior of such configuration.
Post by Grant Taylor
"Up to 3 name servers may be listed, one per keyword (line)." — That
specifically states that multiple nameserver entries are supported.
Yes...
Post by Grant Taylor
"If there are multiple servers, the resolver library queries them in the
order listed." — That clearly states that querying multiple are
supported and that they are queried in the order they are listed.
Yes...
Post by Grant Taylor
"The algorithm used is to try a name server, and if the query times out,
try the next, until out of name servers
*This* is my point. I just wanted to warn people about *this* very behavior
that is usually misunderstood or not known.
Post by Grant Taylor
then repeat trying all the name
servers until a maximum number of retries are made." — That clearly
states that all servers listed are tried in order and "*then* *repeat*
*trying* all the name servers *until* *a* *maximum* *number* of retriese
are made."
Yes and this may take a looooong time to timeout. Say the 3 servers are
down, you will know about it after, at least, 15 seconds.

Say the first server is down, you *will* have, at least, 5 seconds
network latency for *each* DNS request.

Say the web page you want to read contains 3 images, you will see the
page at least 20 seconds after the first DNS request:
- 5 seconds for the page request
- 5 seconds for each image

Why ? Because the DNS data are in cache of the _second_ nameserver, so
you *will* have to wait for the timeout delay of the first nameserver
for *each* DNS request, even for the very same domain name.

Now imagine the time needed to load a page that contain many JS scripts
from various providers, many data from various CDN, etc...

The page will show after several minutes (in fact you'll probably close
your browser before the first data is displayed).

This latency can be a real problem for some network based application that
needs to send many requests.
Post by Grant Taylor
You do NOT have to configure BIND (or any other local name server (like)
daemon) to utilize multiple name servers.
It depends on what you want to achieve but yes it's not absolutely
needed.
Post by Grant Taylor
Even that is not going to behave the way that you describe. BIND will
accept an NXDOMAIN from the first server that replies to it's query and
not (re)query subsequent servers in case they have a different answer.
(I am explicitly ignoring things that filter replies like RPZ and RPS.)
There are some knobs that you can tune with BIND to try to influence how
it queries the world. But it's still going to honor an NXDOMAIN.
The "nameserver" statement is specifically meant for querying multiple
nameservers in a fail-over (but not load balanced) manner.
Yes but at the cost of huge latency.
That's my point and it's perfect if you already know about it.
Most people do not.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Grant Taylor
2018-06-25 21:57:01 UTC
Permalink
Post by Doug713705
Ok for that. Many people do not understand/know that point.
O.o

Okay.
Post by Doug713705
This is your choice and you're right if you exactly know and expect some
behaviors such as extreme latency.
When you back up and think about the Internet when DNS was designed,
having even a 60 second timeout (I'm exaggerating) to get results was
good. Having a delayed answer is always better than no answer.

IMHO it's not until the last 10 ~ 15 years when people can get full page
and graphics downloaded faster than the DNS timeouts happen that this
""redundancy really became an issue.
Post by Doug713705
If the first server timeouts (which may take 5 seconds) your DNS request
will take 5 seconds + the time needed to get the answer from the second
server for *each* DNS request. You can double these 5 seconds if the
2nd server is also down.
I believe that different OSs implement the algorithm slightly
differently. I don't know for sure what Linux does as I've not needed
to look. I think Linux does (or did) wait 5 (?) seconds between servers
in sequential order.

I know that Windows does (or used to) send the first request to the
first server, and then 3 seconds later (re)send the second request to
the first and second server. Then 3 (?) seconds later (re)send the
request to all configured DNS servers.

I'm not sure if the "requests" that you're talking about are the
outbound queries to DNS servers, or calls to getname (?) that
applications issue to the OS name resolution system.

Either way, the primary name server being offline does slow things down.
But for most things it does not stop them from functioning. (Assuming
that all DNS servers have access to the same data.)
Post by Doug713705
This will surely and extremly slow down your connexion.
Slow down, sure. Stop it completely, not likely.
Post by Doug713705
I agree with that. But what if your first server has lost it's external
connexion external and does not have the domain data in cache ?
If the first server does not have zone data, does not have an answer in
cache, and can't successfully query the world, it should return SERVFAIL
to indicate that it failed to do it's job. This is significantly
different than a NXDOMAIN error message.
Post by Doug713705
It will send you back NXDOMAIN yet you don't have any misconfiguration.
I disagree.
Post by Doug713705
Yes, but we're talking about the opposite situation: The first does _not_
know about a domain that the second server knows about.
Hence why the first server returns the SERVFAIL so that clients /
downstream resolvers know that it failed to do what they asked and that
they should query other upstream servers.
Post by Doug713705
I didn't say that it was not possible to have several nameserver entries
in resolv.conf but I said thad this is usually a bad idea if you're not
aware of the exact behavior of such configuration.
I disagree. I think it behooves people to have multiple nameserver
entries in resolv.conf.

Do you also recommend that people only configure one DNS server on
Windows or other systems?

How do you handle the primary server being down if you don't configure
multiple nameservers?

My understanding of your recommended configuration would leave things in
a non-functional state.

I view an extended delay (5 ~ 60) seconds to be FAR better than no
functionality.
Post by Doug713705
*This* is my point. I just wanted to warn people about *this* very
behavior that is usually misunderstood or not known.
Every time I had clients ask me why things took longer than normal, I
would check and then tell them that the primary DNS server was not
responding and that their system automatically fell back tot he backup 5
seconds later.

They were always happy to have the backup.

One asked me what would happen if they didn't have the backup DNS
server. When I told them that they wouldn't be able to use names at
all, they were quite happy to have the backup and live with the rare
delay when the primary was offline.
Post by Doug713705
Yes and this may take a looooong time to timeout. Say the 3 servers are
down, you will know about it after, at least, 15 seconds.
I suspect that people will know that something is up (or down as the
case may be) long before 15 seconds.
Post by Doug713705
Say the first server is down, you *will* have, at least, 5 seconds
network latency for *each* DNS request.
Maybe, maybe not. Caching (both on client and servers) will influence
this. As will local zone data. Constructing negative answers from
DNSSEC's NSEC(3) records can also influence this.

Baring all the above, you will have the 5 / 10 second delay if you have
a secondary / tertiary nameserver configured.

However, you will have an infinite delay if you don't have a secondary /
tertiary nameserver configured.
Post by Doug713705
Say the web page you want to read contains 3 images, you will see the
- 5 seconds for the page request
- 5 seconds for each image
Not if all the image are located on the same host, i.e. www.example.com.
The page should load in about 6 ~ 7 seconds.

Both the client and the functional server will cache the result for
www.example.com.

Further, the client shouldn't even do a DNS lookup for subsequent uses
of the same name (within cache lifetime).
Post by Doug713705
Why ? Because the DNS data are in cache of the _second_ nameserver, so
you *will* have to wait for the timeout delay of the first nameserver
for *each* DNS request, even for the very same domain name.
Waiting 5 / 10 seconds for the secondary / tertiary DNS server is better
than not having to wait until the primary DNS server is back online.
Post by Doug713705
Now imagine the time needed to load a page that contain many JS scripts
from various providers, many data from various CDN, etc...
Sure, waiting will be unpleasant. But the page will load. The same
can't be said if you don't configure secondary or tertiary DNS servers.
Post by Doug713705
The page will show after several minutes (in fact you'll probably close
your browser before the first data is displayed).
Your page won't load at all if the primary nameserver is down and you
don't configure a secondary or tertiary DNS server.
Post by Doug713705
This latency can be a real problem for some network based application
that needs to send many requests.
I'm fairly sure that latency is better than total failure.
Post by Doug713705
It depends on what you want to achieve but yes it's not absolutely needed.
;-)
Post by Doug713705
Yes but at the cost of huge latency.
I would rather have latency than not be able to do anything at all.
Post by Doug713705
That's my point and it's perfect if you already know about it.
Most people do not.
More people know that the lack of name resolution for what ever reason
is worse than slow name resolution.

So I have to ask: In your ideal situation, how do you want to configure
client devices for when the primary nameserver is offline?

What would you like to see done differently that does not include a
secondary or any additional nameserver?
--
Grant. . . .
unix || die
Doug713705
2018-06-26 09:11:17 UTC
Permalink
Le 25-06-2018, Grant Taylor nous expliquait dans
Post by Grant Taylor
So I have to ask: In your ideal situation, how do you want to configure
client devices for when the primary nameserver is offline?
I started a looong answer to your post but I finally think that this
discussion has no place in this Slackware group. So I discarded it even
if this discussion could have been an interesting one.

There is always many solutions to one problem. Somme are bad ones,
other good ones but the best solution is not absolute and depends of
the goal to be achieved.

Hence this a short answer:
I think I would setup things like this:

- One nameserver entry on client side which will query a "single" resolver
- The resolver is a load-balanced (as you already explained it in previous
post) *and* redunded (Virtual IP on 2 or more resolvers set up with
keepalived or some equivalent, possibly with some of the resolvers on a
different network to prevent total network loss).

This way:
- The client needs only on IP address as a nameserver (the virtual IP
address of the array setup with keepalivedi)
- The redundancy is made *server side*, not client side

I really think this configuration is far better.

In fact I already experienced it and it IS far better.

This configuration offers better guarantee that the DNS resolution will
not fail until the client has a connexion to the resolver.

Note that setiing up bind with keepalived can be a bit tricky.
Post by Grant Taylor
What would you like to see done differently that does not include a
secondary or any additional nameserver?
See my answer upward :)
--
Retour aux joints et à la bière.
Désertion du rayon képis !
J'ai rien contre vos partenaires
Mais rien contre vos p'tites sœurs ennemies.
H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Grant Taylor
2018-06-26 16:56:49 UTC
Permalink
Post by Doug713705
- One nameserver entry on client side which will query a "single" resolver
- The resolver is a load-balanced (as you already explained it in previous
post) *and* redunded (Virtual IP on 2 or more resolvers set up with
keepalived or some equivalent, possibly with some of the resolvers on a
different network to prevent total network loss).
- The client needs only on IP address as a nameserver (the virtual IP
address of the array setup with keepalivedi)
- The redundancy is made *server side*, not client side
I agree that server redundancy is a very good thing.

But what happens if the server redundancy is within a data center (with
no inter data center redundancy) and the entire data center is inaccessible?

The client is back in the same situation of not being able to access any
nameserver.
Post by Doug713705
I really think this configuration is far better.
I still believe that it's better to have redundancy on the client side
in the form of multiple nameserver entries.

Redundancy on the server side so that the client doesn't need to use the
secondary nameserver is wonderful.

Plan for failures.
Post by Doug713705
In fact I already experienced it and it IS far better.
Yes, redundancy on the server side is very nice. But that's not always
sufficient.
Post by Doug713705
This configuration offers better guarantee that the DNS resolution will
not fail until the client has a connexion to the resolver.
It also guarantees that the client does not have any DNS service if the
entire data center containing the redundancy is inaccessible.
Post by Doug713705
Note that setiing up bind with keepalived can be a bit tricky.
I've often found that paying it forward to be worth it and pay off in
the long run.
Post by Doug713705
See my answer upward :)
What sort of solution do you want when all the redundant DNS servers
making up the single service (V)IP are inaccessible.
--
Grant. . . .
unix || die
Doug713705
2018-06-27 11:18:13 UTC
Permalink
Le 26-06-2018, Grant Taylor nous expliquait dans
Post by Grant Taylor
Post by Doug713705
- One nameserver entry on client side which will query a "single" resolver
- The resolver is a load-balanced (as you already explained it in previous
post) *and* redunded (Virtual IP on 2 or more resolvers set up with
keepalived or some equivalent, possibly with some of the resolvers on a
different network to prevent total network loss).
- The client needs only on IP address as a nameserver (the virtual IP
address of the array setup with keepalivedi)
- The redundancy is made *server side*, not client side
I agree that server redundancy is a very good thing.
But what happens if the server redundancy is within a data center (with
no inter data center redundancy) and the entire data center is inaccessible?
What if the sun explodes ? :)
I mean, there is no perfect solution, there is always an weakness in the
system even with unlimited money.

And that is my point. One can choose the weakness he wants if he knows
all the possibilities and risks for each of them.

The best solution is probably something mixed but it's often just a
matter of compromise.
Post by Grant Taylor
The client is back in the same situation of not being able to access any
nameserver.
Are you telling that the DB or back/front end servers are in
a different datacenter than the DNS servers one ?

If not, the data center is out of reach, what is the need of the DNS ?
Even with the DNS data you will not be able to reach your servers !

Again, as we see it here, it depends on the situation.
What I'm proposing is not an universal solution.
Post by Grant Taylor
Post by Doug713705
I really think this configuration is far better.
I still believe that it's better to have redundancy on the client side
in the form of multiple nameserver entries.
It depends but you may be right in your case.
Post by Grant Taylor
Redundancy on the server side so that the client doesn't need to use the
secondary nameserver is wonderful.
Plan for failures.
Post by Doug713705
In fact I already experienced it and it IS far better.
Yes, redundancy on the server side is very nice. But that's not always
sufficient.
You're right but there is no perfect solution at low cost.
Post by Grant Taylor
Post by Doug713705
This configuration offers better guarantee that the DNS resolution will
not fail until the client has a connexion to the resolver.
It also guarantees that the client does not have any DNS service if the
entire data center containing the redundancy is inaccessible.
If the datacenter is out of reach then you probably have a lot of
problems more important that a simple DNS redundancy problem :)
Post by Grant Taylor
Post by Doug713705
Note that setiing up bind with keepalived can be a bit tricky.
I've often found that paying it forward to be worth it and pay off in
the long run.
I agree with that :)
Post by Grant Taylor
Post by Doug713705
See my answer upward :)
What sort of solution do you want when all the redundant DNS servers
making up the single service (V)IP are inaccessible.
I'm someone that looking to priority.

How many times did you see a total loss of connexion to datacenter within
your life ?

How many times did you see a physical/virtual server down for whatever
reason within this year ?

I think that the DNS service is more likely to be down before the total
loss of the connexion to the datacenter which is probably already
redunded.

So I will, first, prevent this problem and only then I will look at the
second problem.
--
N'oubliez pas de me faire envoyer la liste
des erreurs constatées au F 756 du 72 03 10
-- H.F. Thiéfaine, L'ascenceur de 22H43
Grant Taylor
2018-06-29 18:56:56 UTC
Permalink
Post by Doug713705
What if the sun explodes ? :)
We will likely still have a few hours to a few days or maybe even weeks
before we have heat death.
Post by Doug713705
I mean, there is no perfect solution, there is always an weakness in
the system even with unlimited money.
No, there is no perfect solution. But there are solutions that are
trivial to implement that do provide an acceptable level of redundancy
with acceptable levels of limitations.
Post by Doug713705
And that is my point. One can choose the weakness he wants if he knows
all the possibilities and risks for each of them.
Or one can follow 30+ years of recommended best practice. Particularly
if one can't explain why they want to do something contrary.
Post by Doug713705
The best solution is probably something mixed but it's often just a
matter of compromise.
I am having a hard time seeing any solution better than having a
secondary or tertiary nameserver configured.
Post by Doug713705
Are you telling that the DB or back/front end servers are in a different
datacenter than the DNS servers one ?
They very well can be.

I just used a DC as an example.

I've routinely seen a switch die or something else that breaks a
communications path to the redundant equipment while still providing
service to other equipment.
Post by Doug713705
If not, the data center is out of reach, what is the need of the DNS ?
Even with the DNS data you will not be able to reach your servers !
If the "data center" is really a Co-Lo facility where you have a server
(say for hosting QuickBooks) and that's all you can't get to, you can
still brows the web get to Gmail, etc perfectly fine using a secondary
nameserver.
Post by Doug713705
Again, as we see it here, it depends on the situation. What I'm proposing
is not an universal solution.
My opinion is that your proposition of only entering a single name
server is bad and counters 30+ years of best practice.
Post by Doug713705
It depends but you may be right in your case.
I'm fairly confident that having multiple configured nameservers is the
proper solution. I'm equally confident that a LOT of other people agree
with me.
Post by Doug713705
You're right but there is no perfect solution at low cost.
Yet entering a secondary (and possibly tertiary) nameserver is free and
does provide a solution. Further, there are no down sides to it while
the primary nameserver is operational. Even further, the secondary (and
tertiary) nameserver will function in the event that the primary
nameserver is inaccessible for any reason (be it a DC level event, or a
switch or what have you).
Post by Doug713705
If the datacenter is out of reach then you probably have a lot of problems
more important that a simple DNS redundancy problem :)
Maybe, maybe not. It really depends what the DC is. If it's a Co-Lo
facility or cloud host that's impacted and your internet connection is
not, then a secondary nameserver will allow you to continue to do other
things.

The lack of the secondary (or tertiary) nameserver almost guarantees
that you won't be able to do anything.
Post by Doug713705
I'm someone that looking to priority.
What does that mean?
Post by Doug713705
How many times did you see a total loss of connexion to datacenter within
your life ?
In my life? 25 ~ 50.
Post by Doug713705
How many times did you see a physical/virtual server down for whatever
reason within this year ?
Do you mean a redundant / service / virtual IP or a server as in a
running OS instance?

Former: Many. The application stack simply ignored that service and
used another fall back / lower priority server in short order and
without noticeable end user impact.

Latter: Weekly do to some sort of hardware failure. Daily do to some
sort of maintenance event.
Post by Doug713705
I think that the DNS service is more likely to be down before the
total loss of the connexion to the datacenter which is probably already
redunded.
I just used a DC as an example of how the redundant service may be
perfectly functional within the DC, despite the fact that people can't
get to it.

Either way, it depends on communications between the client and the
redundant DNS servers. That's usually one (possibly redundant) path.

Conversely, a secondary DNS server can take a completely different (set
of possibly redundant) path(s). Thus the client can access the
secondary (or tertiary) DNS server with minimal issues.

Further, said minimal issues are a LOT better than not having DNS
service and not being able to access anything.
Post by Doug713705
So I will, first, prevent this problem and only then I will look at the
second problem.
You do you.

I expect that > 90% of the rest of the world, myself included, will
continue to use secondary (and possibly tertiary) DNS servers.
--
Grant. . . .
unix || die
Sylvain Robitaille
2018-06-26 18:31:33 UTC
Permalink
Post by Doug713705
The problem is the timeout delay.
If the first server timeouts (which may take 5 seconds) your DNS
request will take 5 seconds + the time needed to get the answer from
the second server for *each* DNS request. You can double these 5
seconds if the 2nd server is also down.
This will surely and extremly slow down your connexion.
So ... how's the connection "speed" when your single nameserver entry
becomes unreachable for any number of reasons? I think that most
people would agree that a slow response is better than no response ...
Post by Doug713705
Yes, but we're talking about the opposite situation: The first does
_not_ know about a domain that the second server knows about.
If the first name server doesn't know about a domain, it will perform
a recursive query to get an answer. That's how name resolution works.

Oh ... and if your first nameserver is unavailable for an extended
period of time, you can just change the order of the nameserver entries
(perhaps only temporarily) in order to get performance back to normal,
but at least in the meantime you weren't completely cut off ...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Doug713705
2018-06-27 11:29:22 UTC
Permalink
Le 26-06-2018, Sylvain Robitaille nous expliquait dans
Post by Sylvain Robitaille
Post by Doug713705
The problem is the timeout delay.
If the first server timeouts (which may take 5 seconds) your DNS
request will take 5 seconds + the time needed to get the answer from
the second server for *each* DNS request. You can double these 5
seconds if the 2nd server is also down.
This will surely and extremly slow down your connexion.
So ... how's the connection "speed" when your single nameserver entry
becomes unreachable for any number of reasons? I think that most
people would agree that a slow response is better than no response ...
Sometimes a slow connection is not better than no connexion at all.
It also could be worse (unpredictable behaviors implying data
loss/corruption).
Post by Sylvain Robitaille
Post by Doug713705
Yes, but we're talking about the opposite situation: The first does
_not_ know about a domain that the second server knows about.
If the first name server doesn't know about a domain, it will perform
a recursive query to get an answer. That's how name resolution works.
Yes, but the case is the first name server do not know because he can no
more join any authority servers and have no data in cache.
Post by Sylvain Robitaille
Oh ... and if your first nameserver is unavailable for an extended
period of time, you can just change the order of the nameserver entries
(perhaps only temporarily) in order to get performance back to normal,
but at least in the meantime you weren't completely cut off ...
It's a matter of choice but you have to be absolutely sure that all will
run fine in degraded conditions.

The needed tests to be absolutely sure of that are not so often made
and/or passed.

But it's just my opinion. I'm not telling to people "don't do this, do
that". I'm just telling "Be aware of that before doing this".
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Grant Taylor
2018-06-29 19:09:13 UTC
Permalink
Post by Doug713705
Sometimes a slow connection is not better than no connexion at all.
It also could be worse (unpredictable behaviors implying data
loss/corruption).
Given the slowness that you are talking about is really latency
introduced by the client waiting before trying the secondary connection,
I'll argue that the connection to the secondary server is not actually
slow. In fact, it could be faster and closer.

Consider someone choosing to use 8.8.8.8 as their primary DNS server and
their ISP's DNS as the secondary DNS server.

It is entirely possible that something is preventing connections to
8.8.8.8 yet the ISP's DNS is still accessible.

In such a case, I'm betting latency to the ISP's DNS server (if run
properly) is actually better than that to 8.8.8.8
Post by Doug713705
Yes, but the case is the first name server do not know because he can
no more join any authority servers and have no data in cache.
That is why the server would return a SERVERROR message to let the
client know that the server experienced an error. Clients know that
they can't trust the response and that they should query a different
nameserver.
Post by Doug713705
It's a matter of choice but you have to be absolutely sure that all will
run fine in degraded conditions.
The connection is not degraded. I feel like you are coercing the
latency / delay that the client imposes before trying the secondary
server to fit / support your argument. I reject such actions.
Post by Doug713705
The needed tests to be absolutely sure of that are not so often made
and/or passed.
Do you also run such tests on primary nameserver? Can you guarantee
that someone is not hijacking your primary nameserver (8.8.8.8) and
messing with the results.
Post by Doug713705
But it's just my opinion. I'm not telling to people "don't do this,
do that". I'm just telling "Be aware of that before doing this".
Your responses in this thread seem to be doing exactly that, telling
people that it's a bad idea to have multiple nameservers configured.

I'm telling the same people, "Yes, there is a delay." and asking them
"Would you rather have a (known) delay and still be able to brows the
web? Or would you prefer to have an infinite delay and not able to do
anything online?".

Let me ask you this? Are you practicing what you (seem to) preach? Do
you only have one nameserver configured?

If you do practice what you preach, and only have one nameserver
configured, do you walk away from your computer when that nameserver is
unavailable? Or do you manually change it to a different nameserver?
--
Grant. . . .
unix || die
Clark Smith
2018-06-19 13:12:56 UTC
Permalink
Post by Henrik Carlqvist
It seems that updating the hint file (/var/named/root.cache) gives a
(human) noticeable speed improvement. I am going next to change my
resolv.conf to see how that works.
Usually editing of /etc/resolv.conf is all you need to do to be able to
do DNS queries. The primary use of bind is to act as a DNS server
letting others on the internet know about which computers you have and
what (public) IP-addresses they have in your domain.
If you for some reason need to have a private DNS server telling your
local network about your own machines as well as forwarding and possibly
caching DNS queris to internet you want some kind of DNS proxy. Bind can
be configured as a DNS proxy, but IMHO it is overkill for that task. I
prefer a more simple program for that task and have during many years
used pdnsd: http://members.home.nl/p.a.rombouts/pdnsd/
Another alternative is dnsmasq.
Loading...