Roller Network Help - Primary DNS
Primary DNS Service
Our flexible Primary DNS service supports all common record types plus some uncommon and possibly obscure record types. To use our Primary DNS service add our authoritative servers (shown below) to the name server list at your domian's registrar.
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. Primary DNS supports secure TSIG zone transfers for additional providers to load data for your zone using AXFR/IXFR.
In the event of DDoS attacks targeted at a Primary DNS zone, Roller Network will rate limit or block queries to that domain.
Zones under Primary DNS are served authoritatively from the following DNS servers:
Our Primary DNS service is also IPv6 enabled.
Click on the "Add New Zone" tab, enter your zone name, and select a template. After the zone is added you will be taken directly to the detailed configuration page where you may add, remove, or modify DNS records as desired.
To view and change the configuration details for a zone, click on the "Configure" button (wrench icon) next to the zone name under the DNS Zones tab. A summary of current resource records are shown under the Records tab. In configure mode you can add new records, modify existing records, and delete records.
Changes take effect on our DNS servers immediately. Our default TTL (caching) value is one day, or 86400 seconds. The TTL may be modified to be as low as 60 seconds. Please be aware that while changes in our Primary DNS service take effect immediately old data may be cached (based on the TTL) by caching resolvers. Common practice is to lower the TTL before you know you're going to make a change and then raise it back to normal after the change.
To add records to a zone click on the "Add Record" tab in configure mode. Choose the record type you wish to add from the select drop-down and click "Add". For a detailed explanation on each record type see the "Common Record Types" and "Other Record Types" sections below.
Other per-zone configurations settings are the SOA, Zone Transfer (AXFR) Permissions, and Domain Name System Security (DNSSEC) Extensions. These can be configured under their corresponding tabs.
Domain Name System Security Extensions
Domain Name System Security Extensions (DNSSEC) allow for digitally signing records in a Primary DNS zone. This feature is managed under the "DNSSEC" tab or by clicking on the lock icon from the DNZ zone overview page. Our DNSSEC implementation operates in "live signing" mode, which means that private keys are stored online in a keystore and DNS records are signed on request. These signatures, as served through RRSIG records, are calculated on the fly and heavily cached. RRSIGs have a validity period of at most a week in the past and at least a week into the future.
When enabling DNSSEC for a zone the system will generate a Common Signing Key (KSK) with ECDSA P-256. The DS and DNSKEY records will be displayed. To complete the chain of trust the Delegation Signer (DS) records will need to be added upstream at your registrar. Once the DS records have been added your zone will be secured with DNSSEC.
If DNSSEC is disabled all private keying material is permanently deleted. There are no recovery options.
Testing DNSSEC
To test your zone use the following tools:
Key Sizing
The recommend algorithm is ECDSA P-256 with SHA256 with a Common Signing Key (CSK). Bits setting is not used with ECDSA. These use fixed bit sizes.
Older configurations may use RSA/SHA-256 with 2048 bits for KSK and 1024 bits for ZSK if your registrar does not suport ECDSA. Larger keys will increase the sizes of the RRSIG and DNSKEY records and will therefore increase the chance of DNS UDP packet overflow. This can be an issue with older firewalls or security practices that incorrectly assume UDP-only for DNS queries.
Larger keys may require more CPU time to generate cryptographic signatures. Roller Network reserves the right to disable needlessly large RSA keys for busy zones that negatively impact performance. Please use the ECDSA algorithm whenever possible.
Key Maintenance
Current security practices for DNSSEC recommend that the zone's keys should be periodically rotated or rolled over. At this time we do not have an automatic key rollover utility, so rollover tasks should be scheduled as appropriate for your zone. Common maintenance tasks include:
Supported Algorithms
The following algorithms are supported:
These algorithms are available for completeness, but no longer supported:
Operational Mode
DNSSEC operated in NSEC with live signing mode.
DNS Update (RFC2136) enables clients and servers to register DNS domain names and IP address mappings on any DNS server supporting RFC2136 style updates. This method is supported on Roller Network Primary DNS with IP and TSIG access lists.
DNS Update access lists are configured per-zone. From the main "DNS Zones" tab, click on "Configure" for the zone name, then go to the "DNS Update" tab in that zone.
Clients or servers must be configured to send DNS Update requests to the following server:
Access Control by IP
Access control by IP address is enabled by adding an IPv4 or IPv6 CIDR formatted address in the IP Address ACL field.
An IP Address ACL is always required, even when using a TSIG key. After at least one TSIG Key ACL is added to a zone, all IP-only update requests will be rejected unless they are also signed by the configured TSIG key.
Access Control by TSIG Key
Access control by TSIG key is enabled by adding a selected TSIG Key Name in addition to an IP Address ACL.
For dynamic IP applications where TSIG will be used to update dynamic DNS names, add an IP Address ACL with a value of 0.0.0.0/0 to allow an update from any IP address together with one or more TSIG Key ACL entries.
Warning: you must add at least one TSIG Key ACL if your IP Address ACL is set to 0.0.0.0/0, otherwise updates will be accepted from any client and your zone will be compromised.
This is a depreciated proprietary API. Please use the DNS Update (RFC2136) standard where supported.
Dynamic DNS behaves exactly like Primary DNS, except you can configure clients to update DNS record on demand. A client may update one record or all records for a zone. There are no limitations for Dynamic DNS clients. For security purposes, our Dynamic DNS clients use a separate client name and client key. This way, you don't have to expose your main account password.
To start using Dynamic DNS with your Roller Network account, you must have an existing zone configured.
To add a new Dynamic DNS client, click on the "Add Dynamic DNS" button. Choose the domain this client will be updating, enter a client user name and a client key (password). If you want to limit what data this client can update, enter the "limit update name". Normally, a client is allowed to update any IP address in a domain name it is configured for. By entering a limit name, the client will only be allowed to update that single IP address. For example, if the domain name "example.com" were chosen and you entered a limit name of "myhome", then the client would only update the IP address for "myhome.example.com".
Dynamic DNS Client Details
Our Dynamic DNS client is called by HTTP or HTTPS. Variables may be sent in a GET or POST request and the client/key may be sent using HTTP basic authentication.
Client URL: http://acc.rollernet.us/dns/dynamic.php
| Variable | Description | Example | Notes |
|---|---|---|---|
| client | Client login name | client=exampleclient | Not needed for HTTP authentication |
| key | Client login key | key=examplekey | Not needed for HTTP authentication |
| domain | DNS domain name | domain=example.com | Always required |
Important: the default action is to update all IP address for the domain. If you only want to update one name you must include the optional name variable in the request as described below. If the client has a limit name configured in the account control center, then the update will be limited to that name.
This example will update IP addresses based on the client's connecting IP address for the domain "example.com":
http://acc.rollernet.us/dns/dynamic.php?client=exampleclient&key=examplekey&domain=example.com |
HTTP Basic Authentication
You may also use HTTP Basic Authentication instead of passing the client user and key in a variable with the request. When using authentication only the domain needs to be in the request. Example using wget on Linux with SSL:
wget -q --http-user=exampleclient --http-password=examplekey -O - 'https://acc.rollernet.us/dns/dynamic.php?domain=example.com' |
Optional Variables and Advanced Options
| Variable | Description | Example |
|---|---|---|
| name | Limit DNS subdomain to update. | name=subdomain |
| ip | Manually specify IPv4 address. | ip=198.51.100.1 |
| ip6 | Manually specify IPv6 address. | ip6=2001:0DB8:107::9 |
| allow1918 | Allow RFC1918 IPv4 addresses. | allow1918 |
These variables let you fine-tune the behavior of the Dynamic DNS client. The name variable will restrict the update to a single IP address, rather than the default behavior of all IP addresses for a domain. (If the client is name limited in the control center, this option will be ignored.) For example, to only update the IP address for "www.example.com":
http://acc.rollernet.us/dns/dynamic.php?client=exampleclient&key=examplekey&domain=example.com&name=www |
There's also a special case for the name variable to only update "example.com" without a leading subdomain: send the name variable but leave it blank.
http://acc.rollernet.us/dns/dynamic.php?client=exampleclient&key=examplekey&domain=example.com&name= |
If you want to set the IP address yourself for any reason rather than the default behavior of trying to determine it automatically by looking at the requesting IP address, specify the ip or ip6 variable:
http://acc.rollernet.us/dns/dynamic.php?client=exampleclient&key=examplekey&domain=example.com&ip=198.51.100.1 http://acc.rollernet.us/dns/dynamic.php?client=exampleclient&key=examplekey&domain=example.com&ip6=2001:0DB8:107::9 |
You can combine optional variables to devise complex Dynamic DNS schemes. Linux users can use curl or wget to call the Dynamic DNS client directly as shown in these examples in pre-up/post-up, pre-down/post-down scripts or as part of a script in PPP's ip-down.d or ip-up.d directories.
The client will return ERROR: xxxxx or OK: 198.51.100.1 in response to a request. For ERROR, a plain text string will be returned describing the error. For OK the IP address that was set will be returned.
Dynamic DNS IPv6 Support
The Roller Network Dynamic DNS service includes IPv6 support. There are two ways we've considered handling IPv4-only, IPv6-only and dual IPv4/IPv6 updates:
An IPv4 only host can rely on the IP the request originated from, but a dual-stack host will default to IPv6. This doesn't help if you want to update the IPv4 address (or both), so this is how we decided to resolve the issue. As of this writing we're the first to offer IPv6 Dynamic DNS, so if a better way of handling this presents itself in the future, we'll probably support that as well.
A and AAAA
The A and AAAA records are used to specify a name-to-address mapping. For standard IP addresses (like 198.51.100.1) use an A record. For IPv6 addresses (like 2001:db8::1) use the AAAA record.
CAA
The CAA record (Certification Authority Authorization) type is used to specify Certificate Authorities that may issue certificates for a domain. For more information see RFC 6844. Although it can be used without DNSSEC, CAA records should be secured with DNSSEC to establish the chain of trust.
CNAME
The CNAME (Canonical Name, meaning expected or real name) record is used to create an alias. For example, if you have the zone "example.com", you could create a CNAME to point "www.example.com" at "www.example.net" which eliminates the need to update DNS if the IP address for example.net ever changes. CNAME is also handy to create aliases for Dynamic DNS names. Warning: CNAME cannot be mixed with other record types, and can't exist at the base of a zone.
MX
The MX (main exchanger) record is used to specify the mail servers for a domain or subdomain. MX records also require a numeric priority value. Priority is indicated from lowest to highest, with the lowest number being the primary mail server. Multiple MX records may exist with the same priority value to indicate equal priority.
NS
The NS record is used to specify name servers for a zone. By default NS records for our authoritative name servers are in every Primary DNS zone. You may add additional name servers to delegate subdomains elsewhere or change the NS records for so-called "vanity" DNS purposes. In the case of vanity name servers it is the domain administrator's responsibility to ensure proper association with the real IP addresses of our authoritative name servers.
PTR
The PTR (pointer) record is the companion to A and AAA and is used in reverse zone files to specify address-to-name mapping.
TXT
The TXT (text) record is used to add any kind of free-form comment to as a DNS record. The TXT record is most often used for SPF, DKIM, and DMARC policies, plus many other uses.
In addition to the common DNS record types, Roller Network also supports these advanced DNS record types.
AFSDB
The AFSDB record is used to specify AFS Database locations. It requires a subtype and hostname. For more information see RFC 1183. The AFSDB record is used in special applications only. AFS is a registered trademark of Transarc Corporation.
HINFO
The HINFO record is used to add architecture and operating system information about a host - for example, "i386" and "FreeBSD".
LOC
The LOC record is used to express location information in DNS. For more information see RFC 1876.
NAPTR
The NAPTR record is used to specify a general purpose set of rules for an application such as VOIP and E164. It stands for "Naming Authority Pointer Record". For more information, see RFC 3403.
RP
The RP record is used to add Responsible Person information to DNS. For more information see RFC 1183.
SRV
The SRV record is used to define services available in a DNS zone or for protocol-specific records. It was originally defined in RFC 2782.
SSHFP
The SSHFP record type is used to store Secure Shell (SSH) fingerprints. SSHFP DNS records for a host can be generated with "ssh-keygen -r hostname". For more information see RFC 4255. Although it can be used without DNSSEC, SSHFP records should be secured with DNSSEC to establish the chain of trust.
TLSA
The TLSA record type is used to bind SSL/TLS certificates to named hosts and ports. For more information see RFC 6698. Although it can be used without DNSSEC, TLSA records should be secured with DNSSEC to establish the chain of trust.
Legacy record types are available for backwards compatibility only and may not be supported.
SPF (Not Supported)
SPF type records were proposed in RFC 4408 but discontinued in favor of only using TXT type records in RFC 7208 Section 3.1. Since this record type is no longer supported, there is no need to continue publishing SPF records and they can be removed. SPF type DNS records should not be added to new configurations: use the TXT type for your SPF policy.
Updating Multiple Records: Find & Replace
The Find & Replace tool for Primary DNS can be used to update matching record types for one or more zones. For any record that matches the specified type and content, any one or more of its content, TTL, or priority values may be updated. If a "replace with" field is left blank that value will not be changed.
To access this feature click on the Find & Replace tab on the Primary DNS page in the account control center. This feature is only available to accounts with a service level of Personal Plus or higher.
AXFR is supported for Primary DNS zones. By default zone transfers are not permitted. Access list entries to permit AXFR requests are managed through the "AXFR" tab under each zone. Roller Network Primary DNS supports several AXFR authorization methods: IPv4 ACL, IPv6 ACL, and TSIG Key. AXFR access is configured per-zone.
Consider using a TSIG key to simplify management instead of a large number of IP address based access list entries. When using TSIG any AXFR request that's authorized and authenticated by a TSIG key will be allowed, which can simplify access from multiple slave servers to that of a single TSIG key shared among the authorized slaves.
We do not send NOTIFY on changes.
Master Servers by IP Address
See the Server Information section for a list of Primary DNS servers by IP address. A master by IP address is commonly required in DNS slave server configurations.
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 and DNS Update (RFC2136) clients or servers.
When adding a TSIG key the name will be prefixed with your account control center login name. The shared secret should also be entered unencoded; when the key is added it will be converted to Base64 automatically. After adding a TSIG key it can be used for zone AXFR authorization by going to DNS Zones tab → Configure zone → AXFR tab.
To test TSIG AXFR use the "dig" command line tool: dig -y tsigname:tsigsecret AXFR example.com @ns1-auth.rollernet.us
TSIG Security Considerations
An AXFR request authorized and authenticated by a TSIG key will gain access to a zone even if the remote IP address is not otherwise allowed to AXFR the zone. IP address ACLs are not required (or used) with TSIG.
TSIG keys on slave servers should ideally be kept in a location that's only readable by the DNS server with secure permissions.
Using TSIG with a BIND9 Slave
Once a TSIG key is created and an AXFR TSIG ACL is added to a Primary DNS zone, the slave DNS server will need to be configured to use the shared secret TSIG key. The following example is for BIND9:
key mytsigkeyname {
algorithm hmac-md5;
secret "X";
};
zone "example.com" {
type slave;
masters {
208.79.240.10 key mytsigkeyname;
208.79.241.10 key mytsigkeyname;
2607:fe70:0:3::c key mytsigkeyname; // optional ipv6
2607:fe70:0:4::c key mytsigkeyname; // optional ipv6
};
file "/var/cache/bind/db.example.com";
};
Or you can use the "server" statement:
key "mytsigkey" {
algorithm hmac-md5;
secret "X";
};
server 208.79.240.10 {
keys { mytsigkeyname; };
};
server 208.79.241.10 {
keys { mytsigkeyname; };
};
server 2607:fe70:0:3::c {
keys { mytsigkeyname; };
};
server 2607:fe70:0:4::c {
keys { mytsigkeyname; };
};
Roller Network Primary DNS service does not support wildcard DNS entries. There are no plans to do so. If you require wildcards please use our Secondary DNS service with a master (stealth or otherwise) that you control.
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 authoritative services will not propagate to the resolver pool even though it's hosted with us; the same normal DNS lookup channels that would occur for DNS external to us are 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, 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 will drastically reduce cache stability. For example, mail delivered to a host name that returns a successful "failure" result (NXDOMAIN) will result in Postfix bouncing the message as an undeliverable destination. For reliable delivery to dynamic DNS destinations try our IP Address Helper service.