On 7/25/19 1:10 PM, hw wrote:>> >> Configure all dns servers as primary slaves (plus 1 primary master) for >> your own domains.? I have never seen problems with resolution of local >> dns domains when the Internet was down. > > It seemed to have to do with the TTL for the local names being too > short and DNS being designed to generally query root servers rather > than sticking to their local information.It has nothing to do with the ttl. The TTL does cause expiration in an authoritative server.? TTLs only affect? caching servers.? The primary master gets changed when you edit the local zone database.? The secondary slave gets updated when the serial number in the SOA record on the primary master gets bumped.?? You must either do that manually or use a zone database management tool that does it for you. If a dns server is configured as a primary master or a secondary slave for a domain, then it is authoritative for that domain and does not require queries to any other server on your network or on the Internet.? The difference between a primary master and a secondary slave is the primary master is where you edit the zone records and the secondary slave replicates the zone database from the primary master.? Even if the primary master goes down, the secondary slave still has a copy of the zone files in it's disk files (or other database format that you configure) and will server them flawlessly. One way to see if a server is properly configured as authoritative for a domain is: nataraj at pygeum:~$ dig mydomain.com. soa @127.0.0.1 ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> mydomain.com. soa at 127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52104 ;; flags: qr *aa* rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 64f402c0c22d57aa2bbb10fc5d3a340d8c19377b924d01c2 (good) ;; QUESTION SECTION: ;mydomain.com.??? ??? ??? IN??? SOA ;; ANSWER SECTION: Mydomain.Com.??? ??? 14400??? IN??? SOA??? ns1.mydomain.com. postmaster.Mydomain.COM. 2019072505 1200 600 15552000 14400 ;; AUTHORITY SECTION: Mydomain.Com.??? ??? 14400??? IN??? NS??? ns1.Mydomain.Com. Mydomain.Com.??? ??? 14400??? IN??? NS??? ns2.Mydomain.Com. Mydomain.Com.??? ??? 14400??? IN??? NS??? ns3.Mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com.??? ??? 14400??? IN??? A??? 8.8.8.8 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 25 15:58:21 PDT 2019 ;; MSG SIZE? rcvd: 243 The AA flag in the flags section tells you that you have queried a dns server that is authoritative for the domain that you queried.? If it doesn't have the AA flag then you have not properly set up the primary master or secondary slave for that domain. If your masters and slaves are all configured correctly for a domain then they will all have the same serial number? in the SOA record (and same results for any query in that domain).? If they don't then something is wrong and your zone transfers are not occuring properly.> >> Depending on the size of your network, you can run a caching server on >> each host (configured as a primary slave for your own domains) and? then >> configure that local server to use forwarders.? When you use multiple >> forwarders the local server does not have to wait for timeouts before >> querying another server.? Then you just run 2 or more servers to use for >> forwarding.? Use forward-only to force all local servers to use only >> forwarding (for security and caching reasons).? Much simpler than using >> keepalived. > > Hm.? I thought about something like that, but without the separation > into local slaves using forwarders and the forwarders.? I will > probably do that; it seems like the most reasonable solution, and I > should have at least one forwarder anyway so as not to leak > information to the internet-only VLANs.? It would be an improvement in > several ways and give better reliability.The local server can have forward-only either on or off.? If off, It will go out directly to the Internet if it does not receive a response from a forwarder.? Using forward only and putting your forwarders on a seperate network away from your inside network means if there is a security hole in the nameserver, your inside hosts are less likely to be compromised.? ? You could also configure your ISP's or google or other public recursive name servers as forwarders if you don't want to run your own.> > It doesn't really help those clients I can not run name servers on, > though. > > > In recent years I *have not had any* problems with bind9 or >> powerdns crashing. >> >> As far as using the ISC server vs powerdns, you may want to check on >> peoples recent experiences.? There was a time when many thought powerdns >> had much better performance and fewer security issues.? For various >> reasons? I've seen some people including myself, switch back to ISC >> bind9.? I switched about 1.5 years ago because I was getting better >> performance from bind9.? You may want to check out other peoples >> experience before switching to powerdns. > > Bind has been around for ages, and I've never had any issues with it > for the last 25 years or so.? Just set it up and let it do its thing, > and it does. > > If there were performance problems, I imagine they would be more > likely due to insufficient internet bandwidth.? Perhaps it would take > all the DNS queries that come up during a week or even a month to > arrive within a second before any performance considerations become > relevant ...Exactly, a simple bind9 configuration is adequate unless you run an application with huge numbers of DNS queries.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos
On 7/25/19 4:31 PM, Nataraj wrote:> It doesn't really help those clients I can not run name servers on, > though.Another alternative is to look at the multicast dns (mdns) protocol.? I have no experience with it, so I can't say very much, but I know it exists.? I'm pretty sure it's inplemented in avahi daemon, so it may just be an issue of enabling it on the client.? If your client supports it then I would think that all you have to do is enable it. Nataraj
This brings up one of the caveats for (at least ISC) DNS, if the master goes down the slaves will take over for a time but eventually will stop serving for the domains of the master if it remains down too long. If my (sometimes faulty) memory serves me well it is in the three day range (but configurable) which is ample time unless the problem occurs early in a holiday weekend and and the notification/escalation process isn't what it should be (Murphey's Law)... ________________________________ From: CentOS <centos-bounces at centos.org> on behalf of Nataraj <incoming-centos at rjl.com> Sent: Thursday, July 25, 2019 6:31:26 PM To: centos at centos.org <centos at centos.org> 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. Subject: [EXTERNAL] Re: [CentOS] how to increase DNS reliability? On 7/25/19 1:10 PM, hw wrote:>> >> Configure all dns servers as primary slaves (plus 1 primary master) for >> your own domains. I have never seen problems with resolution of local >> dns domains when the Internet was down. > > It seemed to have to do with the TTL for the local names being too > short and DNS being designed to generally query root servers rather > than sticking to their local information.It has nothing to do with the ttl. The TTL does cause expiration in an authoritative server. TTLs only affect caching servers. The primary master gets changed when you edit the local zone database. The secondary slave gets updated when the serial number in the SOA record on the primary master gets bumped. You must either do that manually or use a zone database management tool that does it for you. If a dns server is configured as a primary master or a secondary slave for a domain, then it is authoritative for that domain and does not require queries to any other server on your network or on the Internet. The difference between a primary master and a secondary slave is the primary master is where you edit the zone records and the secondary slave replicates the zone database from the primary master. Even if the primary master goes down, the secondary slave still has a copy of the zone files in it's disk files (or other database format that you configure) and will server them flawlessly. One way to see if a server is properly configured as authoritative for a domain is: nataraj at pygeum:~$ dig mydomain.com. soa @127.0.0.1 ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> mydomain.com. soa at 127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52104 ;; flags: qr *aa* rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 64f402c0c22d57aa2bbb10fc5d3a340d8c19377b924d01c2 (good) ;; QUESTION SECTION: ;mydomain.com. IN SOA ;; ANSWER SECTION: Mydomain.Com. 14400 IN SOA ns1.mydomain.com. postmaster.Mydomain.COM. 2019072505 1200 600 15552000 14400 ;; AUTHORITY SECTION: Mydomain.Com. 14400 IN NS ns1.Mydomain.Com. Mydomain.Com. 14400 IN NS ns2.Mydomain.Com. Mydomain.Com. 14400 IN NS ns3.Mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 14400 IN A 8.8.8.8 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 25 15:58:21 PDT 2019 ;; MSG SIZE rcvd: 243 The AA flag in the flags section tells you that you have queried a dns server that is authoritative for the domain that you queried. If it doesn't have the AA flag then you have not properly set up the primary master or secondary slave for that domain. If your masters and slaves are all configured correctly for a domain then they will all have the same serial number in the SOA record (and same results for any query in that domain). If they don't then something is wrong and your zone transfers are not occuring properly.> >> Depending on the size of your network, you can run a caching server on >> each host (configured as a primary slave for your own domains) and then >> configure that local server to use forwarders. When you use multiple >> forwarders the local server does not have to wait for timeouts before >> querying another server. Then you just run 2 or more servers to use for >> forwarding. Use forward-only to force all local servers to use only >> forwarding (for security and caching reasons). Much simpler than using >> keepalived. > > Hm. I thought about something like that, but without the separation > into local slaves using forwarders and the forwarders. I will > probably do that; it seems like the most reasonable solution, and I > should have at least one forwarder anyway so as not to leak > information to the internet-only VLANs. It would be an improvement in > several ways and give better reliability.The local server can have forward-only either on or off. If off, It will go out directly to the Internet if it does not receive a response from a forwarder. Using forward only and putting your forwarders on a seperate network away from your inside network means if there is a security hole in the nameserver, your inside hosts are less likely to be compromised. You could also configure your ISP's or google or other public recursive name servers as forwarders if you don't want to run your own.> > It doesn't really help those clients I can not run name servers on, > though. > > > In recent years I *have not had any* problems with bind9 or >> powerdns crashing. >> >> As far as using the ISC server vs powerdns, you may want to check on >> peoples recent experiences. There was a time when many thought powerdns >> had much better performance and fewer security issues. For various >> reasons I've seen some people including myself, switch back to ISC >> bind9. I switched about 1.5 years ago because I was getting better >> performance from bind9. You may want to check out other peoples >> experience before switching to powerdns. > > Bind has been around for ages, and I've never had any issues with it > for the last 25 years or so. Just set it up and let it do its thing, > and it does. > > If there were performance problems, I imagine they would be more > likely due to insufficient internet bandwidth. Perhaps it would take > all the DNS queries that come up during a week or even a month to > arrive within a second before any performance considerations become > relevant ...Exactly, a simple bind9 configuration is adequate unless you run an application with huge numbers of DNS queries.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos_______________________________________________ CentOS mailing list CentOS at centos.org https://lists.centos.org/mailman/listinfo/centos
On 26/07/2019 14:45, Leroy Tennison wrote:> This brings up one of the caveats for (at least ISC) DNS, if the master goes down the slaves will take over for a time but eventually will stop serving for the domains of the master if it remains down too long. If my (sometimes faulty) memory serves me well it is in the three day range (but configurable) which is ample time unless the problem occurs early in a holiday weekend and and the notification/escalation process isn't what it should be (Murphey's Law)...The value you refer to is the SOA record _expire_ value for a zone, I believe is should be set to between 14 and 28 days. https://en.wikipedia.org/wiki/SOA_record
On Jul 25, 2019, at 5:42 PM, Nataraj <incoming-centos at rjl.com> wrote:> > On 7/25/19 4:31 PM, Nataraj wrote: >> It doesn't really help those clients I can not run name servers on, >> though. > > Another alternative is to look at the multicast dns (mdns) protocol.That?s for allowing a device to self-advertise its own name, along with other things, like available services. If you have such devices, then configuring the other machines on the network to pay attention to such advertisements allows them to see the new names and services when they appear. ?And much more importantly, when they *disappear*, since many ZeroConf/Bonjour/Avahi/mDNS speaking devices are mobile and aren?t always available. This protocol is one common way for network printers to advertise their services, for example. (The other common way is SMB/CIFS.)> I'm pretty sure it's inplemented in avahi daemonYes, that?s an implementation of mDNS for POSIX type systems.> If your client supports > it then I would think that all you have to do is enable it.I?m not sure how this is relevant here. For mDNS to be the solution to the OP?s problems, he?d have to also have mDNS multicasts going out advertising services, so the Avahi daemon would have something to offer when a compatible program comes along looking for services to connect to. I suppose you could use mDNS in datacenter type environments, but it?s a long way away from the protocol?s original intent. You could imagine a load balancer that paid attention to mDNS advertisements to decide who?s available at the moment. But I don?t know of any such implementation.