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