Thursday, December 22, 2011

Was 2011 the year for IPAM?

On January 1st this year, I had predicted 2011 as the "year of IPAM." Driving this prediction were the imminent exhaustion of IPv4 address space, which occurred at the IANA level in early February, 2011, as well as DNSSEC and internationalized domain names (IDNs). While I believe awareness and interest in IPv6 as vastly increased during 2011, I think we're only just beginning. Certainly more organizations are interested in IPv6 and many are actively assessing and planning for deployment, but this process will take another year or two before IPv6 really gains critical mass on the Internet. Then perhaps we'll see a tipping point of widescale IPv6 deployment.

Interest in DNSSEC deployment continues to increase albeit slowly. Unfortunately, nothing short of another Kaminsky-style attack may trigger the DNSSEC deployment tipping point as organizations continue to evaluate and watch given the relative complexity of DNSSEC administration. Much of the trepidation around DNSSEC deployment relates to not only the initial key generation and zone signing process, but to the ongoing burden of rolling over keys and resigning zones. BIND automates this to some degree as of course does BT Diamond IP's Sapphire Sx20 fully automates this process.

For IDNs, 2012 will certainly be an interesting year with impacts on DNS administrators likely beginning in early 2013. ICANN's new gTLD program opens for new gTLD applications on January 12, 2012 and continues through April 12, 2012. The likely outcome of this process is the establishment of several new gTLDs, many of them in "native language" thanks to the IDNA (internationalized domain names for applications) protocol. Organizations seeking to market to global regions represented within IDN gTLDs may seek to register domain names with corresponding registrars. DNS administrators of course will then need to properly configure IDNs in DNS, which requires IDNA translation from native language unicode into ASCII.

So was 2011 the year of IPAM? It seems to me that 2011 was just the beginning of a multi-year period of awareness and planning for revolutionary Internet technologies, stimulating increasing recognition that IPAM solutions will be instrumental in simplifying their deployment and management.

Wednesday, December 7, 2011

Join me in New York December 13 to talk IPv6

If you're in the New York area on December 13, I'll be speaking at Network World's Critical Path to IPv6 event at the Roosevelt Hotel. This free seminar will also feature Network World contributors, Jeff Doyle and Scott Hogg. This event promises to cover a number of IPv6 topics from a variety of perspectives though focusing primarily on preparation, getting started, addressing and implementation. I hope to see you there!

Friday, November 11, 2011

Could DNSSEC have protected against DNSChanger malware scam?

According to major media sites, a two-year FBI investigation has culminated in the arrest of six individuals involved in a DNSChanger malware scam. DNSChanger is downloaded under the guise of a video codec in many cases and is installed on an individual's computer. DNSChanger then modifies the recursive server settings from those provided by the individual's ISP to one administered by the attackers. As the individual browses the web entering URLs, the local resolver queries the attacker's DNS servers, which can return IP addresses leading to falsified sites unbeknownst to the individual.

This scam has reportedly led to the infection of over four million computers in over 100 countries and had netted the conspirators over $14 million. The FBI has published a very basic description of the issue and a listing of falsified DNS sever addresses.

So the question arises, could the widespread implementation of DNSSEC have prevented this type of attack? Unfortunately, in this case, no. The attack modified the client (stub) resolver, which inherently trusts its configured recursive server(s) to validate DNSSEC queries on its behalf. The manner in which DNSSEC commonly deployed with validation performed by the recursive server resolver, not the stub resolver, performing DNSSEC validation would not have prevented this. Once the stub resolver issues the query to the attacker's DNS recursive server under this attack, the attacker could have spoofed DNSSEC-validated responses to the client.

If the client stub resolver performed and required DNSSEC validation, and was configured with trusted root keys, it could have detected falsified zone information. Of course, if the DNSChanger was able to modify the resolver's recursive server address settings, it presumably could have modified the trusted key to point to an attacker's public key! So as advertised, DNSSEC helps prevent cache poisoning attacks, but it does not mitigate resolver configuration attacks, which require ongoing vigilance to detect and mitigate as with other malware and trojan horse style attacks.

Monday, October 31, 2011

IDNA security concerns

During my recent webinar of October 25th regarding IPv6 and internationalized domain names (IDNs), I promised to post a few links on my blog regarding security considerations when deploying IDNA. These security concerns stem primarily from homographs, where characters are visually identical but have in fact different unicode and therefore IDN representations.

The issue that may arise is that a link may appear "legitimate" or intended by a user but the IDNA-translated URL may result in a DNS lookup mapping to an attacker's DNS zone file which could result in phishing and similar attacks. This of course is not an issue unique to IDNA as it occurs on a daily basis within the Latin alphabetic representation in DNS. Attackers publish links that substitute "1" for "l" or "0" for "O", etc. or outright misspell otherwise familiar words or company names. But IDNA adds an additional layer of obscurity as homographs will be indistinguishable to the otherwise careful reader.

Here are some links on the topic for details:
If you'd like to view a replay of the webinar or any of those within the IPv6 webinar series, please navigate here and you will have access to all webinars within the series as they are completed and posted.

Monday, October 17, 2011

IPv6 webinar series - Session 1

Beginning next week, I'll be conducting a series of five webinars with the help of gotomeeting, focused on IPv6. Actually the first webinar in the series touches on IPv6 though it focuses primarily on IDNs, internationalized domain names. I decided to offer this IDN/IPv6 webinar as the first in the series since it introduces IPv6 and provides a context for IPv6 especially for IT managers in North America, namely to facilitate continued web presence for Asia users. IDN is another evolving IPAM-related technology that can ease the usability or navigation to your sites for Asia-based users among others. Following are the planned dates and topics for the IPv6 webinar series:

