Your IP address could not be determined at this time.

DNS and DNSSEC

table of COntents

Domain Names

When you look up a person or company in a phone book, you will find the number assigned to that person or company. When you call someone you ask for him or her by name, but the phone system relies on the number to make the connection. The relationship between a domain name and an IP address is quite similar. Domain names are human-friendly identifiers (names) that are paired with the computer-friendly IP addresses (numbers). Domain names allow users to find a specific domain or object on the Internet, and direct their Internet-capable devices to it.  Much like domain names and IP addresses, phone numbers and names are generated and managed in an organized manner using the Domain Name System.

Domain Name System (DNS)

The Domain Name System (DNS) is the hierarchical naming system for all resources connected to the Internet or a private network, including websites, mail servers and application servers. For instance, the domain name www.example.com translates to the addresses 192.0.32.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). Both identify the same website, but www.example.com is easier for a person to remember and use.

Much like Countries, States, and Counties, DNS zones are organized in a hierarchy so that a chain of authority can be determined within each zone. Each zone represents an area that is administered independently, and consists of a contiguous segment of the DNS name tree.
Domain names are categorized hierarchically within DNS servers, or nameservers. When you access a web site or send an email, your device uses a nameserver to look up that particular domain name. This process is formally referred to as DNS name resolution.  This process prevents users from having to remember the IP address of every web site they wish to visit. Nameservers exist for each domain, preventing the need for a single location or server to be in charge of any and all DNS information and any changes made to it.

Reverse DNS

Reverse DNS, or reverse resolution, is a system that provides a name when a user or device initially provides an IP address.

Reverse DNS is also used functions such as:

  • Network troubleshooting and testing
  • Checking domain names for suspicious information, such as overly generic reverse DNS names, dialup users or dynamically-assigned addresses in an attempt to limit email spam
  • Screening spam/phishing groups who forge domain information
  • Data logging and analysis within web servers

The reverse DNS database is rooted under two specific domains: in.addr.arpa for IPv4, and ipv6.arpa for IPv6. Each IP address associated with a domain has a record within at least one of these domains, known as a pointer (PTR) record. ARIN requires organizations to maintain their PTR records for associated networks in order to keep reverse DNS running smoothly.

DNS Zones

The DNS structure is hierarchically divided into segments called zones. Each DNS zone is responsible for a variety of tasks, such as defining that zone’s naming hierarchy and registration procedures, and operating DNS servers to store that naming hierarchy. DNS zones may be separated by locality, organization, department, or by specific individuals registered to use a domain or sub-domain.

With each subdivision of a DNS zone, the “child” zones must contain records that provide referral information to other DNS servers, so that users querying the DNS can find the domain(s) within that zone. These records are called Nameserver (NS) records. In order for delegations to function properly, every parent zone must contain NS records for each of its child zones.

Resource Records

There are many types of records within the DNS that specify information about a given resource. These records might contain the resource’s IP address, nameserver information, geographic location, etc. Click here for a list of all DNS record types.

DNSSEC

While DNS is invaluable to the Internet community, it is not without vulnerability. Internet criminals are capable of creating false DNS records, which may trick users into visiting websites or downloading malicious software. DNS Security (DNSSEC) protects the Internet from these kinds of attacks using public-key cryptography. This ability allows user to validate that the DNS records they receive came from the correct source. DNSSEC is enabled with the addition of the following DNS record types:

  • RRSIG: Resource Record Signature: This record is provided by a DNS server whenever the DNS receives a query from a DNS resolver (the program responsible for initiating and sequencing DNS queries) for information about a particular resource.
  • DNSKEY: DNS Key: This record contains the cryptographic keys used to sign zone file records (records describing the contents and structure of a DNS zone).  DNSSEC involves using DNSKEY records to cryptographically verify RRSIG records and ensure that outgoing Internet traffic is always sent to the correct place.
  • DS: Delegation Signer: This record indicates that a certain child zone is digitally signed and that the key used to sign that zone’s Resource Record set is recognized as valid.  These records are crucial to the chain of trust model DNSSEC is designed for. Each parent domain’s DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down.
  • NSEC: Next Secure: This record’s sole purpose is to prove that no records exist between two other records, preventing malicious parties from inserting false records into a DNSSEC-protected zone.

