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 DN

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!

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 ca

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

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 Topic Date and Time IDNs and IPv6: Enhancing your Asia presence Tuesday, October 25, 2011, 12-1pm EDT Introduction to IPv6 Thursday, October 27, 2011, 12-1pm EDT IPv6 deployment checklist Tuesday, November 1, 2011, 12-1pm EDT Configuring DNS for a dual stack network Thursday, November 3, 2011, 12-1

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

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

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, wh

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 n

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 con

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

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 f

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 a

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!

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 t

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 o

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!

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 btdiamondip.com, 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

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 hedg

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

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 amo

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 wo

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

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

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 p

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

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-define

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 guides...as 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

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 resol

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 implementi

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

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

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!

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 nam

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 th

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 (

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 admin

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 h