account control center

Roller Network Help - Primary DNS

Primary DNS Service

The Roller Network offers a comprehensive and flexible Primary DNS service which has the ability to serve all common record types with additional 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.

Authoritative Server List

Zones under Primary DNS are served authoritatively from the following DNS servers:

Our Primary DNS service is also IPv6 enabled.

Adding a New Zone

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.

Configuring a Zone

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 from the default disabled state the system will generate one active Key Signing Key (KSK) and two Zone Signing Keys (ZSK) one active and one inactive. 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. This is typically done by adding them through the registrar for your domain. 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 DNSSEC for your zone use one of the following tools:

Key Sizing

The recommend sizes are 2048 for KSK and 1024 for ZSK. 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. The ECC-GOST algorithm is 256 bits only.

Larger keys also require more CPU time to generate the cryptographic signatures. Roller Network reserves the right to disable or regenerate needlessly large keys for busy zones that negatively impact performance. Please use the default recommended sizes whenever possible.

Key Maintenance

Current security practices for DNSSEC recommend that the zone's KSK and ZSKs 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 supported for completeness, but not recommended:

Operational Mode

At this time we are only supporting NSEC mode. We expect to add NSEC3 support in the future.

Dynamic DNS

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. (See the other sections of this help page for more information. We are planning on adding generic domains soon!)

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.

Record Type Support

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.

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.

SPF

This is the official DNS record for SPF data. Although SPF borrowed the TXT record for rapid deployment it has an official DNS type. SPF records should be published in conjunction with a TXT-SPF record and they must be identical. This type was originally defined in RFC 4408.

TXT

The TXT (text) record is used to add any kind of free-form comment to as a DNS record. There is no special content format. The TXT record is commonly used for SPF and DKIM. If you are publishing an SPF record in TXT we recommend adding an identical SPF record (see above).

Extended Record Support

In addition to common record types, Roller Network also supports these specialized record types, some of which are not commonly used.

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.

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.

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.

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.

Zone Transfers (AXFR)

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 currently send NOTIFY on changes; this will be addressed in a future update.

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.

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; };
};

Wildcard Entries

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.

Home | Account Control Center | Status | Help | Contact | Policy | IPv6

© Roller Network LLC