DNSSEC Deployment

DNSSEC deployment is complex, and there are a variety of deployment strategies available depending on your organization’s objectives. General DNSSEC deployment models include:

  • Do it yourself: As the name implies, this method consists of your organization finding the scripts, tools and software required to DNSSEC-enable your zone(s), configure them properly so that they work for your environment. This method has a higher learning curve and research requirement, but is more easily audited if you keep records of what you do.
  • Hosted solutions: Many organizations offer DNSSEC deployment and management services for organizations that may not have sufficient manpower or training to do so in-house. This option eliminates the high learning curve, but may cost more.
  • Automated: Some organizations may want to secure their DNS zones, but not have the time or manpower to take on a manual deployment of DNSSEC. . There are automated DNSSEC deployment/maintenance products available that will handle secure key signing and re-signing, key rollover, and will allow online dynamic content and automatic record keeping.

Which deployment method will work best for your organization? Consider the following:

Does your organization have:

    • The expertise and training to properly enable DNSSEC
    • The manpower and resources to deploy and maintain DNSSEC going forward
    • The rigorous process discipline to keep DNSSEC working
  • What level of security your organization wants and is prepared to implement
  • The number and size of zones your organization manages and how often they change
  • Whether your organization needs detailed logs and records for the resources you use for potential auditing purposes

Assess your needs against the questions listed above to get a better idea of which method best suits your organization.

Reverse DNS and DNSSEC Management at ARIN

ARIN provides delegation management tools to individually manage reverse DNS within IPv4 and IPv6 networks once your zones are DNSSEC-enabled. ARIN members may choose to DNSSEC-enable their reverse zones by submitting Delegation Signer (DS) Records to ARIN. These DS records point to DNSKEY Resource Records that are held in the zone being maintained.

Reverse DNS and DNSSEC can be managed within ARIN Online. You can also programmatically manage reverse DNS using ARIN’s RESTful provisioning system (Reg-RWS).

     Note: Before using Reg-RWS for this purpose, you will need an ARIN Online account with an API Key.

Using Your ARIN Online Account

ARIN recommends viewing the ARIN Online Delegation Management Presentation before getting started.

To modify delegations via ARIN Online:

  • Log into ARIN Online
  • Select on MANAGE RESOURCES in the left-hand menu
  • Select the POC or Org ID associated with the network registration record you wish to update
  • Select the desired network and click the Manage Reverse DNS icon in the toolbar on the right
    • The resulting screen will show all of the reverse DNS zones that you have permission to modify, any nameservers delegated to that zone, any registered Delegation Signer (DS) resource record key tags, and the names of any customers with shared authority over a zone
  • Select the zone or zones you wish to change and click the Modify Nameservers or the Modify DS Records button at the bottom of the page
  • Add or remove nameservers/DS Records and select Apply to All
    • These changes will be applied to all the selected zones. Your changes will take effect in the DNS within 24 hours

Note: If the nameservers for the selected delegations differ, they will not display on the listing page and you will receive a warning message. If you choose to add nameservers, those changes made will be applied to all of the selected zones and all previously listed nameservers will be deleted. The same applies to DS record changes.

Byte & Nibble Boundaries

Reverse DNS can be managed in IPv4 on byte boundaries (/8, /16 or /24’s), and IPv6 networks can be managed on nibble boundaries (every 4 bits of the IPv6 address). For example in IPv4, you could have a /23 network registered with ARIN that is comprised of two /24 delegations. In this case, you are able to delegate one set of nameservers to the first delegation and another set of nameservers to the second delegation.

Shared Authority

When ARIN-issued IP address space is reassigned by an organization to their customer, both parties may manage DNS for that space via Shared Whois Project (SWIP). Organizations with authority over a delegation are listed in the Authorized Organizations column.

Note: If your organization’s customers are disconnected from you, it is imperative that you protect your records by promptly removing any SWIPs to them, thus severing their shared authority rights for your reverse zones.