Webinar TopicDate and Time
IDNs and IPv6: Enhancing your Asia presenceTuesday, October 25, 2011, 12-1pm EDT
Introduction to IPv6Thursday, October 27, 2011, 12-1pm EDT
IPv6 deployment checklistTuesday, November 1, 2011, 12-1pm EDT
Configuring DNS for a dual stack networkThursday, November 3, 2011, 12-1pm EDT
DHCPv6: features and comparison with DHCPv4Tuesday, November 8, 2011, 12-1pm EST

The first webinar, IDNs and IPv6: Enhancing your Asia presence will discuss the following. The rate of broadband and wireless services deployments in the Eastern hemisphere far exceed those in the West. With this Internet access proliferation into broader, less technical segments of these populations, it behooves organizations to assure Internet reachability and simplify navigation to their web resources. This webinar will discuss how implementation of IPv6 and international domain names (IDNs) can help achieve these objectives. Register here.

For more information about the series and topics to be discussed in other webinars, I'll be blogging about that later, or you can see the short answer here.

Thursday, September 29, 2011

Speaking of filters - my segment of the BT Tower webcast

As a follow up to my post-live webcast blogpost, here is just my segment from the webcast where I talk about IPv6. Enjoy!

Handy AAAA filter in BIND 9.8

The ISC introduced a pair of new configuration file options in BIND 9.8 to enable administrators to easily filter who may receive AAAA record type responses even if valid responses exist. For example, clients on subnets that do not have IPv6 network access can be excluded from receiving affirmative answers for AAAA queries. This feature provides simpler administration than the alternative mechanism using views.

The first option, filter-aaaa-on-v4,defines whether the server will return AAAA records to certain clients. Such clients are defined by the address match list parameter of the second option, filter-aaaa. Note that BIND must be compiled with the --enable-filter-aaaa option on the configure command line to enable AAAA filtering. The syntax of these options is as follows:

  • filter-aaaa-on-v4 (yes | no | break-dnssec) ;
  • filter-aaaa {addr_match_list;} ;

The filter-aaaa option identifies the address match list for which the filter-aaaa-on-v4 option is to be applied as described next. Multiple filter-aaaa options may be defined. The default is any.

If the filter-aaaa-on-v4 option is set to yes, AAAA records are filtered out of (not included in) the response if the client falls within the filter-aaaa address match list and no DNSSEC signatures are included. If set to no, such filtering is not performed and AAAA records are returned. If set to break-dnssec, the AAAA records are filtered out even if DNSSEC signatures exist.

The filter-aaaa pair of options provides control at the DNS level to control distribution of AAAA responses; just remember to remove (unfilter) corresponding address match lists as you deploy IPv6 and enable IPv6 access!

Tuesday, September 20, 2011

Dual stack host default address selection

As many organizations ponder IPv6 deployment, the most popular approach will be dual-stack deployment according to a recent survey. This approach entails activating IPv4 and IPv6 address types and assigning corresponding addresses by defined means such as manual, DHCP or auto-configuration for a given device's interface(s). All major host operating systems (OSs) support IPv4 and IPv6 and in some cases auto-configure IPv6 addresses by default.

When an application seeks to communicate with a remote host given its hostname, the application calls the getaddrinfo() sockets API call. This API call triggers one or more DNS lookups (though other forms of name resolution could be used) with the query name set to the hostname passed in the getaddrinfo() call, the query class set to Internet and the query type set to A and AAAA on successive DNS queries. So given a host with both IPv4 and IPv6 interface addresses and destination host name resolution yielding both IPv4 and IPv6 addresses, which addresses are used? Microsoft, Linux, Unix and Mac operating systems all prefer IPv6 source addresses over IPv4 by default. when an appropriate IPv6 destination address is available.

RFC 3484 defines an algorithm for source address selection in the form of a policy table which prioritizes precedence values and preferred source address prefixes for returned destination addresses. This table enables the host to select the most appropriate source address given the possible destination addresses returned with the DNS queries. The original default policy table published in RFC 3484 appeared as:

::/0401Default (matching unicast) IPv6 address
::/96203IPv4-compatible IPv6 address
::ffff:0:0/96104IPv4-mapped IPv6 address

