February 2012 archive

Feb 17

Deploy360 Stickers and Pens!

Working remotely, I was delighted to receive a package recently from my colleague Megan down in our Reston, VA, office that was full of Deploy360 stickers and pens!  One Deploy360 sticker now is nicely on the back of my iPad and another adorns the cover of my laptop. (Yes, I’m that kind of person who puts stickers all over his laptop cover.  Provides an easy way to make sure no one grabs my laptop in a sea of other laptops. :-) )  The pens are also awesome and I’m looking forward to using them as my writing instrument of choice.

Would you like to receive a Deploy360 sticker or pen?  Just find us at one of our upcoming events and we’ll do what we can to get you one!

Deploy360 Stickers and Pens

Feb 17

Need A Weekend Project? Install The New DNSSEC-Trigger 0.10 Release

Dnssec TriggerLooking for a quick weekend project to learn more about DNSSEC? Want to set up your home network to correctly validate DNSSEC info?

If so, the NLnet Labs team just announced the 0.10 release of DNSSEC-Trigger, a local DNSSEC-validating resolver you can run on your Linux, Windows or Mac OS X system.

Per the change log on the project page, version 0.10 includes the following changes:

  • truncate pidfile (just like NSD fix, in case directory not owned).
  • If hotspot-signon, set override servers right away on a network change, so the user does not have to wait for 10 seconds after a change of the wifi.
  • Attempt to add DHCPv6 support for windows.
  • Use Processes.dll code (can be freely used, source provided) for kill process in windows NSIS installer. Compiled to 6kb (not 50kb). Processes.dll was made by Andrei Ciubotaru.
  • show version number in add-removeprograms configpanel (windows).
  • install script removes leftover trayicons using direct windows API.
  • dnssec-trigger-control uses registry config location (for windows).
  • fix dnssec-trigger-control error printout if SSL files fail.
  • show package version in probe results dialog.
  • updated acx.nlnetlabs.m4 for gcc 4.6 compat for portability tests.
  • Do not show the insecure and hotspot windows at the same time.
  • Fix for OSX to show the popups on top of the other windows.
  • alert icon easier to read.

I just updated my local MacBook Pro and the installation went perfectly fine. (To “update” on Mac OS X, you simply download the latest version and run through the installation process again.)

How will you know if DNSSEC-Trigger is working? Well, one simple test is to try to go to either of the “bad” websites we mention on the DNSSEC Tools page in your web browser: www.dnssec-failed.org or www.rhybar.cz. If DNSSEC-Trigger is working correctly, your web browser will probably tell you that it can’t find either of those sites. DNSSEC-Trigger is determining that the sites do not correctly validate and is therefore not providing any DNS information for those domains.

Anyway, the new 0.10 release of DNSSEC-Trigger is available now for download for Windows, Mac OS X or Linux. Download it now and get started using DNSSEC validation!

Feb 17

Chris Grundemann’s Excellent “Introducing IPv6″ Article Series

Over on his “don’t panic” blog, Chris Grundemann has started an excellent series of articles on the topic of “Introducing IPv6″.  You can see the articles he’s written so far:

http://chrisgrundemann.com/index.php/category/ipv6/introducing-ipv6/

In his first post in the 4-part series, Understanding IPv6 Addresses, Chris goes down to a bit level to explain exactly why we wound up writing IPv6 addresses in hexadecimal notation, and then explains some of the shortcuts we use.  In part 2, Classifying IPv6 Addresses, Chris takes a look at the different types of IPv6 addresses and walks through each of them works.  In part 3, IPv6 Headers, he looks at what is different in IPv6 headers and how extension headers work… and his final part 4 will cover “Neighbor Discovery and SLAAC“.

Chris has a great writing style that’s very easy to understand.  It’s great that he’s writing this series and I look forward to seeing more of these kinds of IPv6 posts coming our way from Chris!

Introducing IPv6

Feb 16

Want to Deploy DNSSEC on Microsoft Windows 7 or Server 2008 R2?

