Hi, how can DNS reliability, as experienced by clients on the LAN who are sending queries, be increased? Would I have to set up some sort of cluster consisting of several servers all providing DNS services which is reachable under a single IP address known to the clients? Just setting up several name servers and making them known to the clients for the clients to automatically switch isn't a good solution because the clients take their timeouts and users lacking even the most basic knowledge inevitably panic when the first name server does not answer queries.
Am 2019-07-25 14:51, schrieb hw:> Hi, > > how can DNS reliability, as experienced by clients on the LAN who are > sending queries, be increased? > > Would I have to set up some sort of cluster consisting of several > servers all providing DNS services which is reachable under a single > IP address known to the clients? > > Just setting up several name servers and making them known to the > clients > for the clients to automatically switch isn't a good solution because > the clients take their timeouts and users lacking even the most basic > knowledge inevitably panic when the first name server does not answer > queries.Run a local cache (unbound) and enter all your local resolvers as upstreams.
If you don't want multiple DNS server entries on the client then a master and (possibly multiple) slave server configuration can be set up (I'm assuming ISC DNS - their solution to redundancy/failover is master and slave servers, this may be the way it is with all DNS). keepalived can be used for fail over and will present a single IP address (which the clients would use) shared among the servers. haproxy or alternatives might be another fail over option. Each technology has its own learning curve (and doing this will require at least two) and caveats. In particular systemd doesn't appear to play well with technologies creating IP addresses it doesn't manage. The version of keepalived we're using also has its own nasty quirk as well where it comes up assuming it is master until discovered otherwise, this is true even if it is configured as backup. In most cases this is probably either a non-issue (no scripts being used) or a minor annoyance. But if you're using scripts triggered by keepalived which make significant (and possibly conflicting) changes to the environment then you'll need to embed "intelligence" in them to wait until final state is reached or test state before acting or some other option. ________________________________ From: CentOS <centos-bounces at centos.org> on behalf of hw <hw at gc-24.de> Sent: Thursday, July 25, 2019 7:51:39 AM To: centos at centos.org <centos at centos.org> Subject: [EXTERNAL] [CentOS] how to increase DNS reliability? Hi, how can DNS reliability, as experienced by clients on the LAN who are sending queries, be increased? Would I have to set up some sort of cluster consisting of several servers all providing DNS services which is reachable under a single IP address known to the clients? Just setting up several name servers and making them known to the clients for the clients to automatically switch isn't a good solution because the clients take their timeouts and users lacking even the most basic knowledge inevitably panic when the first name server does not answer queries. _______________________________________________ CentOS mailing list CentOS at centos.org https://lists.centos.org/mailman/listinfo/centos Harriscomputer Register now for the dataVoice User Conference, October 9-11 at the Gaylord Rockies in Denver, CO. To register click Here<https://www.harriscomputer.com/en/events/> Leroy Tennison Network Information/Cyber Security Specialist E: leroy at datavoiceint.com [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG] 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com<http://www..com> This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here<http://subscribe.harriscomputer.com/>. If you prefer not to be contacted by Harris Operating Group please notify us<http://subscribe.harriscomputer.com/>. This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
On 7/25/19 2:53 PM, rainer at ultra-secure.de wrote:> Am 2019-07-25 14:51, schrieb hw: >> Hi, >> >> how can DNS reliability, as experienced by clients on the LAN who are >> sending queries, be increased? >> >> Would I have to set up some sort of cluster consisting of several >> servers all providing DNS services which is reachable under a single >> IP address known to the clients? >> >> Just setting up several name servers and making them known to the clients >> for the clients to automatically switch isn't a good solution because >> the clients take their timeouts and users lacking even the most basic >> knowledge inevitably panic when the first name server does not answer >> queries. > > Run a local cache (unbound) and enter all your local resolvers as upstreams.That can fail just as well --- or be even worse when the clients can't switch over anymore. I have that and am avoiding to use it for some clients because it takes a while for the cache to get updated when I make changes. However, if that cache fails, chances are that the internet connection is also down in which case it can be troublesome to even get local host names resolved. When that happens, trouble is to be expected.
On 25/07/2019 13:51, hw wrote:> Hi, > > how can DNS reliability, as experienced by clients on the LAN who are > sending queries, be increased? > > Would I have to set up some sort of cluster consisting of several > servers all providing DNS services which is reachable under a single > IP address known to the clients? > > Just setting up several name servers and making them known to the clients > for the clients to automatically switch isn't a good solution because > the clients take their timeouts and users lacking even the most basic > knowledge inevitably panic when the first name server does not answer > queries.Sounds like you're performing maintenance on your servers (a) too often (b) during office / peak hours You could load balance multiple servers (using lots of available load-balancing technologies) to allow you to perform maintenance at certain times, but it has its own issues. I've recently been looking at PowerDNS, which separates the recursor and the authoritative server into two distinct packages. I'm just running the authoritative server as a master, and keeping my old bind/named servers as recursors / slaves. It's a home office network, but I only have issues when I'm tinkering, and if I were to be doing this kind of work in a larger commercial environment, then I would not be doing DNS server maintenance while others were relying on them. For much of the back end infrastructure I use IP addresses rather than DNS names in their configuration, just to take DNS issues out of the equation completely.
I'm about to do an overhaul of the DNS service at work and my plan is to use powerdns recursor + dnsdist + keepalived. --- Sent from the Delta quadrant using Borg technology! On 2019-07-25 14:28, Leroy Tennison wrote:> If you don't want multiple DNS server entries on the client then a > master and (possibly multiple) slave server configuration can be set > up (I'm assuming ISC DNS - their solution to redundancy/failover is > master and slave servers, this may be the way it is with all DNS). > keepalived can be used for fail over and will present a single IP > address (which the clients would use) shared among the servers. > haproxy or alternatives might be another fail over option. Each > technology has its own learning curve (and doing this will require at > least two) and caveats. In particular systemd doesn't appear to play > well with technologies creating IP addresses it doesn't manage. The > version of keepalived we're using also has its own nasty quirk as well > where it comes up assuming it is master until discovered otherwise, > this is true even if it is configured as backup. In most cases this > is probably either a non-issue (no scripts being used) or a minor > annoyance. But if you're using scripts trigger > ed by keepalived which make significant (and possibly conflicting) > changes to the environment then you'll need to embed "intelligence" in > them to wait until final state is reached or test state before acting > or some other option. > > ________________________________ > From: CentOS <centos-bounces at centos.org> on behalf of hw <hw at gc-24.de> > Sent: Thursday, July 25, 2019 7:51:39 AM > To: centos at centos.org <centos at centos.org> > Subject: [EXTERNAL] [CentOS] how to increase DNS reliability? > > > Hi, > > how can DNS reliability, as experienced by clients on the LAN who are > sending queries, be increased? > > Would I have to set up some sort of cluster consisting of several > servers all providing DNS services which is reachable under a single > IP address known to the clients? > > Just setting up several name servers and making them known to the > clients > for the clients to automatically switch isn't a good solution because > the clients take their timeouts and users lacking even the most basic > knowledge inevitably panic when the first name server does not answer > queries. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > > Harriscomputer > > Register now for the dataVoice User Conference, > October 9-11 at the Gaylord Rockies in Denver, CO. > To register click Here<https://www.harriscomputer.com/en/events/> > > > Leroy Tennison > Network Information/Cyber Security Specialist > E: leroy at datavoiceint.com > > > [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG] > > > 2220 Bush Dr > McKinney, Texas > 75070 > www.datavoiceint.com<http://www..com> > > > This message has been sent on behalf of a company that is part of the > Harris Operating Group of Constellation Software Inc. These companies > are listed here<http://subscribe.harriscomputer.com/>. > > If you prefer not to be contacted by Harris Operating Group please > notify us<http://subscribe.harriscomputer.com/>. > > > > This message is intended exclusively for the individual or entity to > which it is addressed. This communication may contain information that > is proprietary, privileged or confidential or otherwise legally exempt > from disclosure. If you are not the named addressee, you are not > authorized to read, print, retain, copy or disseminate this message or > any part of it. If you have received this message in error, please > notify the sender immediately by e-mail and delete all copies of the > message. > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos
On 7/25/19 3:28 PM, Leroy Tennison wrote:> If you don't want multiple DNS server entries on the clientI'm ok with them, only the problem is that the clients take their timeouts when a server is unreachable, and users panic.> then a master and (possibly multiple) slave server configuration can be set up (I'm assuming ISC DNS - their solution to redundancy/failover is master and slave servers, this may be the way it is with all DNS).Yes, bind9, and I've set up a master and a slave. The router uses them to forward requests to on behalf of those clients that use the router as a name server while other clients know master and slave but not the router as name servers. There was a failure a while ago (IIRC because of a UPS causing a server to shut down when the battery failed the self test), and things didn't quite work anymore with the master server being unreachable. This is how I have a problem with the clients knowing multiple servers: The very setup is intended to keep things working during an outage and yet it doesn't help.> keepalived can be used for fail over and will present a single IP address (which the clients would use) shared among the servers. haproxy or alternatives might be another fail over option.Thanks, I'll look into that! I've been searching for "dns proxy" and no useful results came up ...> Each technology has its own learning curve (and doing this will require at least two) and caveats. In particular systemd doesn't appear to play well with technologies creating IP addresses it doesn't manage. The version of keepalived we're using also has its own nasty quirk as well where it comes up assuming it is master until discovered otherwise, this is true even if it is configured as backup. In most cases this is probably either a non-issue (no scripts being used) or a minor annoyance. But if you're using scripts trigger > ed by keepalived which make significant (and possibly conflicting) changes to the environment then you'll need to embed "intelligence" in them to wait until final state is reached or test state before acting or some other option.I consider myself warned :)
On 7/25/19 4:07 PM, Giles Coochey wrote:> > On 25/07/2019 13:51, hw wrote: >> Hi, >> >> how can DNS reliability, as experienced by clients on the LAN who are >> sending queries, be increased? >> >> Would I have to set up some sort of cluster consisting of several >> servers all providing DNS services which is reachable under a single >> IP address known to the clients? >> >> Just setting up several name servers and making them known to the clients >> for the clients to automatically switch isn't a good solution because >> the clients take their timeouts and users lacking even the most basic >> knowledge inevitably panic when the first name server does not answer >> queries. > > Sounds like you're performing maintenance on your servers > > (a) too often > (b) during office / peak hoursI can't help it when the primary name server goes down because the UPS fails the self test and tells the server it has 2 minutes or so left in wich case the server figures it needs to shut down. I wanted better UPSs ...> You could load balance multiple servers (using lots of available load-balancing technologies) to allow you to perform maintenance at certain times, but it has its own issues.Load balancing or clustering? At least clustering seems not entirely trivial to do.> I've recently been looking at PowerDNS, which separates the recursor and the authoritative server into two distinct packages. I'm just running the authoritative server as a master, and keeping my old bind/named servers as recursors / slaves.This can be done with bind, how does it require something called PowerDNS?> It's a home > office network, but I only have issues when I'm tinkering, and if I were to be doing this kind of work in a larger commercial environment, then I would not be doing DNS server maintenance while others were relying on them.The maintenance didn't cause any problems. You can edit the configuration just fine and restart the server when done ... :)> For much of the back end infrastructure I use IP addresses rather than DNS names in their configuration, just to take DNS issues out of the equation completely.I think this is a very bad idea because it causes lots of work and is likely to cause issues. What if you, for example, migrate remote logging to another server? All the time, you have to document every place where you put an IP address; you have to keep the documentation always up to date and then change the address at every place when you make a change. Forget one place, and things break. But when you use names instead of addresses, like 'log.example.com', you only need to make a single change at a single place such as you alter the address in your name server config. DNS can be difficult to get right, though it's not all that difficult, and once it's working, there aren't really any issues other than that a server can become unreachable.