While RFC 3484 defines independent rules for selecting source and destination addresses based on the policy table, the logic is generally the same and consists of selection in the following priority order:

  1. Prefer the same address type
  2. Prefer the same address scope (link-local, site/ULA, etc.)
  3. Prefer non-deprecated addresses (avoid both globally deprecated addresses like site-local and addresses in deprecated state)
  4. Prefer home addresses over care-of addresses (Mobile IPv6)
  5. Prefer source addresses on the selected outbound interface assigned by the designated next hop (e.g., if the outbound interface connects to multiple ISPs, each of which assigned an IP address to the interface, select the one assigned by the corresponding ISP (next-hop)
  6. Prefer matching labels (source and destination prefix mapping)
  7. Prefer public address space
  8. Prefer the address with the longest matching prefix up to the subnet prefix length (this "up to" qualifier added to enable proper DNS round robin operation where multiple round robin destinations on the same subnet resulted in always the same one being selected, that having the longest total bit-wise matching prefix

RFC 3484 is currently undergoing revision and is currently in Internet draft status to add Unique Local Addresses (ULA) as well as Teredo addresses. Though unofficial as yet, the revised policy table currently looks like:

::/0402Default (matching) IPv6 address
::ffff:0:0/96303IPv4-mapped IPv6 address
::/96110Avoid IPv4-compatible IPv6 address
fec0::/10111Avoid site local IPv6 address

A given host's policy table may be modified if needed in one of the following ways depending on the OS:

  • On Linux you can explicitly denote a prefix as non-preferred setting the preferred_lft parameter to 0. For example, ip -6 addr change 2001:db8:4e/128 dev eth0 preferred_lft 0 disables selection of 2001:db8::4e address as an outbound source address.
  • On Unix/Solaris you can edit the /usr/sbin/ipaddrsel.conf file which is formatted just like the policy tables above. This allows insertion or demoting of address prefixes as desired. Run the /usr/sbin/ipaddrsel command to load the new configuration.
  • On Windows XP, use the ipv6.exe command to update the policy table for a given prefix in the form of:
    ipv6 ppu prefix precedence precedence_value srclabel label_value_source [dstlable label_value_dest ].
  • On Windows 7, Server 2003 and 2008R2, you can update the policy table for a given prefix in the form of:
    netsh interface IPv6 add prefixpolicy [prefix =] prefix/length [precedence=] precedence_value [label=]label_value[[[store=] {active | persistent}]].

Of course creation of and sending of an IP packet with the best match IP source and destination addresses does not guarantee delivery as intermediate transit nodes may or may not support the chosen protocol. As with most things, having a second or third choice improves the probability of a successful connection.

Wednesday, September 14, 2011

Planned Obsolescence in the IPAM Industry

Many products become obsolete or passe over time due to the availability of newer products with technology improvements or of more attractive replacement products, or even due to intangible factors such as social fads or trends. I'd term these natural or unplanned obsolescence. But planned obsolescence is a scheme where a product is consciously designed, manufactured or offered with a limited lifetime. The motivation is obvious: the product bought this year will become obsolete within x years, so the customer will need to re-purchase the product at that time.

Perhaps you've recently heard something like this from your IPAM (aka DDI) vendor: "Sorry that version of software doesn't run on that version of hardware." Or "that version of product has expired as has your support. I guess you'll have to repurchase everything!"

While this may be sound strategy for growing top-line revenue as every sale today will be repeated in x years, it's not necessarily attractive to customers. In fact I'm surprised customers knowingly buy into such vendors. And that those who unwittingly do so, repurchase again when "support" expires. There are alternatives out there and perhaps it's time for another look when "hit" with a repurchase invoice from your vendor. In this economy, who can afford to buy the same product every x years?

I invite you to check out BT Diamond IP products and services as your support expiration approaches. If you have to purchase your IPAM infrastructure again, why not consider a vendor from whom you only have to purchase the product one time. There's no doubt that evaluating IPAM vendors and products is a laborious and tedious process, and vendors with a repurchase strategy are counting on the theory that it's easier just to repurchase than to re-open the evaluation process. Don't be taken advantage of! Go with vendors who will support their products!

Friday, August 26, 2011

IPv6 Internet Concentration Growing Rapidly

Based on analysis of Internet routing table information, the RIPE NCC (the European region Regional Internet Registry) publishes a telling graph regarding the growth in concentration of IPv6 networks in the Internet IPv4/IPv6 mix. The useful graph is interactive, allowing filtering by country, RIR or multiple criteria. I like it so much I've framed it into my website.

It's no surprise that the APNIC region with its relatively scarce IPv4 space especially with respect to its served population, has and continues to lead the pack in terms of percentage of Internet networks (autonomous systems) advertising at least one IPv6 prefix. But all regions trend in a like manner, exponentially higher, approximately doubling in proportion since the beginning of 2010!

Assuming this trend continues as IPv4 space runs out completely, ask yourself if your Internet presence is prepared for this growing proportion of IPv6 users. As I've blogged several times this year and will likely continue to harp on, now is the time to prepare for IPv6 deployment if you aren't already doing so!

Thursday, August 11, 2011

IPv6 Business Drivers

I just commented on a Network World article about IPv6. The question was asked regarding the top five business drivers for deploying IPv6 and this was my offering:

In my opinion, these are the top 5 business drivers to deploy IPv6:

1. Remaining open for business on the Internet ubiquitously. With Asia being among the fastest growing region for broadband and mobility subscribers with no remaining IPv4 addresses, you'll need an IPv6 Internet presence to communicate with this soon-to-be-exploding segment of the Internet population. If you do any business on the web (and who doesn't?) you need to deploy IPv6 at least externally.

2. Keeping up or ahead of competition who may be ahead or behind in various stages of IPv6 deployment. Depending on your industry, such "technological leadership" can be positioned as a competitive differentiator.

3. Most operating systems ship with IPv6 today so IPv6 may already be "deployed" at least locally in spots. Improve your visibility to IPv6 addresses in use in your network. While this one isn't necessarily a driver to "deployment" it is a driver to prepare for and learn about IPv6.

4. Ability to support partner connections for those partners requiring IPv6.

5. Support a work environment with opportunity for career growth for your IT/Ops staff in being able to work on "new" technology such as IPv6.

Tuesday, August 9, 2011

IPAM Book News

I just received my August, 2011 issue of IEEE Communications magazine. I noticed a book review for my IP Address Management Principles and Practice book. I am gratified and humbled by the review which included such comments as, "The book ... provides comprehensive information for practitioners dealing with IP Address Management (IPAM)" and, "whenever one encounters a networking issue (not only basic), an answer ... can be found."

In related news about this book, my publisher informed me that it will be translated for sale in China. With continuing proliferation of communications technology and a virtual lack of IPv4 addresses, hopefully readers in China will be able to learn about IPv6 technology and various techniques for effectively managing it along with related IPAM technologies.

If you've read my book or my Introduction to IP Address Management book, I'd be grateful for your feedback as well, whether good, bad or ugly. Also check out my website for more IPAM resources including technology-specific RFCs and ISC/BIND configuration details for IPv4 and IPv6 DHCP and DNS.

Wednesday, August 3, 2011

Raising the Roof on the IP Address Ceiling

After half a year of drawn out, down-to-the-wire, insidious infighting, the U.S. government has raised the "debt ceiling," the maximum debt liability permitted for the U.S. Treasury. What had routinely been a relatively easy and trivial task in the past became an outright stare-down to the brink of economic calamity. Nevertheless, with Congressional passage and the President's signature, the "capacity" for debt permitted by the U.S. government had been raised.

If only the capacity of IP address space could be raised as "easily." Some may argue that some of the emails on RIR or IETF email lists rival those of Congressional rhetoric over the last few weeks, but all attempts to raise IPv4 capacity have been unsuccessful. This is largely due to the fact that IP address capacity is plentiful in the form of IPv6 address space. Any steps to squeeze out IPv4 space will only postpone the inevitable: IPv6 is required to meet the ever-increasing demand for IP addresses. So instead of raising the ceiling, the Internet added a second floor, which itself has a very high ceiling!

With the Asia Pacific region down to its last remaining /8 block of IPv4 space, we've nearly hit the capacity ceiling for IPv4. Internet users in this half of the world will be among IPv6 early adopters from an end user perspective. Will these users be able to communicate with you and vice versa? It's time to think through the implications and to begin planning for IPv6 deployment.

Monday, July 25, 2011

Talking Technology Video

After CiscoLive in Vegas two weeks ago and my "Mayan Internet Calendar" presentation which was well received, I headed to London last week, where I participated in a live BT webcast. The webcast featured six speakers from various BT entities and my segment is about one-third of the way into the show, which you can view here, then select the July 19 session. I discussed the IPv4 exhaustion situation and the need to begin planning for IPv6 deployment now. Check it out!

Friday, July 8, 2011

The Mayan Internet Calendar

I'm getting ready to fly out to Vegas for Cisco Live! 2011. It's looking to be a pretty good show with Cisco confirming nearly 19,000 attendees and another 40,000 virtual participants. Cisco Live has been the leading networking show in the industry at least over the last five years in my opinion. Obviously not everyone uses Cisco, but for networking geeks like me, it's a great venue for discussuing IPAM.

In fact, I will be giving a talk at the Cisco booth on Thursday. Since it's the last day of the show, which is traditionally pretty dead, I thought I'd add some humor and lighten it up a bit for those diehards who stick around for it. The title of my talk is "The Mayan Internet Calendar". I don't know about the end of the world, but we are certainly approaching the end of the Internet world as we know it as a nearly homogeneous IPv4 network.

As the explosive demand for IP addresses continues, soon this demand will be met with IPv6 addresses. As the IPv6 population grows, the complexion of the Internet will change to that of a dual-protocol Internet for quite some time. If you'll be the show, stop by and check it out, or if you're leaving early, stop by the BT Diamond IP booth to say hi.

We'll see if the purported Mayan prediction of the end of the world comes next year, but it's a sure bet that 2012 will bring the end of the Internet as we know it!

Monday, June 20, 2011

New gTLD Program Approved

As predicted in a prior blog post earlier this year, the Internet Corporation for Assigned Names and Numbers (ICANN) voted today to approve the new generic top level domain (gTLD) program, opening the door to additional top level domains, particularly those of international language. Applications for newly proposed gTLDs will be accepted between January 12, 2012 and April 12, 2012. Read the press release for full details.

Today, DNS domain administrators are typically concerned with a handful of TLDs "under" which to register their organization's domain name(s) and maintain zone data. For example most commercial organizations register within the .com gTLD and perhaps a country code TLD (ccTLD) in which services or products are offered. The addition of perhaps hundreds of new TLDs, many of them "international", meaning they are respresented in non-ASCII characters, could present a couple of new challenges for DNS administrators.

The first challenge is that of sheer effort in supporting the registration process with each gTLD of interest. Corresponding zones and zone data must also be configured, though use of a common zone file can simplify the ongoing maintenance effort required, assuming you're publishing common DNS data across all TLDs. The second challenge relates to configuring international domain names (IDNs) in DNS. Several RFCs define this process under the guise of International Domain Names for Applications (IDNA). If you'd like to read up on IDNA and the effort required to implement it, check out my new white paper.

While most of us have enough to do without taking on additional work, the business side of your organization may wish to simplify access to your website and email for users of a particular language. Supporting international gTLDs enables fully "native language" domains names. What could be simpler? As is typical, "simple" for end users translates into more work on network administration. But supporting additional revenue opportunities benefits everyone in the organization.

Wednesday, June 8, 2011

World IPv6 Day Quietly Successful

Early feedback indicates that June 8th was a successful World IPv6 Day...or should I say lack of feedback. But in this case no news is good news. Despite an occasional IPv6 reachability issue perhaps due to IPv6 inexperience, no widespread or even moderate connectivity issues were reported for IPv6 or IPv4 connections.

As reported by the Internet Society, sponsors of World IPv6 Day, nearly all registered participating organizations truly participated and measured IPv6 traffic was up sharply compared to nominal IPv6 traffic, though still miniscule with respect to overall IP traffic.

So while scalability testing was not in the cards, hopefully participating organizations have garnered "lessons learned" about implementing IPv6. Scalability testing will inevitably come with time with an increasing IPv6 end user population. So now's not a bad time to get comfortable with IPv6 when demand is low...for now!

Tuesday, June 7, 2011

Happy World IPv6 Day!

The day has arrived for participants to fire up their IPv6 addressable web servers to give IPv6 an Internet "test flight!" As I blogged last week, I'm excited to see the results - was it easier than expected and worked flawlessly or were there headaches and issues? Perhaps a little bit of both!? In any case, right now, it's all about awareness and this is the day for it! In fact, at, we just posted an IPv6 information kit, which includes a basic Microsoft Windows IPv6 subnet calculator and my IPv6 addressing white paper. Register here to download your copy!

In my informal statistically insignificant poll on my website over the last few days, over half of respondents were planning to participate with varying degrees of readiness. It is encouraging to see interest in participating. I believe the investment in time in enabling IPv6 for at least just one web server will give administrators the satisfaction of having participated and of experiencing what it takes on a small scale.

Theory is nice but experience makes it real. And experience is something organizations can build on to pursue further IPv6 deployment in a disciplined, controlled manner or to defer such activities. I'm all for conscious decisions as much as possible and the more real data on which to base such decisions, the better!

Friday, June 3, 2011

World IPv6 Day is almost here! Are you participating?

The Internet Society-sponsored World IPv6 Day is June 8, 2011. The intent of this effort is to publicize the need to consider IPv6 deployment and to allow organizations to "test drive" IPv6 by implementing it on a limited basis, e.g., on external web servers. This day should provide interesting results with respect to any connectivity issues as well as participants' experiences and lessons learned.

Personally I applaud this initiative and believe it will raise awareness to the state of IPv4 address capacity and the need to at least consider IPv6 deployment. Not everyone will feel the need to deploy IPv6, but this decision should be made consciously, considering your costs, your estimated time frame when IPv6 users will begin to gain critical mass and the corresponding potential loss of web visitors due to inaccessibility to IPv6 users. Some organizations may create a plan for deployment and set it aside for use when and if IPv6 deployment is warranted. Others will hedge their bets and build on World IPv6 Day success or failure to expand deployment or revise deployment strategies.

The point of the day is to give some thought to IPv6. Make a conscious decision to defer action or pursue more details. I'd be interested in hearing from you regarding your plans to participate in World IPv6 Day. Take my quick poll and let me know!

Wednesday, June 1, 2011

Cornering the market on good ideas

We at BT Diamond IP just wrapped our annual user conference last week in Philly. Putting on a conference like this takes a committed team effort, lots of work in logistics, planning, staging, and material preparation. All of this prep work helps the conference to go relatively smoothly. Given the conference attendee survey results, it appears our efforts were well worth it!

There's really nothing like getting together face-to-face to discuss IPAM products, technologies, and user concerns and suggestions. Customers get a lot out of it - meeting and chatting with our engineers, leadership, support staff, etc. But we get a lot out of it too. While we've certainly got among the most experienced and bright IPAM engineers in the industry, we haven't cornered the market on good ideas! And thankfully neither has anyone else.

The users of our products help keep us grounded and focused on prioritizing what's important to them in making their IP management tasks easier, which is our mutual goal. By listening to our customers, we can come closer to achieving it. What a concept!

Thursday, May 19, 2011

IPAM or DDI: why buy an automobile when you can buy TWA?

The term "DDI" is redundant and superfluous. But it's proven an effective distraction to the market from the true IPAM capabilities, or lack thereof, of certain vendors. You see, IP address management, IPAM, comprises the practice of managing IP address space, from which DNS and DHCP configurations can be derived and deployed. The term "IPAM," initially coined in the 1990's, incorporates IP address management, which itself includes DNS and DHCP configuration.

Why would an IP engineer define an address pool on a DHCP server in a vacuum, independently of the IP address plan? An address pool corresponds to one or more IP addresses on a provisioned subnet which rolls up to an IP address block managed by the IP network manager. Likewise, a device's DNS resource records, especially those referring to a device's IP address(es), namely A, AAAA and PTR, relate to an IP address on a similarly provisioned subnet.

The inter-relationships and dependencies among these three core functions necessitate an integrated approach, not one of loosely associating each major sub-function. The analogy is one of a tire manufacturer who at first simply extends the current tire business model into "wheels." Then seeking the broader more lucrative automobile market, derives the term "tires, wheels and automobiles" or TWA! Why settle for an automobile? Obviously a working automobile includes wheels and tires, though they may be interchanged independently, just as a true IPAM solution includes DHCP and DNS, which also may be interchanged independently among DHCP/DNS reference implementations.

So beware of new and different buzzwords for established practices. It makes for good marketing hype but it probably also masks a major deficiency. I visited my eye doctor today and he said he was in the market for a car; I could have told him not to settle for just an automobile, to make sure he considered the new TWA solutions as well if there was such a thing, but I would have advised him to stick with the tried and true automobile approach instead for a complete integrated solution.

Thursday, May 12, 2011

New IPAM-focused website!

I haven't posted in a while as I've been spending my spare time tweaking my new website! I needed to track the various configuration parameter settings for DHCP and BIND for my own reference - so why not share it!? The site details configurations for these market-leading reference implementations and I plan to keep it as up-to-date as practical. I've also packaged up these configuration details along with those for Microsoft DHCP and DNS in an "IPAM Configuration Reference Guide", downloadable in pdf or zip format - to download the document, simply register as part of the IPAM community!

The site also links to key resources for further information on IP addressing, DHCP and DNS including DNSSEC including relevant RFCs. The goal is to be technology focused and not so much sales focused - we get enough of that with vendor sites and even affinity sites like LinkedIn!

IPAM technologies continue to evolve and new resources come and go, so it's somewhat of a work-in-progress or a "living" site, which is a good thing! If you have any content or link suggestions, please feel from to post a comment or email me!

Friday, April 15, 2011

APNIC First RIR Down to Last /8

When IANA allocated its final set of /8 address blocks, one each to every Regional Internet Registry (RIR) on February 4, 2011, the "source" of IPv4 address space had officially dried up. The second tier in the IP address distribution chain, the Regional Internet Registries (RIRs), at that point each received a /8 of address space (consisting of 16,777,216 IP addresses).

Interestingly, the Asia Pacific Network Information Center (APNIC) RIR received the last allocation that triggered this final /8 distribution to each RIR. The allocation of two /8s to APNIC February 1 left IANA with five /8s left, which by policy were distributed to each RIR. So APNIC received three /8s in early February - as of today, they are down to one. Having allocated address space comprising about 33 million IP addresses in ten weeks is a testament to the voracious appetite for IP addresses in the region. Of course the AP region compasses over two-thirds of the world's population!

At this point the APNIC will institute its final /8 policy or stage 3 policy which provides for smaller maximum allocations to prolong the lifetime of this final /8. Internet Service Providers in the region will soon have no access to additional IPv4 space and their customers will only receive IPv6 allocations, probably by later this year. The onset of the "IPv6-only" customer is fast approaching. Are your Internet servers for www and email prepared to receive their communications?

Thursday, March 31, 2011

It's Official - .com is Signed!

According to Matt Larson of Verisign, the .com zone is in production as a DNSSEC signed zone as of 1500 UTC today (11am EDT)! This is a big step in helping to eliminate islands of trust given a linked chain up through .com to the root zone.

Now validating resolvers (recursive or caching servers) need be configured with the root zone's public key as trust anchor to validate .com subzones. This along with automated trust anchor rollover per RFC 5011 , puts ongoing management of validating DNSSEC servers on "auto pilot." As the root zone rolls keys, the RFC 5011 process enables validating resolvers to roll with the root!

On the flip side, signing your authoritative zones still requires some ongoing configuration and updating (unless of course you're using a policy-driven signing DNSSEC server such as BT Diamond IP's Sapphire Sx20 appliance!). If you're within the .com domain subtree, you'll need to provide your Delegation Signer (DS) records to your ISP for each of your KSKs, assuming of course your ISP supports DNSSEC! If your service provider hosts your DNS, then they may offer DNSSEC signing as part of their services.

This is a big day in the history of the Internet. Congratulations to the Verisign team for this monumental achievement!

Thursday, March 24, 2011

Microsoft Windows Server DNSSEC Support - Clever or Cumbersome?

Microsoft Windows Server 2008 R2 supports DNSSEC[bis] for both signing zones (for authoritative servers) and for validating DNSSEC responses (for recursive servers). Zone signatures for authoritative servers must be configured and performed using the dnscmd command line interface. While at first blush, it may seem inconvenient not to enable DNSSEC via the graphical interface of the Microsoft Management Console (MMC), this is actually a legitimate and even ingenious implementation approach.

How many organizations' IPAM configuration teams also manage network security? In small organizations, certainly these and all IT functions for that matter could fall into the lap of a single person or team. But for modest to larger organizations, who may in fact be more amenable to using Microsoft Windows Server products, the network security function is typically an independent function by design, even if the rest of IT falls within another single group.

Not to stereotype network security personnel, but they tend to want sole control over security policies and implementations. This "necessary paranoia" actually makes for solid security policy. Security professionals may prefer to control the configuration of DNS security policies, keys and signatures under the sole authority of the security team, obscured from the DNS configuration team which uses the MMC interface on a day-to-day basis. You wouldn't want an IPAM/DNS engineer to view and/or edit an RRSIG or DNSKEY record out of curiosity would you?

So is it clever or cumbersome? Does your network security team trust your IP network engineers to configure and managed DNSSEC? If so, perhaps the Micorosoft approach is cumbersome and a solution giving IPAM engineers control of DNSSEC policies is in order. But if not, having a separate user interface outside of the normal day-to-day DNS/IPAM workflow is downright clever if not ingenious!

The Microsoft approach is not without its limitations however. For example, Windows Server 2008 R2 supports signing of static zones only (dynamic zones are not dynamically signed) and limited support of NSEC3 record processing, but I'll address these topics is in a future post.

Tuesday, March 22, 2011

Take the IPv6 Survey!

If you'd care to share your thoughts on IPv6 deployment within your organization, I invite you to participate in BT Diamond IP's IPv6 survey. It only takes about five minutes to complete but your feedback would be useful input to our sampling of where people are with IPv6 these days. INS conducted similar surveys in 2005 and in 2008, so we're right on queue with our triennial survey! I have a feeling results may be a bit more IPv6-optimistic this year...but I don't want to jump to conclusions! That's why we put the survey out there.

The survey is quick plus you could win your choice of an autographed copy of two IPAM books by yours truly or a $100 American Express gift card (it's ok if you pick this, I won't be insulted!). One winner from among the survey respondents will be selected in late April, so take the survey today!

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?

BIND 9.8.0 introduced a new dns64 option statement that can be configured within the server named.conf options block or within a view options block. Recall from a prior post that DNS64 configures a recursive DNS server to issue A record queries on behalf of a client requesting AAAA records, then appends the returned IPv4 address to a defined IPv6 prefix. This manufactured IPv6 address enables the querying host to connect to a NAT64 gateway which will terminate the IPv6 connection from the client and map it to an outbound IPv4 connection to the appended IPv4 address, completing the connection! Whew!

BIND offers a number of useful parameters within the dns64 statement to control this process. The statement syntax is:

dns64 IPv6_prefix {
[clients {address_match_list };]
[mapped {address_match_list };]
[exclude {address_match_list };]
[suffix IPv6_addr;]
[recursive-only (yes|no);]
[break-dnssec (yes|no);]

The IPv6_prefix parameter is the prefix to which returned IPv4 addresses shall be appended and is required.

The clients parameter indicates an address match list of clients for whom the service is provided; the default is any. This is similar to "match-clients" in a view statement.

The mapped parameter indicates which IPv4 addresses within the A resource record set shall be mapped to corresponding AAAA answers. For example, this can be used to define non-private addresses or other addresses where mapping is not desired.

The exclude parameter defines which IPv6 clients will be excluded from the DNS64 service (actual AAAA records will be returned or NXDOMAIN).

The suffix can be used to specify additional bits to include in the mapped response following the IPv4 address (default is ::). For example, if the prefix length is 64 bits and an IPv4 address is 32 bits, that leaves 32 bits that may be appended in this case.

The recursive-only parameter indicates whether to apply DNS64 mapping to recursive queries only.

The break-dnssec option will not add or remove records from the authoritative server response if set to "no" and will do so if "yes".

Another nice feature of DNS64 support in BIND is the automated creation of the reverse domain corresponding to the IPv6_prefix parameter. IPv6 reverse domains can be lengthy and error-prone so this feature provides one less opportunity for error. You can specify the default contact name and server name parameters to be populated in the SOA record of each such reverse domain by using the dns64-contact and dns64-server options respectively.

Wednesday, March 16, 2011

BIND 9.8.0 Adds DNS64 Support - Part 1 - What is DNS64?

The Internet Systems Consortium (ISC) recently introduced BIND 9.8.0, a major release with several new features. I'd like to focus on DNS64 support, which is an IPv4-IPv6 co-existence feature that enables IPv6 hosts to connect to IPv4 destinations via a NAT64 (IPv6-to-IPv4 network address translator). DNS64 functions operate on a recursive server which attempts to resolve queries on behalf of its clients.

When a client issues a query for a AAAA (IPv6 address) record type for a particular destination host, the DNS server initially behaves normally, locating the authoritative server and issuing the query. If AAAA record(s) are returned, the servers passes this to the resolver client and a native IPv6 connection ensues. If no AAAA records are received, the DNS64 service performs an additional query for the same destination host though for the A (IPv4 address) record type. If a successful response is received, the DNS64 service concatenates the returned IPv4 address to a pre-defined IPv6 prefix to formulate an IPv6 address. This IPv6 address is returned as the answer to the original AAAA query from the resolver client, and it connects the client to the NAT64 gateway.

The NAT64 gateway is configured to listen for IPv6 packets on all addresses within the same pre-defined IPv6 prefix that the DNS64 service uses to append resolved IPv4 addresses. When the client host sends the IPv6 packet to initiate the connection to the resolved IPv6 address, the NAT64 gateway receives the packet and it knows to what IPv4 destination it is destined as appended. Hence the NAT64 device allocates an outgoing source IPv4 address and initiates a connection to the IPv4 destination. The NAT64 device interconnects the IPv6 session with the originating host with the IPv4 session to the destination host. Thus IPv6 hosts are able to communicate with IPv4 destinations! For more details including a timeflow diagram please see my recent white paper which includes discussion of DNS64.

Sunday, March 6, 2011

Need a Quick Concise Guide to IPv6 Deployment Options?

If you're starting to investigate your options for deploying IPv6 within your existing IPv4 network, wouldn't it be nice if you had a thorough yet concise summary of your options in one place? There are a dizzying number of alternatives, and deciding which ones to consider and further investigate can take time. If you're operating a network for an enterprise, perhaps dual stack, ISATAP, 6to4 or a translation technology would work best. Or as a service provider, perhaps 6rd, dual-stack lite, or NAT64 would better meet the needs of your business.

So if you're looking for a concise guide...well, actually two a starting point, check out these two free white papers at the top of the list. I've just published an update to my IP4v-IPv6 Co-Existence Strategies white paper and a new white paper entitled Service Provider IPv6 Deployment Strategies. The former paper is broadly applicable though more focused on enterprise IPv4-IPv6 co-existence strategies, while the latter is focused on service provider techniques. Hopefully these papers will help you begin the process of evaluating alternatives, dismissing fruitless alternatives and focusing your research on suitable alternatives.

Saturday, February 26, 2011

Upcoming Milestones in Bringing DNSSEC to .com

Starting today, ICANN-accredited registrars may submit Delegation Signer (DS) records to Verisign, the .com administrator. Most organizations obtain and register their domain names with domain registrars, who may also be their ISP. Contact your registrar to determine if they are participating in this process. Verisign will include submitted DS records in a"deliberately unvalidatable" .com zone that will be published on Monday, February 28. This deliberately unvalidatable zone will contain dummy keys for testing purposes.

As recently announced , the .com zone will be signed in production on March 31, 2011. The submitted DS records will be included in the signed .com zone and the .com DS record will be published in the root zone, fully linking the chain of trust for .com zones!

This linked chain of trust vastly simplifies the management of trusted keys on validating resolvers (typically within recursive or caching DNS servers which are queried by clients or "stub resolvers"). Prior to this linkage, a validating resolver requires a copy of each .com's trusted subzone's public key (key signing key, KSK). So if a DNS administrator desired to implement DNSSEC validation to protect the cache of his/her DNS servers, a trusted key for each subzone needed to be configured on each caching server. If you think about all the .com subzones your users browse or email to, that's a lot of trusted keys! Fortunately, with a fully linked chain of trust, only the root zone's public key (KSK) need be configured for successful validation of .com subzones.

The KSK of a signed zone basically signs the zone's key records, consisting of the KSK and the zone signing key(s) (ZSKs). The ZSK signs the zone, meaning that it is used to produce a signature for each resource record set within the zone. The DS record is analogous to the NS record. The NS record provides referrals to the next subzone in the domain tree for name resolution. The DS record provides a "trust referral" to a signed subzone by incorporating a hash of the subzone's KSK. If a validating resolver does not "trust" the subzone's KSK, it can check if the parent zone links trust to this KSK via a corresponding DS record; if so the validating resolver can determine if it trusts the parent zone's KSK, and so on up the domain tree to the root!

Friday, February 25, 2011

IPv6 Implications for Enterprises

With the recent announcement that IANA has allocated its last remaining IPv4 address space to the Regional Internet Registries (RIRs), time is running out on availability of new IPv4 address space allocations. As the last remaining IPv4 address space is allocated, enterprises at some point in the not too distant future will have no choice but to implement IPv6 for Internet-accessible web or email servers. Any newly-formed organization or those that require additional address space after this time will be "IPv6-only" organizations.

Perhaps you're thinking this is not an issue given the plentiful private IPv4 address space. But consider this: as this population of IPv6-only organizations and users grows into 2013 and beyond, will they be able to reach your websites and email? To serve this population which will grow rapidly as more IP-based public and private applications are deployed, implementation of IPv6-addressable Internet servers is imperative.

Besides implementing IPv6 on Internet-facing servers, enterprises should take heed regarding IPv6 addresses already in use internally. Many popular operating systems including Microsoft Windows and Linux natively support IPv6 addressing. A major feature of IPv6 addressing is address autoconfiguration, which enables a device to identify the subnet address to which it is attached by virtue of router advertisement messages and to append its self-derived Interface Identifier to this subnet address to fully compose a unique IPv6 address unbeknownst to network administrators.

Autoconfiguration may provide a convenience for users initializing on a network, but it runs counter to network admission control (NAC), a strategy for reviewing and approving the assignment of addresses to devices. The scope of autoconfigured IPv6 devices can be constrained to a local link by disabling the autoconfiguration option in router advertisements or by disabling router advertisements altogether until you consciously deploy IPv6 on the given link. Take control and implement IPv6 on your terms...but do plan to implement it!

Wednesday, February 23, 2011

Network World Concurs: IPAM Required for IPv6, IPv4, DHCP, DNS

I couldn't agree more! It's nice to see corroboration in recent commentary by Jeff Doyle on the overall disciplined approach for IPAM encompassing IP planning, DHCP and DNS. In his article for Network World, Jeff states that an IPAM solution is even more necessary with the advent (or onslaught?) of IPv6 deployment. Dotted decimal IPv4 address allocations and assignments can more easily be tracked in spreadsheets or homegrown solutions than can IPv6 hexadecimal.

In addition, Jeff highlights the need to integrate DHCP and DNS management with IP address planning, which I've always contended helps eliminate duplicate entry of common data, saving time and reducing the potential for data entry errors.

Another comment I found interesting is Jeff's contention that some organizations will conclude that managing two protocols, IPv4 and IPv6, is expensive, risky and difficult and will fully implement IPv6 sooner rather than later. If this prediction holds true, then the need to plan for and implement IPv6 on Internet-facing servers is even more urgent than I discussed in a prior post. IPv6 is the future! Plan on it!

Incidentally, if you're interested in more discussion regarding IPv6 allocations and even allocating address space such that assignments have "meaning" as Jeff suggests, please consult Chapter 3 of my IP Address Management Principles and Practice book.

Thursday, February 3, 2011

When will the second domino of IPv4 space exhaustion fall in your region?

Now that IANA has exhausted its IPv4 address space, each Regional Internet Registry (RIR) now has a finite amount of IPv4 space to allocate to its “customers”, Internet Service Providers (ISPs). Eventually RIRs will run out of IPv4 space to allocate, followed by an ISP near you. The potaroo site, famous for its predictive tracking of the exhaustion of IPv4 space over the last few years, has published a frequency distribution for each RIR indicating for the estimated probability of IPv4 exhaustion by time frame.

This chart indicates that the Asia Pacific region will likely be the first to face exhaustion at the RIR level. The Asia Pacific Network Information Centre (APNIC) appears to be likely to exhaust its IPv4 space before the end of this year! According to the chart, the European region served by the RIPE NCC will exhaust in about a year or so, followed by North America’s ARIN RIR, exhausting in about one and a half to two years. The Latin America and Africa regions, served by LACNIC and AFRINIC respectively, have a relatively lengthy remaining IPv4 lifetime, not likely to exhaust until 2014 or later.

As IPv4 address space availability shrinks, requirements for obtaining IPv4 address space will become increasingly stringent. But with the continued growth of converged and virtualized IP devices, networks, services and applications, such controls will merely add flow control and only minimally extend the exhaustion date. IPv6 will soon be the only IP address space available for new address space requests. Now is the time to learn about and plan for IPv6!

Tuesday, February 1, 2011

First Domino Falls in IPv4 Address Space Exhaustion

As of today, IANA has allocated two /8 IPv4 blocks to APNIC, leaving five remaining /8 blocks. As discussed in a prior post, IANA will now allocate the remaining five /8 blocks, one each to the five Regional Internet Registries (RIRs). IANA's IPv4 address space has been exhausted!

Each of the RIRs now has finite and fixed IPv4 address space for allocation to ISPs. This may take a few months but soon the RIRs will exhaust followed by exhaustion of IPv4 space available to end users. The time to start learning and planning for IPv6 is now!

The timing is perfect given my talk today at Cisco Live! in London regarding IPAM. I will raise major news and reinforce my recommendation to start the process today!

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.