IPAM

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