MS DNSSEC Deployment GuideDo you operate a Microsoft Windows server infrastructure and would like to know how to implement DNSSEC? If so, Microsoft published a “DNSSEC Deployment Guide” to help administrators of Windows Server 2008 R2 and Windows 7 systems.

The comprehensive document explains what DNSSEC is all about, walks step-by-step through each process and also provides easy checklists to use as a reference during deployment and ongoing operation.

I no longer administer Windows Servers so can’t personally attest to the usefulness of the guide.  In reading through it, my initial reaction is that there seems to be very little GUI management of DNSSEC. Most of the administration seems to involve use of the ‘dnscmd’ command-line tool.  While that’s perfectly fine by me, given that I’ve a big command-line fan, I suspect that many regular Windows administrators may wish they could execute these commands through one of the administration tools Microsoft provides. The document also was last updated in March 2010 and thus pre-dates the signing of the root in July 2010. With the root signed, the section on distributing trust anchors may no longer be quite as applicable.

Regardless, this appears to be the most recent document provided by Microsoft and so if you have a Windows-based server infrastructure you may want to check it out.  I’d note that this document only applies to Windows Server 2008 R2 and Windows 7.  Earlier versions of Windows Server had much more limited support for DNSSEC.

If you are a Windows administrator, what do you think?  Is this document helpful? Useful?  What could Microsoft do to make DNSSEC deployment easier on Windows Server 2008 R2 or Windows 7?

Feb 16

3 IETF Mailing Lists To Follow For Monitoring DNSSEC

Would you like to monitor the ongoing evolution of IETF standards related to DNSSEC?  If so, here are 3 IETF working group mailing lists you may consider joining.  All lists are open to anyone to join.  Do note that several of these can have a very large amount of traffic.  Each of the mailing list pages also contains a link to the mailing list public archives if you would like to see what is going on in the lists prior to (or instead of) subscribing.

  • dnsext mailing list – dnsext charter

    The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT working group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols “on the wire” or the internal processing of DNS data. DNS operations are out of scope for the WG.

  • dnsop mailing list – dnsop charter

    The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones

  • dane mailing list – DANE charter

    The DNS-based Authentication of Named Entities (dane) working group will specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through DNSSEC for discovering and authenticating public keys which are associated with a service located at a domain name.

    For more information about the DANE working group, see the article in the October 2011 IETF Journal: “DANE: Taking TLS Authentication to the Next Level Using DNSSEC“

 

Feb 15

Slides: The Case For IPv6-Only Data Centers

Why don’t we just skip dual-stack and other transition technologies and jump straight to IPv6-only data centers that use a gateway/proxy server to service IPv4 requests? That’s the fundamental question Tore Anderson posed in his presentation to the V6 World Congress last week in Paris: “The Case For IPv6-Only Data Centers” (PDF). Here’s what was for me the key slide:

Tore goes on to explain how this can be done using Stateless IP/ICMP Translation (SIIT), also known as “Stateless NAT64″ and “IVI” and defined in RFC 6052 and RFC 6145. Through a series of examples and diagrams he shows how IPv4 traffic would pass through the SIIT gateways into the IPv6 data center and then back out again.  He explains the advantages of this setup and concludes with a configuration example and remarks that he’s using this exact setup for his own website and that of his employer.

It’s certainly an intriguing approach and I’m now thinking I may work on setting this up in my IPv6 lab I’m working on.

What do you think?  Do you like the idea of just migrating once to an IPv6-only data center?

Feb 15

Google’s Public DNS Works With IPv6 – Can Help In Your Migration

GooglePublicDNSIn a post out yesterday, “Google Public DNS: 70 billion requests a day and counting“, Google reminded us all that their Public DNS service supports IPv6 at these addresses:

2001:4860:4860::8888
2001:4860:4860::8844

From Google’s post:

