October 21, 2014 archive

DPRIVE – New IETF Working Group On DNS Privacy

IETF LogoHow can we ensure the confidentiality of DNS queries to protect against pervasive monitoring?  What kind of mechanisms can be developed to increase the privacy of an individual’s DNS transactions?

After holding a BOF session (DNSE) at an earlier IETF meeting, the IETF has now chartered a new Working Group called DPRIVE (DNS PRIVate Exchange) to dig into this matter. Part of the WG charter states:

The set of DNS requests that an individual makes can provide an
attacker with a large amount of information about that individual.
DPRIVE aims to deprive the attacker of this information. (The IETF
defines pervasive monitoring as an attack [RFC7258])

The primary focus of this Working Group is to develop mechanisms that
provide confidentiality between DNS Clients and Iterative Resolvers,
but it may also later consider mechanisms that provide confidentiality
between Iterative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions. Some of the results of
this working group may be experimental. The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

The group has adopted its first document for consideration, Stephane Bortzmeyer’s “DNS privacy considerations”, draft-bortzmeyer-dnsop-dns-privacy, and discussion has already begun on the “dns-privacy” mailing list.  This list is open to anyone to join. You can subscribe at:


and the archives are available at:


While this group does not directly relate to the work we do here at Deploy360 related to DNSSEC, it is part of the overall effort to increase the security of the DNS, and so I thought it would be of interest to our readers.

If you are interested in monitoring what is being discussed about DNS privacy, or contributing to those discussions, I would definitely encourage you to subscribe and join in the conversations and the work to make the Internet more secure!

Interesting IPv6 Address Planning Discussion on NANOG Mailing List

IPv6 BadgeEarlier this month there was an interesting discussion on the public NANOG mailing list about IPv6 subnetting that I thought might be of interest to our readers.

The very lengthy discussion thread began back on October 9, 2014, when Erik Sundberg asked this question:

I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space.


Small Customer?
Medium Customer?
Large Customer?

The ensuing discussion makes for interesting reading to see what many network operators do and why they suggest doing things in the way that they do.

For our part, we have a page about IPv6 Address Planning that links to several resources that can help guide people in what to do:


Of particular interest (and was mentioned in the discussion thread) may be the Best Current Operational Practice (BCOP) document developed by NANOG on this particular topic and available at:


It was a great to read the discussion on the NANOG list. One of the hardest things to understand when thinking about IPv6 address planning is the need to adjust your mind from living with the scarcity of IPv4 addresses to where we have a world of abundance of IPv6 addresses.  With that abundance we now have the freedom and flexibility to think about network addressing in a much different manner!

If you would like to get started with IPv6, please do visit our Start Here page to find resources tailored for your type of organization or role!