Thursday, January 13, 2011

Protect Your DNS Cache Without Signing a Zone....But be a Good "Netizen"

While DNSSEC technology has been specified for over a decade (though the standard was revamped about six years ago), it gained little true interest until mid-2008. With the announcement of the so-called Kaminsky vulnerability in July, 2008, momentum for DNSSEC began building and is accelerating into this year. Here's a great article describing this vulnerability in detail. The vulnerability can lead to cache poisoning of a name server performing lookups on behalf of DNS clients or stub resolvers.

This name server, commonly referred to as a recursive name server, accepts recursive queries from resolver clients, and issues successive queries down the domain tree to locate the source of the queried information. Once received, the answer is cached so should another resolver request the same information, the recursive name server simply returns the cached resolution data, saving time and reducing needless resolution traffic. Thus recursive servers are also referred to as caching names servers.

By forcing the recursive name server to perform a lookup such that malicious data is stored in its cache, an attacker may direct clients requesting legitimate and popular websites to a fraudulent site. Consider some popular websites and how many of your users access them during the day and it's easy to see how quickly this defrauded cached data can spread. And given the Kaminsky vulnerability, which is a DNS protocol vulnerability, not that of a particular DNS vendor, makes this cache poisoning attack easier, how should you protect your cache? While the patches that many vendors supplied coincident with and soon after the vulnerability announcement helped mitigate the vulnerability, the only surefire solution is the use of DNSSEC.

If zone administrators managing name resolution for these popular websites sign their zone data with DNSSEC, and your recursive servers can be configured to "trust" them, then any fraudulent response will be identifiable and therefore prevented from entering the name server cache. To protect your recursive server caches, you must configure this trust information (trust anchors) such that signed resolutions can be deemed trustworthy or not. Both of the most popular enterprise DNS server reference implementations, namely from the Internet Systems Consortium (ISC) and Microsoft Corporation support the declaration of one or more trust anchors within recursive server configurations.

And with the root zone being signed and most major top level domains (TLDs) being signed or soon to be signed, the root zone trust anchor is all that needs to be configured. Just as name resolution works from the root zone down to the authoritative zone, trust anchor validation works up to the root zone in a chain of trust.

So while the first part of the headline of this post states that you can protect your own caches in this manner by configuring trust anchor(s) and querying other servers' signed information, the second part encourages you to consider signing your own publicly reachable zone data as well. This assures that would-be attackers will be unable to impersonate your zone information for secure resolutions, maintaining your DNS information integrity. It also supports Internet "civility" which has become a hot term in public circles but has been a true hallmark of Internet designers and implementers ("netizens") from the beginnings of the Internet. Let's keep it that way!

Monday, January 10, 2011

IPAM Requirements Driven by IPAM Responsibilities - Yours or Your Organization's?

The first part of the title of this post is plainly obvious - your requirements for anything are going to be driven by what you need to get done and manage. But in the broader scheme of things, meeting your individual requirements may make your daily work easier, but will it provide the full breadth of benefits for your organization beyond making one person's or team's work more efficient?

Certainly garnering efficiencies anywhere is usually a good thing. But if you're going to invest in making a particular task easier, doesn't it make sense to examine other related savings opportunities that can be gained through perhaps a smaller (proportionally) incremental investment. For example if you're a DNS administrator, procuring a set of dedicated DNS servers, perhaps a DNS GUI for easier data entry, or even a DNS hosting service, may make life easier for you. But is this benefit of this "ease" provide the maximum return on the investment in one or more of these solutions?

One way to assess this is to consider how you interact with other members of your organization to accomplish your work. If you're managing internal DNS servers for all or a portion of your organization, you probably receive requests for new resource records for newly deployed devices and/or services or reverse domains for new subnets (e.g., new branch office or store openings).

Consider how these requests and your results are communicated and whether your proposed solution can streamline these communications. Many organizations communicate such requests through email or phone calls. Imagine a solution where other users can log requests, you review and adjust or approve them, you enact the change, then you communicate results to requestors without necessarily having to email back and forth. Such automation can save time and reduce mistakes otherwise possible with the transposition of information from an email to your DNS GUI. Your job will be easier and these other users will likely appreciate the faster and more accurate service you provide. And we could all do with a little less email!

Automating otherwise manual communication methods is one of the major benefits of investing in an IPAM solution. The larger the number of requestors and members of your team, the larger the potential error reduction and time and money savings that can generally be realized. Of course getting all of those affected by such a change in process need to be brought on board (by edict or consensus) but the benefits can be substantial.

Selecting a solution that provides an incremental growth path may be the way to go to start small with an extend-able solution (at least making your job easier!), make incremental deployments, and identify savings to feed subsequent broader deployments.

Saturday, January 8, 2011

IPAM and New gTLDs

Thanks to a comment on my prior post predicting 2011 as the year of IPAM due to the emergence of IPv6 and DNSSEC, a third IPAM-impacting event is expected to begin this year which will affect IPAM planners perhaps not in 2011 but certainly in future years: new gTLDs. Generic Top Level Domains, gTLDs, are those domain labels directly beneath the root in the domain tree. Country Code TLDs, ccTLDs, are two letter country code domain names directly beneath the root which map to those country codes maintained by the ISO 3166 Maintenance Agency. There are about 250 ccTLDs and examples include .us (US), .ca (Canada), .eu (European Union), .jp (Japan), etc.

