Roller Network Help - Secondary DNS
Secondary DNS Service
Secondary DNS service loads zone files using AXF/IXFR from another DNS server. Some options may require an upgraded account.
It is best practice to use DNS servers from at least two different providers that don't share any common network or management in case of outages or DDoS attacks. Secondary DNS supports secure TSIG zone transfers to load data for your zone.
In the event of DDoS attacks targeted at a Secondary DNS zone, Roller Network will rate limit or block queries to that domain.
Secondary Authoritative Server List
Secondary DNS zones are served and loaded from the following:
See the Server Information section for IP addresses. Use these to update the name servers at your domain registry in order to utilize our Secondary DNS service. Also, ensure that you have NS records in your zone file for these servers.
Secondary DNS service is IPv6 enabled.
To add a new Secondary DNS zone, click on the "Add New Zone" button. You may specify domain names, subdomains, or reverse zones (IPv4 and IPV6) as the zone name. The master server may be specified by IP address (IPv4 or IPv6) or by host name (IPv4). We strongly recommend using an IP address for the master. Although host names are allowed, they are not recommended if you require reliable service since we must perform an IP address lookup to build the slave configuration with the master IP address. Configuartions can't be built with DNS names. If this lookup fails the zone will be automatically disabled.
Up to three IP addresses may be specified to allow AXFR access to a zone. These IP addresses will also receive a NOTIFY if the "Enable NOTIFY" option is set to "Yes".
When adding a zone for the first time it may take up to an hour before the slave configuration is built and the first transfer by our slaves is attempted.
You must allow AXFR requests from our slave server and your master server in order for Secondary DNS to load the zone file. A current list of our IP addresses can be found on the resource access page. Our slaves will respond to a NOTIFY from the master.
Zones that have a master server refuse AXFR will be automatically disabled.
Additional Configuration and Maintenance
After adding a new zone you may change its settings at any time by clicking on the zone name on the Secondary DNS page. You may change the master server at any time, along with any advanced options. (These changes may take up to an hour before the slave configuration is rebuilt.)
There are also two maintenance options: Retransfer Zone Files and Delete Zone Files. The Retransfer Zone Files option will command our servers to request a zone transfer. The Delete Zone Files option will delete the existing zone file from our servers. The current zone file status for each server is shown in the Zone File Status status field. Please note that if you delete your zone file and it can't be reloaded from the master, the slaves no longer have data for the zone. Both maintenance options take effect immediately, although a retransfer request may wait in the queue if there are too many pending requests.
Logging for Secondary DNS zones is available online in the Secondary DNS section. These are standard BIND logging messages. Successful transfers, notifies, and error messages related to a zone name will be logged. Please check the logs before contacting us for help. A maintenance script is run at midnight on the first day of each month (US/Pacific time) that will remove log entries older than two months from the database.
To check the zone file status, click on the zone name and look at the "Zone File Status" status field. If it shows "Not Present" then the zone has not been successfully transferred yet.
If you get "Error processing request" after clicking on Retransfer Zone Files this means the slave configuration for this zone has not been built yet. (Changes are only rebuilt in the BIND configuration files every 5 to 15 minutes.) If you get "Error processing request" after clicking on Delete Zone Files, then the zone files do not exist or have already been deleted.
Email Alert on Disable
This option will send an alert message by email if the zone is automatically disabled by our system for one of the conditions described in "Automatic Secondary Zone Deactivation" below.
Only one notice will be sent at the time the error occurs. If proactive monitoring is required, a external probe should be used to query our servers for your zone to ensure they are serving a zone as expected. Roller Network is not responsible for monitoring individual zones.
Allow AXFR Access
Up to three additional IP addresses can be configured to allow AXFR access to this zone. This is normally used for monitoring or stealth master configurations, although it may be useful for other scenarios. If "Send NOTIFY" is enabled these IP addresses will also always get a NOTIFY (BIND 'notify yes' and 'also-notify' parameters).
A TSIG key can be used to authenticate a zone transfer. To enable TSIG for a zone enter the private key and match the key name on the master. Key names for Secondary DNS zones are prefixed with information unique to your account to prevent overlap in our system.
DNS Transaction SIGnature (TSIG)
DNS TSIG (short for "Transaction SIGnature") is a method of authenticating transfer requests with shared secret keys and one-way hashing to identify the connection. TSIG keys can be used to authorize and sign AXFR requests.
When adding a TSIG key the name will be prefixed with your account control center login name for unique key naming purposes. After adding a TSIG key it can be associated with a master server by going into a secondary zone's configuration (click on the zone in the DNS Zones tab) and setting the TSIG keys under Master Server Settings.
Common Errors for Secondary DNS Zones
The most common problem for Secondary DNS zones is the master refusing the zone transfer. If you are having trouble getting your Secondary DNS zone to load verify that your master is allowing zone transfer requests from our servers.
In the event that your Secondary DNS zone expires (as determined by the "expire" value in your SOA record), the message "zone example.com/IN: expired" will be logged. When a zone expires it is automatically disabled. The recommended expire time for a zone is 2-3 weeks (1209600-1814400 seconds).
If a zone has expired the old zone file data may trigger an expire and disable cycle before it can be reloaded from the master. To resolve this delete the old zone file data on our servers by clicking on "Delete Zone Files" under the zone file status section. The status should read "Not Present" or "Deleted" before you try to refresh or enable an expired zone.
The account control center looks for a "expired" log message from BIND; it is not calculating SOA values or transfer attempts independently. If BIND determines a zone is stale or expired, it will not serve the zone, and the account control center reflects this by disabling the zone.
Error: "CNAME and other data"
In DNS, CNAME records must be unique. If you mix a CNAME with other record types (such as A, MX, etc.) BIND will return the "CNAME and other data" error and refuse to load the zone due to errors. Fix the zone on the master.
Automatic Secondary Zone Deactivation
There are some conditions which will automatically disable a Secondary DNS zone:
• If the zone expires and becomes stale. A stale zone is one where the "expire" time in the SOA has passed and the master could not be contacted for a refresh. A stale zone will not be served by BIND anyway, so we disable it to reduce dead zone overhead.
• If the master sends rcode REFUSED in response to a transfer attempt or if the master refuses the connection with an ICMP response (active responses, not unreachable or timeouts). Our system must assume that if the master has been configured to refuse our requests that we must not try to be a secondary, and it wastes resources to keep trying.
• If the master sends rcode NOTAUTH in response to a transfer attempt. Our system must assume that if the master is not authoritative for a zone that we must not try to be a secondary, and it wastes resources to keep trying.
• If a host name master is entered (instead of an IPv4 or IPv6 address) and it is unresolvable. Host names can't define a master so it's translated to an IP to build the config for BIND. For this reason we do not recommend using a host name to define a master.
These conditions will be logged. The advanced option Email Alert on Disable will send a message to the alert email address configured for your account if a zone is automatically disabled.
Separation of Authoritative and Resolving Nameservers
For security purposes - such as preventing DNS cache poisoning - Roller Network operates four physically and operationally distinct DNS server groups: Primary DNS (including Dynamic DNS), Secondary DNS, internal authoritative servers for our own domains, and our internal caching resolver pool that services such as the mail servers use for lookups. Changes made on one of our DNS services will not propagate to the resolver pool even though it's hosted with us: the same normal DNS lookup path that would occur for external lookups is enforced internally.
Separation of authoritative DNS services and caching resolvers is an extremely common best practice for any respectable service provider. Roller Network does not override TTL values on our caching resolvers, so if you require better propagation time for your DNS updates (such as for Dynamic DNS) lower your TTL values.
Please be aware that lowering TTL values can dramatically reduce reliability for some services. For example, mail delivered to a host name target in SMTP Redirection that returns a successful "failure" result (NXDOMAIN) will result in loss of the message to an undeliverable destination. For reliable delivery to dynamic DNS destinations try our IP Address Helper service.