Internet Performance Delivered right to your inbox

Dyn Releases Dynect 4.1 And API 3.0, Adds New Features

“You want to do what? And you’re doing it at the DNS Layer? That’s wicked cool.”

Our customers are using the DNS in some rather unique ways to solve a myriad of business cases. We just love hearing about the next great thing coming down the pike and providing the Infrastructure they need to support their business plan.

We’re often adding features and functionality to the Dynect Platform based on customer requests. Some of these are pretty significant and easily observed, while others are easily missed if you aren’t looking for them.

Dynect 4.1

– This week, we added six new Resource Record types. Two were direct requests from customers in support of their business model and others we added were because we’ve received a few inquiries. There are now 20 different DNS Record types that can be added and maintained in both the Management portal and through the SOAP or REST API. (There’s a handful more coming in the next couple of weeks).

There are over 60 types of Resource Records (RRs) defined by RFC. A good number of the most commonly used are defined right in RFC 1035 (A, NS, MX, TXT, SOA). Others are somewhat obscure, serving very specific purposes and are defined in later RFCs. Four years ago when we first launched the Dynect Platform, we provided support for 11 RR Types with a data and interface architecture to support growing that out as needed.

In the next four years, we added three more record types. Two new record types for DNSSEC (DS and DNSKEY) and one experimental RR Type we added at customer request. The records we support served us and our customers quite well for the past few years.

– When I was asked a couple of weeks ago by our business development team if we supported SSHFP RRs, I knew two things:

  1. No, we didn’t.
  2. I would need to read RFC 4255 in order to determine if SSH Key Fingerprint records fit into our existing framework.

Turns out this is a handy DNS record type, allowing domain owners to publish SSH Key Fingerprints in a DNSSEC signed zone, using the DNS as the secure delivery mechanism and out-of-band verification of the fingerprint.

This was a no-brainer for support in the Dynect Platform as we already provide our customers with a secure method of updating their zone data, and we support DNSSEC signing of zones.

– Ok, show of hands: how many of you knew you could use the DNS in the SSH Key verification chain of trust? (Not all of us can be like Tom and keep the DNS in our minds.)

Another handy RR type we were requested to support is the DHCID for encoding Dynamic Host Configuration Protocol information in the DNS.

Sometimes even when using DHCP to assign IPs to a host, you want to keep the IP assignment static for a particular host. There are plenty of homegrown approaches to making this happen in a local network. Inevitably conflicts occur.

The DHCID provides a way to store DHCP client identifiers in the DNS to eliminate potential hostname conflicts within a zone. The data in a DHCID is a hashed representation of a unique identifier and the fully qualified domain name of the host. By pairing an IPv4 or IPv6 Address record in DNS with a DHCID record, site administrators can set strict policies on which DHCP client has rights to update the DNS for that host name.

DNAME (DNS Name Redirection) is a resource record which allows aliasing of a delegated zone. This type of record is very handy in the event of a site rename where you can point “original-site.com” to “our-new-site.com” and all of the hosts of “original-site.com” will now resolve to the domain “our-new-site.com”.

I can imagine using this RR type to clone domains or address typo corrections. RFC 2672 which describes the DNAME RR type has a clear set of expected behaviors for servers with regard to DNAME and wildcard (‘*’) record responses and how resolvers should cache DNAME information. We recommend a thorough reading of the RFC if you want to experiment with this record type.

The experimental resource record for authorizing a domain in email Sender Policy Framework (SPF) was added to the Dynect Platform at the request of customers. While the SPF record type itself is experimental, the purpose it serves has been filled by entering standardized SPF information in a TXT record.

The SPF record declares what hosts are (or are not) authorized to send mail for a particular domain name. According to RFC 4408, an SPF-compliant domain must publish SPF records. These can be of type TXT or type SPF. To be fully compliant and ensure compatibility with resolvers that do not yet support the SPF RR type, domains should publish SPF data using both record types.

Two other records added are:

  • NSAP records for mapping NSAP to domain names through the use of PTR records. Having this information in the DNS is useful for OSI networking and debugging CLNP connectivity
  • PX records allow distributing information for MIXER compliant email gateways name mapping for X.400 and RFC822 mail.

We added these two record type on a whim, because we could. Now we’re anxious to hear how you might use these to bring about the next game changing business model.

API 3.0

In addition, we’ve made some changes to our API — perfect for Integration Month here at Dyn!

Some highlights:

  • Ability to use the API to manage the new permissions made available with Dynect 4.0 a few weeks ago.
  • DNSSEC management via the API (ability to configure DNSSEC on your zones, do key rollovers, etc.)
  • The following DNS record types are now available on Dynect:
    – SSHFP
    – DHCID
    – NSAP
    – PX
    – DNAME
    – SPF
  • You can also forbid access to zones and nodes explicitly under a User’s Advanced Permissions.

What else do you want to see? Your feedback made these updates happen, so keep ’em coming and let us know what should be next?


Share Now