[gentoo-user] Re: DNS server packages
J. Roeleveld antarean.org> writes: > > On Sunday, October 11, 2015 02:48:23 PM Alan McKinnon wrote: > > On 11/10/2015 11:33, J. Roeleveld wrote: > > > On Sunday, October 11, 2015 10:43:01 AM Alan McKinnon wrote: > > >> On 11/10/2015 10:18, J. Roeleveld wrote: > > > In a database I have a table with the following fields: > > > MAC, IP, Hostname, domain > > > xx:xx:xx:xx:xx , 1.2.3.4 , vmobi1114node1 , vm1.lab.example.com > > > > I want the DNS server to use the IP, Hostname and domain fields for > > > the resolving. > > > I want the DHCP server to use all the fields for the DHCP assignments. A cluster is very reliable as nodes (slaves) can be added and removed for individual admin needs, keeping 'the beast' HA. You can even put part of your cluster (for redundancy and peak loading) partially on a remote DatatCenter like 'rackspace'; should the HA requirements be such to justify the extra expense. Or a smaller vendor on another network; reciprocity style. I hope to have mine up by Christmas. > > OK, that makes sense. You'd think all decent DNS and DHCP servers out > > there would support any old arb db backend (very useful, no?) but it > > seems not. I've gotten used to independently vi'ing two files and > > HUP/reload two daemons over the years > > Bind can use a mysql backend, so can most auth servers. > Need to check how difficult/easy it is to make it listen to PostgreSQL. > I'm not overly attached to Bind. Having a DNS server that's easier to > configure and maintain would be appreciated. Here is something that many are playing with:: https://github.com/mesosphere/mesos-dns/blob/master/README.md Many are posting about the wonderfulness and stability of web services even on a smaller cluster. ymmv. hth, James
[gentoo-user] Re: DNS server packages
Alan McKinnon gmail.com> writes: > > These are the (2) net facing primary and slave dns servers, just for the > > few domain names I willauthenticate. They'll be behind a firewall > > (iptables/dmz) with no internal zone information. Strictly auth, public > > facing, with DNSsec. > Then you need your chosen name server (bind), your chosen fw ruleset > generators (iptables, maybe some other front end) and maybe fail2ban or > one of it's friends if you find some port gets hammered. fail2ban. an excellent additional package. > How much ram do you think you need? The idea is to minimize the ram footprint. -Os in the make.conf file should keep things small, with little performance degradation. Profile:: [1] default/linux/amd64/13.0 * Do you think I can keep the HD size (ide-CompactFlash) below 4 gig? I did years ago on a gentoo firewall circa 2009. Tricks for OS size minimization are the focus now. > > Bind9, dnssec-tools, iptables:: any other packages relevant/germane > > on a amd-default profile [1] ? > Yes, that's about it. > Add in all the other usual server stuff you like to use - monitoring, > logging, notifications, mail, whatever mailx, another good idea. OK, now a minimized set of flag setting for make.conf:: USE="-8 ncurses ssl crypt berkdb pam perl pcre python readline zlib bzip2 nptl syslog" were the flags on that minimzed gentoo (firewall) systems; further reducing the globals flag is warranted? Any suggestions on flag minimization? with:: CFLAGS=" -march=native -Os -pipe" I hope I can get the total size @ or below 3 GB, as I have several 4 GB CF cards on hand; other suggestions? James
Re: [gentoo-user] Re: DNS server packages
On 12/10/2015 19:43, James wrote: > Alan McKinnon gmail.com> writes: > > >>> I need to setup DNS primary/secondary systems on gentoo. So right now >>> I'm looking for a suggested list of packages to install with Bind, >>> iptables and DNSSEC-tools as these (2) gentoo dns servers will only >>> run the minimum packages to operate securely? >> auth or cache? > > These are the (2) net facing primary and slave dns servers, just for the > few domain names I willauthenticate. They'll be behind a firewall > (iptables/dmz) with no internal zone information. Strictly auth, public > facing, with DNSsec. The plan is to go slow with manual configuration and > and slow add features like a database, as I roll out new auth-DNS servers > on newer, embedded hardware (very small very low power, but lots of ram > (2G)). So over time the scope will evolve. It's a manual approach to a > refresher for me. Eventually one of the auth-dns-slaves will be an arm > cluster for performance testing on mesos. (That's a ways off). > > > So also, the iptables rules for such a setup will need to be revisited, > dusting off what I use to use. Again, the importance is trying different > packages and sniffing the results and examining log files (manually and with > scripts) on a log host. So only ports 53 (public/routable net visible > and port 22 from a select sets of private ips is all these will need. Then you need your chosen name server (bind), your chosen fw ruleset generators (iptables, maybe some other front end) and maybe fail2ban or one of it's friends if you find some port gets hammered. Block all ports except 53 and 22, send all logs to a remote syslogger and trawl through them to your heart's content. All very usual and normal. >> First of all, bind is a pain to use. Reason: it's actually a reference >> implementation that as usual got forced into production use. It's slower >> than it could be because it deals with every possible corner case per RFC. >> As an auth server (few queries) it's OK > > Bind is an old acquaintance of mine:: been a few years, hence the post. > I may test/migrate to something else, later. OK. For a few domains there's no benefit to using something other than what you already know. > >> As a cache (many queries), there are better servers out there. I prefer >> unbound. > > A Caching DNS server for internal usages is another project for another > time. It will be totally isolated; still, good to know. > > >>> Also, what is the (nominal) minimum amount of RAM needed to keep all >>> routes in ram in these name servers? >> I don't understand. DNS servers don't keep routes in memory - routers do >> that. Perhaps you mean cached DNS records? >> DNS is light on RAM, there are only so many records typical users will >> look up. DNS caches not too long ago ran for years problem free with a >> puny few hundred MB. It's not something to be worried about. > > There should be a way to keep all the responses for the zones info they > server in ram? I know it often happens without intervention, but surely > there are published methods to insure this info is kept "in ram" like > bcachefs? > > Also flushing and ram usage status monitoring, as these auth dns servers > will eventually migrate to low power embedded machines where keeping > things in ram is critical to performance. I can't help but feel you are worried about a problem that doesn't exist. It takes lots and lots and lots of zones to get above 1M disk space. How much ram do you think you need? DNS caches are resource intensive (the upper limit on what they cache is the internet) DNS auth servers are not (their upper limit is how many bytes in the zones) and they tend to idle most of the time. Well unless you do silly things like set all TTLs to 1 (or god forbid, 0) and your auth server becomes a cache > > 'eix -cC net-dns | grep auth' > Curiously, Are they better, more easily secured solutions? > > > It's been a hwile for me so a vetting of the packages is the first step > for this minimal, manual setup of the auth-dns servers for a few domain > names:: > > > Bind9, dnssec-tools, iptables:: any other packages relevant/germane > on a amd-default profile [1] ? Yes, that's about it. Add in all the other usual server stuff you like to use - monitoring, logging, notifications, mail, whatever -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: DNS server packages
Alan McKinnon gmail.com> writes: > > I need to setup DNS primary/secondary systems on gentoo. So right now > > I'm looking for a suggested list of packages to install with Bind, > > iptables and DNSSEC-tools as these (2) gentoo dns servers will only > > run the minimum packages to operate securely? > auth or cache? These are the (2) net facing primary and slave dns servers, just for the few domain names I willauthenticate. They'll be behind a firewall (iptables/dmz) with no internal zone information. Strictly auth, public facing, with DNSsec. The plan is to go slow with manual configuration and and slow add features like a database, as I roll out new auth-DNS servers on newer, embedded hardware (very small very low power, but lots of ram (2G)). So over time the scope will evolve. It's a manual approach to a refresher for me. Eventually one of the auth-dns-slaves will be an arm cluster for performance testing on mesos. (That's a ways off). So also, the iptables rules for such a setup will need to be revisited, dusting off what I use to use. Again, the importance is trying different packages and sniffing the results and examining log files (manually and with scripts) on a log host. So only ports 53 (public/routable net visible and port 22 from a select sets of private ips is all these will need. > First of all, bind is a pain to use. Reason: it's actually a reference > implementation that as usual got forced into production use. It's slower > than it could be because it deals with every possible corner case per RFC. > As an auth server (few queries) it's OK Bind is an old acquaintance of mine:: been a few years, hence the post. I may test/migrate to something else, later. > As a cache (many queries), there are better servers out there. I prefer > unbound. A Caching DNS server for internal usages is another project for another time. It will be totally isolated; still, good to know. > > Also, what is the (nominal) minimum amount of RAM needed to keep all > > routes in ram in these name servers? > I don't understand. DNS servers don't keep routes in memory - routers do > that. Perhaps you mean cached DNS records? > DNS is light on RAM, there are only so many records typical users will > look up. DNS caches not too long ago ran for years problem free with a > puny few hundred MB. It's not something to be worried about. There should be a way to keep all the responses for the zones info they server in ram? I know it often happens without intervention, but surely there are published methods to insure this info is kept "in ram" like bcachefs? Also flushing and ram usage status monitoring, as these auth dns servers will eventually migrate to low power embedded machines where keeping things in ram is critical to performance. 'eix -cC net-dns | grep auth'
