Secondary DNS service: Difference between revisions
Strugglers (talk | contribs) (→BitFolk adds your domain: change to co.uk) |
Strugglers (talk | contribs) m (→TSIG: Fix syntax highlight warnings) |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
domains yourself. That requires more than one DNS server, but | domains yourself. That requires more than one DNS server, but | ||
BitFolk can provide up to three more for you, all of which will take | BitFolk can provide up to three more for you, all of which will take | ||
updates from your designated | updates from your designated primary server. That's the BitFolk | ||
secondary DNS service. | secondary DNS service. | ||
| Line 24: | Line 24: | ||
* <tt>a.authns.bitfolk.co.uk</tt> — London, UK | * <tt>a.authns.bitfolk.co.uk</tt> — London, UK | ||
* <tt>b.authns.bitfolk.com</tt> — | * <tt>b.authns.bitfolk.com</tt> — Fremont, CA, US | ||
* <tt>c.authns.bitfolk.com</tt> — Newark, NJ, US | * <tt>c.authns.bitfolk.com</tt> — Newark, NJ, US | ||
They are also reachable over | They are also reachable over legacy IPv4. | ||
==Configuring the secondary DNS service== | ==Configuring the secondary DNS service== | ||
| Line 58: | Line 58: | ||
has been added. | has been added. | ||
If anything is wrong then you may also receive some | If anything is wrong then you may also receive some [[Monitoring|Icinga]] [[#Alerting|alerts]] at | ||
this point. If the alert relates to your own host or to | this point. If the alert relates to your own host or to | ||
<tt>a.authns.bitfolk.co.uk</tt> then you need to fix it now. The other | <tt>a.authns.bitfolk.co.uk</tt> then you need to fix it now. The other | ||
| Line 69: | Line 69: | ||
If you'd prefer that the world only sees the BitFolk nameservers, | If you'd prefer that the world only sees the BitFolk nameservers, | ||
then you need not list your own | then you need not list your own primary nameserver. That is usually | ||
called a "hidden | called a "hidden primary" setup. | ||
It is best to use the | It is best to use the BitFolk names (<tt>a.authns.bitfolk.co.uk</tt>, <tt>b.authns.bitfolk.com</tt>, <tt>c.authns.bitfolk.com</tt>) and not | ||
your own names for the nameservers as if they ever required | your own names for the nameservers as if they ever required | ||
renumbering this would force you to make changes in a lot of places. | renumbering this would force you to make changes in a lot of places. | ||
| Line 105: | Line 105: | ||
and has a number of different monitoring checks enabled. | and has a number of different monitoring checks enabled. | ||
===Checks on your | ===Checks on your primary nameserver=== | ||
The following checks run against your | The following checks run against your primary server (usually your | ||
BitFolk VPS). | BitFolk VPS). | ||
| Line 118: | Line 118: | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
!What it looks like | !What it looks like | ||
|<syntaxhighlight> | |<syntaxhighlight lang="text"> | ||
From: | From: monitoring-bounces@bitfolk.com | ||
Subject: ** PROBLEM alert - your. | Subject: ** PROBLEM alert - your.primary.host/DNS Server is CRITICAL ** | ||
***** Nagios ***** | ***** Nagios ***** | ||
| Line 127: | Line 127: | ||
Service: DNS Server | Service: DNS Server | ||
Host: your. | Host: your.primary.host | ||
Address: 85.119.82.121 | Address: 85.119.82.121 | ||
State: CRITICAL | State: CRITICAL | ||
| Line 148: | Line 148: | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
!What it looks like | !What it looks like | ||
|<syntaxhighlight> | |<syntaxhighlight lang="text"> | ||
From: | From: monitoring-bounces@bitfolk.com | ||
Subject: ** PROBLEM alert - your. | Subject: ** PROBLEM alert - your.primary.host/Auth. DNS example.com is UNKNOWN ** | ||
***** Nagios ***** | ***** Nagios ***** | ||
| Line 157: | Line 157: | ||
Service: Auth. DNS example.com | Service: Auth. DNS example.com | ||
Host: your. | Host: your.primary.host | ||
Address: 85.119.82.121 | Address: 85.119.82.121 | ||
State: UNKNOWN | State: UNKNOWN | ||
| Line 166: | Line 166: | ||
DNS UNKNOWN - 0.600 seconds response time (No ANSWER SECTION found) | DNS UNKNOWN - 0.600 seconds response time (No ANSWER SECTION found) | ||
</syntaxhighlight> | |||
|} | |||
====Zone serials match==== | |||
{| class="wikitable" style="width: 100%" | |||
|- style="vertical-align:top;" | |||
!What it does | |||
|Checks that the serial number of the zone on your server is consistent with the serial number on all other authoritative nameservers. | |||
If this alert is received then it indicates that one or more of the authoritative servers for the given zone have a different serial number and thus likely a different/outdated version of the zone contents. It may be that zone transfers are not happening. The logs from your nameserver software will often be enlightening. | |||
It can also mean that one or more of the nameservers that you list in the zone's top level NS records are not responding or are themselves not resolvable. This will be causing real problems that force DNS clients to retry your other (working) nameservers, so you should fix it by either making the names resolve/respond or remove them from the zone entirely. | |||
|- style="vertical-align:top;" | |||
!What it looks like | |||
|<syntaxhighlight lang="text"> | |||
From: monitoring-bounces@bitfolk.com | |||
Subject: [PROBLEM] Zone serial example.com on your-ns.example.com is CRITICAL! | |||
***** BitFolk Monitoring ***** | |||
Zone serial example.com on your-ns.example.com is CRITICAL! | |||
Info: MISMATCH: b.authns.bitfolk.com 2022051715 | |||
MISMATCH: c.authns.bitfolk.com 2022051715 | |||
DNS_ZONE_SERIAL_MATCH CRITICAL - At least one server's serial for zone example.com did not match mine (2022051714) | |||
</syntaxhighlight> | </syntaxhighlight> | ||
|} | |} | ||
| Line 178: | Line 203: | ||
|Checks that your domain on BitFolk's nameserver was last refreshed within a reasonable amount of time. | |Checks that your domain on BitFolk's nameserver was last refreshed within a reasonable amount of time. | ||
The [[List_of_DNS_record_types#SOA|SOA]] record in your zone has a | The [[Wikipedia:List_of_DNS_record_types#SOA|SOA]] record in your zone has a | ||
'''refresh''' time and an '''expire''' time. Both are specified in | '''refresh''' time and an '''expire''' time. Both are specified in | ||
seconds. | seconds. | ||
The '''refresh''' time is how often secondary servers should check | The '''refresh''' time is how often secondary servers should check | ||
with your | with your primary for updates. | ||
The '''expire''' time is the maximum amount of time without | The '''expire''' time is the maximum amount of time without | ||
| Line 192: | Line 217: | ||
no successful refresh within 1.5x your '''refresh''' setting. For | no successful refresh within 1.5x your '''refresh''' setting. For | ||
example, if your '''refresh''' setting were 7200 (2 hours) and | example, if your '''refresh''' setting were 7200 (2 hours) and | ||
BitFolk's servers were unable to contact your | BitFolk's servers were unable to contact your primary for 3 hours, | ||
you would receive a warning alert. | you would receive a warning alert. | ||
| Line 204: | Line 229: | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
!What it looks like | !What it looks like | ||
|<syntaxhighlight> | |<syntaxhighlight lang="text"> | ||
From: | From: monitoring-bounces@bitfolk.com | ||
Subject: ** PROBLEM alert - a.authns.bitfolk. | Subject: ** PROBLEM alert - a.authns.bitfolk.co.uk/Last DNS refresh example.com is WARNING ** | ||
***** Nagios ***** | ***** Nagios ***** | ||
| Line 213: | Line 238: | ||
Service: Last DNS refresh example.com | Service: Last DNS refresh example.com | ||
Host: a.authns.bitfolk. | Host: a.authns.bitfolk.co.uk | ||
Address: 85.119.80.222 | Address: 85.119.80.222 | ||
State: WARNING | State: WARNING | ||
| Line 234: | Line 259: | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
!What it looks like | !What it looks like | ||
|<syntaxhighlight> | |<syntaxhighlight lang="text"> | ||
From: | From: monitoring-bounces@bitfolk.com | ||
Subject: ** PROBLEM alert - b.authns.bitfolk.com/Auth. DNS example.com is UNKNOWN ** | Subject: ** PROBLEM alert - b.authns.bitfolk.com/Auth. DNS example.com is UNKNOWN ** | ||
| Line 255: | Line 280: | ||
|} | |} | ||
==DNSSEC== | ==<abbr title="Domain Name System Security Extensions">DNSSEC</abbr>== | ||
BitFolk's authoritative nameservers have no problem serving | BitFolk's authoritative nameservers have no problem serving | ||
[[Wikipedia:DNSSEC|DNSSEC]] record types. | [[Wikipedia:DNSSEC|DNSSEC]] record types. | ||
==<abbr title="Transaction Signature">TSIG</abbr>== | |||
Normally BitFolk authenticates your zone updates only by IP address. If you would like to also do [[Wikipedia:TSIG|TSIG]] authentication then that is possible, but isn't very integrated with BitFolk's systems at the moment so will have to be specifically requested by support ticket. | |||
This is based on a shared secret, so either BitFolk or you will need to create the private key and then it will need to be communicated between you. This should be done by some secure method such as [[Wikipedia:PGP|PGP]] encryption. | |||
An example of key creation using tools from the [[Wikipedia:BIND|BIND]] package: | |||
<syntaxhighlight lang="text"> | |||
# dnssec-keygen -a HMAC-SHA512 -b 128 -n HOST bitfolk-ruminant | |||
Kbitfolk-ruminant.+165+31748 | |||
</syntaxhighlight> | |||
It would then be the contents of either the '''Kbitfolk-ruminant.+165+31748.key''' file or the '''Kbitfolk-ruminant.+165+31748.private''' file (they both contain essentially the same information) that needs to be shared between you and BitFolk. | |||
==Useful resources== | ==Useful resources== | ||
* Your nameserver logs! Most nameserver software is really quite keen to tell you what's wrong. | * Your nameserver logs! Most nameserver software is really quite keen to tell you what's wrong. | ||
* [http://dns.squish.net/ squish.net DNS comprehensive traversal checker] | * [http://dns.squish.net/ squish.net DNS comprehensive traversal checker] | ||
Latest revision as of 23:42, 22 May 2022
BitFolk provides a free secondary DNS service for VPS customers.
Secondary DNS service
Since you have a VPS you may be interested in running DNS for your domains yourself. That requires more than one DNS server, but BitFolk can provide up to three more for you, all of which will take updates from your designated primary server. That's the BitFolk secondary DNS service.
Eligibility
BitFolk is happy to provide free DNS secondary service for every customer for up to 50 domains, provided that total number of queries for all domains is "reasonable" (below several hundred thousand requests per month).
This complimentary service is intended for VPS customers with a few domains and no access to additional servers. Those wishing to run DNS for more than 50 domains or for extremely busy domains can still be accommodated but there will be additional charge. Please contact support for a quote.
Servers
BitFolk currently operates DNS servers in the following locations:
- a.authns.bitfolk.co.uk — London, UK
- b.authns.bitfolk.com — Fremont, CA, US
- c.authns.bitfolk.com — Newark, NJ, US
They are also reachable over legacy IPv4.
Configuring the secondary DNS service
For each domain you wish to add to the BitFolk secondary DNS service you'll need to carry out the following steps.
Serve the domain yourself
Firstly you'll need to add the domain to an authoritative DNS server that is under your control. This would normally be your VPS, but can be any other authoritative DNS server you like as long as they will allow AXFR from BitFolk.
You need to allow AXFR from:
- 85.119.80.222
That is port 53 TCP, and you'll probably need to allow it in the access control of your DNS server also. With bind 9, the default is to allow transfers to all hosts, but you can limit it via the allow-transfer option.
Contact support
Once you have done the above, please contact support with:
- The IP address of your DNS server
- The name of your domain
BitFolk adds your domain
You'll receive a response from support to indicate that your domain has been added.
If anything is wrong then you may also receive some Icinga alerts at this point. If the alert relates to your own host or to a.authns.bitfolk.co.uk then you need to fix it now. The other BitFolk nameservers won't take a copy of your zone until there's a copy on a.authns.bitfolk.co.uk.
Add the BitFolk DNS servers to your domain's NS list
If you haven't done so already then you should add the BitFolk DNS servers to your domain's list of NS records.
If you'd prefer that the world only sees the BitFolk nameservers, then you need not list your own primary nameserver. That is usually called a "hidden primary" setup.
It is best to use the BitFolk names (a.authns.bitfolk.co.uk, b.authns.bitfolk.com, c.authns.bitfolk.com) and not your own names for the nameservers as if they ever required renumbering this would force you to make changes in a lot of places.
Do a final check that everything is being served correctly
BitFolk's DNS monitoring does a good job of checking that things are being served correctly, but you should also verify for yourself that:
- Your nameserver is serving the domain correctly;
- Each of BitFolk's nameservers are also serving the domain correctly.
Up until this point you have not directed any live DNS traffic at BitFolk's DNS infrastructure.
Update your nameserver list in the parent domain
 Warning: | Do this step last, after you have personally confirmed that everything is correct! Up until this point no live DNS traffic for your domain has been directed at BitFolk's DNS infrastructure. |
To start directing live DNS traffic to your chosen nameservers you must list them in the parent domain. Normally you do that by contacting your domain registrar to tell them the list of nameservers to use. These are the nameservers that appear in WHOIS.
Secondary DNS and the BitFolk Panel
The BitFolk Panel has a currently read-only list of the domains you have configured for secondary DNS. There's a feature request open for the ability to add, remove and disable domains from this web interface without having to contact support. Please vote it up if you're interested in seeing this implemented.
Alerting
The secondary DNS service is one of the more complicated services and has a number of different monitoring checks enabled.
Checks on your primary nameserver
The following checks run against your primary server (usually your BitFolk VPS).
TCP port 53 open
| What it does | Checks that your TCP port 53 is open. Your own nameserver should be listening on this port ready to accept connections for AXFR to take place.
If this alert is received then it indicates that BitFolk's monitoring can't connect to your DNS server. |
|---|---|
| What it looks like | From: monitoring-bounces@bitfolk.com
Subject: ** PROBLEM alert - your.primary.host/DNS Server is CRITICAL **
***** Nagios *****
Notification Type: PROBLEM
Service: DNS Server
Host: your.primary.host
Address: 85.119.82.121
State: CRITICAL
Date/Time: Sat Jan 21 22:05:27 UTC 2012
Additional Info:
Connection refused
|
Nameserver is authoritative
| What it does | Checks that your nameserver is prepared to say it is authoritative for the domain in question.
If this alert is received then it indicates that your nameserver doesn't think it is authoritative for the domain in question. Likely reasons would be that you haven't configured the domain, haven't reloaded the server after configuring it, or are refusing queries. |
|---|---|
| What it looks like | From: monitoring-bounces@bitfolk.com
Subject: ** PROBLEM alert - your.primary.host/Auth. DNS example.com is UNKNOWN **
***** Nagios *****
Notification Type: PROBLEM
Service: Auth. DNS example.com
Host: your.primary.host
Address: 85.119.82.121
State: UNKNOWN
Date/Time: Sat Jan 21 22:05:27 UTC 2012
Additional Info:
DNS UNKNOWN - 0.600 seconds response time (No ANSWER SECTION found)
|
Zone serials match
| What it does | Checks that the serial number of the zone on your server is consistent with the serial number on all other authoritative nameservers.
If this alert is received then it indicates that one or more of the authoritative servers for the given zone have a different serial number and thus likely a different/outdated version of the zone contents. It may be that zone transfers are not happening. The logs from your nameserver software will often be enlightening. It can also mean that one or more of the nameservers that you list in the zone's top level NS records are not responding or are themselves not resolvable. This will be causing real problems that force DNS clients to retry your other (working) nameservers, so you should fix it by either making the names resolve/respond or remove them from the zone entirely. |
|---|---|
| What it looks like | From: monitoring-bounces@bitfolk.com
Subject: [PROBLEM] Zone serial example.com on your-ns.example.com is CRITICAL!
***** BitFolk Monitoring *****
Zone serial example.com on your-ns.example.com is CRITICAL!
Info: MISMATCH: b.authns.bitfolk.com 2022051715
MISMATCH: c.authns.bitfolk.com 2022051715
DNS_ZONE_SERIAL_MATCH CRITICAL - At least one server's serial for zone example.com did not match mine (2022051714)
|
Checks on BitFolk's infrastructure
The following checks are run against BitFolk's DNS infrastructure, but may still indicate a problem with your configuration.
Last domain refresh time
| What it does | Checks that your domain on BitFolk's nameserver was last refreshed within a reasonable amount of time.
The SOA record in your zone has a refresh time and an expire time. Both are specified in seconds. The refresh time is how often secondary servers should check with your primary for updates. The expire time is the maximum amount of time without successful refresh that secondary servers are allowed to serve your domain. If you receive a warning alert then this means that there has been no successful refresh within 1.5x your refresh setting. For example, if your refresh setting were 7200 (2 hours) and BitFolk's servers were unable to contact your primary for 3 hours, you would receive a warning alert. If you receive a critical alert then this means that you're half way towards your expire setting with no successful refresh. Should the expire time be reached, BitFolk's nameservers will return SERVFAIL for all queries. That would be bad. Your nameserver log files most likely contain details about why refresh has been failing. |
|---|---|
| What it looks like | From: monitoring-bounces@bitfolk.com
Subject: ** PROBLEM alert - a.authns.bitfolk.co.uk/Last DNS refresh example.com is WARNING **
***** Nagios *****
Notification Type: PROBLEM
Service: Last DNS refresh example.com
Host: a.authns.bitfolk.co.uk
Address: 85.119.80.222
State: WARNING
Date/Time: Sat Jan 21 22:05:27 UTC 2012
Additional Info:
FILE_AGE WARNING: /etc/bind/slave/example.com is 44898 seconds old and 488 bytes
|
Nameserver is authoritative
| What it does | Checks that BitFolk's nameservers are prepared to say they are authoritative for the domain in question.
If this alert is received then it indicates that a BitFolk nameserver doesn't think it is authoritative for the domain in question. The most likely reason would be that zone transfers to BitFolk's nameservers have never yet worked. Your log files will probably give more information. |
|---|---|
| What it looks like | From: monitoring-bounces@bitfolk.com
Subject: ** PROBLEM alert - b.authns.bitfolk.com/Auth. DNS example.com is UNKNOWN **
***** Nagios *****
Notification Type: PROBLEM
Service: Auth. DNS example.com
Host: b.authns.bitfolk.com
Address: 209.237.247.198
State: UNKNOWN
Date/Time: Sat Jan 21 22:05:27 UTC 2012
Additional Info:
DNS UNKNOWN - 0.600 seconds response time (No ANSWER SECTION found)
|
DNSSEC
BitFolk's authoritative nameservers have no problem serving DNSSEC record types.
TSIG
Normally BitFolk authenticates your zone updates only by IP address. If you would like to also do TSIG authentication then that is possible, but isn't very integrated with BitFolk's systems at the moment so will have to be specifically requested by support ticket.
This is based on a shared secret, so either BitFolk or you will need to create the private key and then it will need to be communicated between you. This should be done by some secure method such as PGP encryption.
An example of key creation using tools from the BIND package:
# dnssec-keygen -a HMAC-SHA512 -b 128 -n HOST bitfolk-ruminant
Kbitfolk-ruminant.+165+31748
It would then be the contents of either the Kbitfolk-ruminant.+165+31748.key file or the Kbitfolk-ruminant.+165+31748.private file (they both contain essentially the same information) that needs to be shared between you and BitFolk.
Useful resources
- Your nameserver logs! Most nameserver software is really quite keen to tell you what's wrong.
- squish.net DNS comprehensive traversal checker