We’ve also taken steps to help support IPv6. On World IPv6 Day, we announced our IPv6 addresses: 2001:4860:4860::8888 and 2001:4860:4860::8844 to supplement our original addresses, 8.8.8.8 and 8.8.4.4.

If you are working in an IPv6 environment, you can configure your system to point to these addresses for DNS services. (Typically in the settings or control panel for your operating system.) This can greatly help as you migrate your network to IPv6 or establish a trial network.

With World IPv6 Launch coming up on June 6, 2012, it’s great to have resources like these from Google that allow people to work in an IPv6 world!

Feb 15

Valuable Info In EU’s “Good Practices Guide” for DNSSEC Deployment

Looking for a good concise guide to the security issues and procedures related to deploying DNSSEC?  Back in March 2010, the European Network and Information Security Agency (ENISA) issued their “Good Practices Guide For Deploying DNSSEC” with the abstract:

Deploying DNSSEC requires a number of security details and procedures to be defined and followed with specific requirements as to timing. This guide addresses these issues from the point of view of information security managers responsible for defining a policy and procedures to secure the DNS services of a company or an organisation, and from the point of view of competent authorities defining or regulating requirements for deployment.

Coming in at only 29 pages, the document provides a good overview of the issues you need to be thinking about and the steps you need to go through when deploying DNSSEC. While the guide was created prior to the signing of the root zone in July 2010, it still is very accurate in outlining what needs to be done.

Well worth a look if you are looking for whitepapers and similar documents around DNSSEC deployment.

Feb 14

Network Computing: Time To Buckle Down and Start an IPv6 Project

Over on the Network Computer site, author Robert Mullins recently said it’s time to buckle down and start an IPv6 project. The first of an apparent three-part series, this article primarily provides an overview of the issues around the transition to IPv6, mentions the upcoming World IPv6 Launch, addresses the “chicken and egg” situation around IPv6 deployment and suggests that organizations look at trying some kind of IPv6 project.

According to the article, part two of the series will look at how to deploy an IPv6 network on top of an existing IPv4 network.

The author very nicely mentions Deploy360 (thanks!) and this is what we’re here for!  We want to help you get IPv6 deployed in some way within your network and organization.  Please do take a look at the many IPv6 resources we have available… and if you can’t find what you are looking for, please let us know so that we can find those resources!

Feb 14

4 IETF Mailing Lists To Follow For Monitoring IPv6

Want to monitor the ongoing evolution of IETF standards related to IPv6?  Here are 4 mailing lists and the associated IETF working groups you may consider joining.  All lists are open to anyone to join.  Note that several of these can have a very large amount of traffic.  Each of the mailing list pages also contains a link to the mailing list public archives if you would like to see what is going on in the lists prior to (or instead of) subscribing.

  • v6ops mailing list – v6ops charter

    The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.

  • 6man mailing list - 6man charter

    The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF.

  • 6lowpan mailing list - 6lowpan charter

    The 6lowpan Working Group has completed two RFCs: “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals” (RFC4919) that documents and discusses the problem space and “Transmission of IPv6 Packets over IEEE 802.15.4 Networks” (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4.The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available.

    6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs).

  • 6renum mailing list - 6renum charter

    As outlined in RFC 5887, renumbering, especially for medium to large  sites and networks, is currently viewed as an expensive, painful, and  error-prone process, avoided by network managers as much as possible.

    The task of the 6RENUM working group is to document existing renumbering  practices for enterprise site networks and to identify specific renumbering problems or ‘gaps’ in the context of partial or site-wide  renumbering. Completion of these tasks should provide a basis for  future work to identify and develop point solutions or system solutions  to address those problems or to stimulate such development in other working groups as appropriate.

    6RENUM is chartered to perform an analysis of IPv6 site renumbering. If  the analysis leads to conclusions that are also applicable to IPv4 that  will be an advantage, but it is not an objective of the WG to make its  outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios.

There are other IETF Working Groups (see full list) that may handle other IPv6 interactions, for instance the BEHAVE working group handling NAT issues, but these are the primary working groups working on IPv6 issues.