3 ms·

Z2 (no, Z is not on the list you have) You need at least two nodes that do DNS, DHCP, NTP, and other miscellaneous services that you absolutely want to have bu

by dsr_ 10y ago

Z2 (no, Z is not on the list you have) You need at least two nodes that do DNS, DHCP, NTP, and other miscellaneous services that you absolutely want to have but do not seem to have mentioned. You want them to be permanently assigned, so that you never have to search for them, and you want them to fail over each service as needed, preferably both operating at once. Three nodes would be better. Consider doing some basic monitoring on these nodes, too, as a backup to your main monitoring system.

skuhn 10y ago
Absolutely agree. Typically I deploy about 4-6 "tools" hosts in a site. From a computational standpoint, you could make do with fewer hosts, but there are some things that I prefer to separate out: 1&2. Authoritative DNS (internal) 1&2. NTP 1&2. Caching DNS resolver 3&4. Outbound HTTP proxy (if necessary) 3&4. PXE / installer / dhcp 3&4. Local software mirror (apt / yum / etc.) 5&6. SSH jump hosts. Or something like that. Make sure the second host is not just in a separate chassis from the first host, but also in a separate rack. For external authoritative DNS, don't do it yourself -- pay for someone to run that for you (Route53, ns1, etc.). For e-mail, if you can possibly not deal with it then don't -- use Mailchimp or something.
- sytse 10y ago
  Good points, thanks!
- stp-ip 10y ago
  Sidenote: We are running coredns.io in production as authoritative internal DNS and as hidden master with NOTIFY to a secondary DNS provider (currently DNSmadeEasy). The DNS records for the internal records are done using the kubernetes middleware (basically serving the service records). The external records are pulled in from a git repository hosting our zones as bind files. If need be zones are split into subzones per team/project. Same permission system as our code via MRs using Gitlab. Our recommendation is build on open standards (BIND, AXFR) and use services on top of these. I agree that using an external mail provider is usually a good idea. It mostly is your fallback communication channel and is usually easy to switch (doing replication to an offsite mail storage needs to be done to make switching easy/possible/fast). MX records \o/

by dsr_ 10y ago

skuhn 10y ago

Absolutely agree. Typically I deploy about 4-6 "tools" hosts in a site. From a computational standpoint, you could make do with fewer hosts, but there are some things that I prefer to separate out: 1&2. Authoritative DNS (internal) 1&2. NTP 1&2. Caching DNS resolver 3&4. Outbound HTTP proxy (if necessary) 3&4. PXE / installer / dhcp 3&4. Local software mirror (apt / yum / etc.) 5&6. SSH jump hosts. Or something like that. Make sure the second host is not just in a separate chassis from the first host, but also in a separate rack. For external authoritative DNS, don't do it yourself -- pay for someone to run that for you (Route53, ns1, etc.). For e-mail, if you can possibly not deal with it then don't -- use Mailchimp or something.

sytse 10y ago
Good points, thanks!
stp-ip 10y ago
Sidenote: We are running coredns.io in production as authoritative internal DNS and as hidden master with NOTIFY to a secondary DNS provider (currently DNSmadeEasy). The DNS records for the internal records are done using the kubernetes middleware (basically serving the service records). The external records are pulled in from a git repository hosting our zones as bind files. If need be zones are split into subzones per team/project. Same permission system as our code via MRs using Gitlab. Our recommendation is build on open standards (BIND, AXFR) and use services on top of these. I agree that using an external mail provider is usually a good idea. It mostly is your fallback communication channel and is usually easy to switch (doing replication to an offsite mail storage needs to be done to make switching easy/possible/fast). MX records \o/