Eight gTLDs existed prior to the formation of ICANN (Internet Corporation for Assigned Names and Numbers) which is now responsible for these domain assignments: .com, .edu, .net, .gov, .int, .mil, .org, and .arpa. ICANN accepted seven gTLD applications during 2000 (.aero, .biz, .coop, .info, .museum, .name and .pro) and six during 2004 (.asia, .cat, .jobs, .mobi, .tel, .travel).

An exciting addition to the 2011 round of gTLD applications is the support of internationalized domain names (IDN). IDN gTLDs will enable representation of fully qualified domain names using native or international characters; today only second level domains, domains below gTLDs, may use IDN. Because resource record information is stored and communicated using ASCII characters, IDN defines an algorithm for mapping international character sets, generally represented as unicode characters into DNS-compliant ASCII characters.

Thus users throughout the world will be able to send emails or browse websites typing fully native language character domain names with IDN gTLDs. Of course applicants for native language gTLDs must successfully complete the selection process. The application process for new gTLDs is expected to open this spring.

Beyond the convenience of accessing websites using native language, new gTLDs may ultimately affect organizations that perceive no inherent need to support IDN. Given our shrinking world and the general desire to provide global Internet access, supporting IDN domain names may ultimately become a competitive advantage. Not an immediate concern, but the new gTLD application and award process is certainly something to keep an eye on this year.

Tuesday, January 4, 2011

IPAM in the Cloud Offerings a Bit Cloudy

If you're in need of help in managing your day-to-day IPAM functions, there is certainly a variety of solutions available. But which one is right for you? Many offerings can help offload your IT team from having to manage your public or external DNS servers and name spaces. Many service providers provide secondary DNS hosting, enabling (and requiring) you to manage your zone and resource record information on your own external master DNS server, then update the service provider's secondary DNS servers via standard zone transfers.
Some service providers can also host the master server, allowing a small number of changes over a given time frame. The simplest solution albeit with limited control offered by website hosting providers integrate domain name assignment and operation of master and slave DNS servers accordingly.
Beyond these various external DNS support services, fewer offerings are available for helping to manage internal DNS as well as DHCP and IP address space administration. These technologies are at the same time very complex and crucial to proper network operation for end users. The first question after all should be whether you even want to trust administration of this critical infrastructure to a third party. Should a misconfiguration occur or a server fail, does the service provider apply sufficient redundancy and resources to quickly rectify the issue? Only a trustworthy organization with resources that can be brought to bear would be worth considering.
But if managing (or mis-managing) IPAM is creating issues in your network, stirring end user dissatisfaction, or is too time and resource-intensive, a managed IPAM service may be worth seeking. Whether you prefer additional hands on deck with professional services support or a true IPAM-in-the-cloud service, BT Diamond IP is a professional, competent and trustworthy IPAM services partner. Of course BT Diamond IP also offers software and appliance products if you prefer to purchase and manage IPAM in-house!

Saturday, January 1, 2011

2011 Promises to be the Year of IPAM

Two major Internet industry events will occur in 2011 that will shape the future of Internet communications and potentially increase the technical scope of IP managers:
  • Top level IPv4 address space exhaustion
  • Top-level domain (TLD) zone signing
With only seven /8 blocks left in IANA's pool of address space, IANA is expected to run out of the IPv4 address space it is able to allocate to RIRs during the first quarter of 2011.This exhaustion will be hastened by the ICANN policy to allocate one /8 automatically to each of the five RIRs when any excess space has been allocated; that is after the next two /8 blocks are allocated, the remaining five will automatically be allocated to each RIR. As discussed in a prior post, this exhaustion of the top of the IP address space food chain will ultimately impact organizations.

The signing particularly of the .com TLD will enable commercial organizations to greatly simplify the configuration of DNS security (DNSSEC). With the root zones having been signed since July, 2010, the signing of .com will enable commercial organizations beneath the .com zone to sign their zones with an unbroken chain of trust from their respective zones up to .com and finally to the root zone. Thus when you configure your DNS caching servers to authenticate DNS information via DNSSEC, you'll only need to configure the root zone public key as trusted-keys (technically as managed-keys within your BIND configuration so root zone key changes can be updated automatically).

Without this chain of trust you'd have to configure each signed zones' keys as trusted, vastly increasing DNS caching server configuration and administration.So TLD signing will simplify caching server configuration, but you'll still need to configure and manage the keys and signing of your external authoritative zones. Nevertheless, the road to wide-scale DNSSEC implementation will be vastly simplified when these TLDs are signed.

With time running out on the availability of IPv4 address space and the expected wider deployment of DNSSEC, 2011 will be the year to learn more about and begin making plans for IPv6 and DNSSEC deployment. Of course, you'll need to continue managing your current IP address space and DNS zones, signed and unsigned. Implementation of an IPAM solution can help keep IPv4, IPv6 and signed and unsigned DNS zone information organized and processes disciplined.