- By Adib Behjat on April 21, 2011
Numbering Computers in IPv6
Computers and other IPv6-enabled devices need a way to select which IP address they are using, just like in IPv4. IPv6 provides several ways to do this:
- Manual configuration
- Autoconfiguration (Stateless Address Autoconfiguration, or SLAAC)
- Cryptographically Generated Addresses (CGA)
- DHCPv6 (sometimes called stateful autoconfiguration)
Manual configuration works the same in IPv6 as in IPv4 – the user or the user’s administrator configures the address by hand. While practical for very small networks, this is almost never done today due to the ease of use of the other methods and the more difficult notation in IPv6.
SLAAC allows a node (a computer or other device that is not a router) to automatically generate an address. This is done using information sent from nearby IPv6 routers, as well as some other information such as a unique hardware identifier or a random number.
CGA is a method designed to make it difficult for someone to spoof an address of another computer on a network. This is an improvement over ARP, which is used for neighbor discovery in IPv4, or ND which does the same in IPv6, and relies on the long number space in IPv6 to encode a public key. It is optional and not yet widely deployed.
Finally, there is DHCPv6. DHCPv6 performs the same role in IPv6 as DHCP does in IPv4. It allows a central server to distribute addresses and
other configuration information to a number of hosts.
The most common way to number in IPv6 today is using SLAAC. DHCPv6 offers a number of advantages over SLAAC:
- It allows central management, so administrators can know which addresses were in use at which time. This may be important for auditing, billing, and other purposes.
- Administrators can use similar tools for IPv4 and IPv6 network management, and they are comfortable with DHCP.
- It is easy for the DHCPv6 server to set up DNS and many other services, like SIP parameters, required for VoIP, on behalf of hosts.
- With DNS updates in DHCPv6, clients can enjoy having their human readable names, like desktop-joe.example.org rather than just an address like 2001:db8:1:21e:8cff:fe9b:7349.
- Entire prefixes, for example a /48 or a /64, can be delegated, instead of single addresses.
- Other kinds of configuration other than addresses are easy to transmit. (For example, until recently there was no way to transfer information about local DNS recursive resolvers except through DHCPv6.)
- Granting different parameters. Administrators may configure DHCPv6 to grant specific parameters to different groups or even single users.
- Access control. Administrators can configure DHCPv6 server to refuse to assign parameters to untrusted or unwanted users.
How is DHCPv6 Different from DHCP in IPv4?
The basic protocol flow is basically the same for both DHCP in IPv4 and for DHCPv6. However, the details are very different.
- No baggage
- DHCP is based on an earlier protocol called BOOTP. This packet layout is wasteful in a lot of cases. It is also cumbersome to parse and examine with network tools. Due to backward compatibility, there are a number of restrictions that further complicate DHCP for IPv4
- A lot of the options turn out to be not useful, or not as useful as they can be, but it is hard to change a protocol with such a large installed base.
- There are a lot of “tweaks” that implementations need in order to be compatible with the buggy clients.
- IPv6 is better. Four features of IPv6 greatly improve DHCPv6:
- IPv6 hosts have “link-local addresses”. Every network interface has a unique address, that can be used to send and receive on the link only. IPv6 hosts can use this to send requests for “real” addresses. IPv4 hosts have to use system-specific hacks to work before they have an address.
- All IPv6 systems support multicasting. All DHCPv6 servers register that they want to receive DHCPv6 multicast packets. This means the network knows where to send them. In IPv4, clients broadcast their requests, and networks do not know how far to send them.
- DHCPv6 supports robust relaying, with up to 32 relays in each network. This greatly improves scalability and network manageability.
- Thanks to number of features like deprecated addresses and information refresh time option, network administrators can easily perform configuration changes and even network renumbering with users barely noticing.
ISC was approached by Comcast in 2006 to implement DHCPv6, as they were looking for an open source DHCPv6 server to test IPv6 functionality on DOCSIS 3.0 modems. ISC released ISC DHCP 4.0 in December 2007, which included a DHCPv6 server, client, and relay. ISC continues to release new versions of ISC DHCP, which include additional functionality and other improvements to DHCPv6.
ISC is actively participating in DHCP and DHCPv6 standardization efforts within the IETF. ISC DHCP is often the first protocol implementation that offers new capabilities and is often used as a reference implementation by other vendors.
Sign up now to learn how Security Information Exchange (SIE) & Passive DNS are changing the way investigators are effectively collaborating.By Adib Behjat on March 17, 2011
Robert Edmonds, Eric Ziegast, Barry Greene
The Security Information Exchange (SIE) and ISC’s Passive DNS System (DNSDB) are public benefit projects that are contributing to a shift in the way security companies work with each other.
Please sign up now for one of two webinars on March 29th, 2011 (click here).
In this webinar, we will:
- Provide an Overview of SIE, Passive DNS, and the DNSDB
- Give a context of how this will help the Security industry evolve into more effective Private-Private and Public-Private partnerships
- Demonstrate how different security companies are using SIE to collaborate and share, quietly, behind the scenes, while publicly competing with these same “SIE peers.”
- Provide examples of how Passive DNS is pulling back the covers, allowing the good guys to see the bad guy activities, helping to “take back DNS.”
- Provide step-by-step guidance to help organizations join the SIE and Passive DNS efforts.
For more information on SIE or Passive DNS, please E-mail email@example.com.
- By Paul Vixie on March 16, 2011
COICA and Secure DNS
Update: This article from March 2011 was superceded in some details by a article published in August 2011. If you reached this blog entry as a result of the SOPA markup meeting December 15 2011, you should read both articles.
As a strong proponent of the private right of action for all Internet endpoints and users, I’ve long been aware of the costs in complexity and chaos of any kind of “blocking” that deliberately keeps something from working. I saw this as a founder at MAPS (Mail Abuse Prevention System LLC; http://mail-abuse.com/) back in 1997 or so, when we created the first RBL (Realtime Blackhole List) to put some distributed controls in place to prevent the transmission of unwanted e-mail from low reputation Internet addresses. What we saw was that in addition to the expected costs (to spammers) and benefits (to victims) of this new technology there were unintended costs to system and network operators whose diagnostic and repair work for problems related to e-mail delivery was made more complex because of the new consideration for every trouble ticket: “was this e-mail message blocked on purpose?”
Now that ISC (Internet System Consortium; https://www.isc.org/) has created DNS Response Policy Zones (RPZ;http://www.circleid.com/posts/20100728_taking_back_the_dns/) to bring a common interchange format and framework for putting distributed policy controls in place for DNS lookups, and now that ISC BIND9 9.8.0 has been published containing an implementation of this new technology, I’ve been pondering the possible side effects of “DNS blocking” as this kind of policy framework is sometimes called. In addition to the foreseeable complexities for system and network operators and their diagnostic workload, I envision some impact on end users and perhaps on Internet governance and policy, especially considering the possible interactions with Secure DNS. In this article I’ll briefly explain how end users will interact with Secure DNS (sometimes called DNSSEC) and on the possible ways that “DNS blocking” could affect those interactions.
Briefly, Secure DNS involves signing and verifying DNS signals to prove their authenticity. The details of how this works and how to make it work are ably described in the literature (http://dnssec.net/) so for the purpose of this article it’s enough to note that Secure DNS adds only two features to DNS and we are only able to use one of them at the moment.
The first new feature of Secure DNS is provable inauthenticity of forged DNS data and we use this today in the data path between authoritative name servers (for example the root or .COM servers) and recursive name servers (for example whatever your DHCP server told your laptop to use right now). By being able to prove that forged data is inauthentic, Secure DNS protects end users against DNS poisoning by “man in the middle” attackers. This is a good and useful feature and I’m glad we finally have it – but this feature alone would never have justified the incredible investments of time and money that have gone into the development and deployment of Secure DNS.
The second new feature of Secure DNS is provable authenticity of non-forged DNS data. We are not using this yet but it’s the real reason the DNS industry and Internet community has spent so many years and so much money developing Secure DNS. What this feature will ultimately bring us is new applications designed to behave differently in the face of provably authentic DNS data. Normal (unsecured) DNS data is inherently non-trustworthy and so no application whose needs are sensitive can afford to depend on the authenticity of data they retrieve from DNS.
Examples of “sensitive applications” are electronic banking or commerce, encrypted or signed messages, or anything else where the value of successfully poisoning or attacking DNS is higher than the (relatively low) cost of such a poisoning attack. Most current and contemplated “sensitive applications” use some other kind of security to assure themselves that the data they get from DNS does not lead them astray. Sadly, some applications which ought to worry about this kind of thing just blithely proceed and hope for the best – like when we use unsecured e-mail controlled by unsecured DNS to reset a supposedly secure web password. To open the way for new sensitive distributed applications and to better secure the sensitive distributed applications we have today, we needed Secure DNS.
But, in Secure DNS’s eventual and more important role of proving the authenticity of DNS data for sensitive applications we will need a rather large upgrade of everybody’s laptop, desktop, and mobile devices; almost every wireless or wired gateway in almost every home and in every hotel and coffee shop; and, most enterprise firewalls. This isn’t coming soon other than in isolated applications who have tricky ways to tunnel their Secure DNS needs over existing protocols, sort of like Bit Torrent does for peer to peer file transfers. So, as important as this feature is to the eventual success and relevance (and cost justification) of Secure DNS, it is not happening at the moment and it is not imminent. That means we have to consider it in our planning but we don’t have to worry about it today.
The distinction between the role of Secure DNS in proving that forged data is inauthentic vs. its role in proving that unforged data is authentic is vital to understanding the interaction between “DNS blocking” and Secure DNS because in one case we don’t care at all and in the other case we don’t care mostly.
For the purpose of this article I’m going to distinguish among several forms of “DNS blocking” since some forms are going to interact poorly with Secure DNS while other forms will pass Secure DNS like “ships in the night”.
DNS blocking that’s done by an ISP or enterprise in order to censor content or protect end users or to insert ads into the web experience occurs between the end user’s laptop or desktop or mobile device and whatever recursive DNS server that end user is depending on. Your recursive DNS server as you read this article was most likely assigned to you by DHCP along with your IP address unless you’ve taken explicit steps to override this setting and it’s possible for the operator of your network to prevent you from successfully overriding it – which they will do if your override is costing them revenue or if their government insists. I’ll refer to these forms of “DNS blocking” which occur inside a recursive name server collectively as “below-recursive policy”.
DNS blocking that’s done by an authority server operator or by a government using deliberate DNS poisoning will happen in between an authority server and a recursive server. One could imagine a country that rewrites DNS transactions at its international borders, or that injects false IP routes for well known authority name servers thus taking over their role, or demands that all recursive name server operators in the country use a specific “alternate root” name server system whose design and configuration included various kinds of censorship and overrides. I’ll refer to these forms of “DNS blocking” which occur outside a recursive name server collectively as “above-recursive policy”.
The distinction between below-recursive policy and above-recursive policy is vital in understanding the impact of “DNS blocking” on Secure DNS since some forms of “DNS blocking” can cause problems for Secure DNS whereas other forms don’t cause any problems at all.
Within the taxonomy now established, it’s now safe to say that most forms of above-recursive policy can be stopped or prevented or detected by Secure DNS in its mode of proving the inauthenticity of forged data. I say “most forms” because I can imagine a government requiring not only the use of an “alternate root” name server system also requiring the use of a private in-country Secure DNS key. Any situation involving an alternate root server system is outside the scope of this article.
In the more common case where the data being inserted by an above-recursive policy is not compatible with the Secure DNS key of a recursive DNS server, that data will appear to be forged and will therefore not be passed on to end users. This makes almost impossible to use above-recursive policy to send end users to “walled gardens” or other faked servers. However, if the goal of an above-recursive policy is to make some domain name unreachable, then any signal insertion or modification would achieve that goal by side effect – the result would merely be a secure failure rather than an unsecure failure. Any “DNS blocking” whose aim is to make something disappear can achieve that result no matter whether Secure DNS is in use or not. Secure DNS will change the details of the method but the end result will be the same – the domain that’s been “blocked” will in fact be unreachable.
Contrasting that we have below-recursive policy in which the recursive name server operator is deliberately telling the end user laptops and desktops and mobiles various kinds of lies in order to modify their behaviour, such as sending them to a walled garden to be told “that content has been censored for your safety” or sending them to an advertising server or sending them to a competing company. The possibilities are endless and as of today all of these possibilities are completely achievable because the end user devices aren’t doing Secure DNS yet and they are going to believe anything their recursive name server tells them. Until Secure DNS is deployed on every laptop and desktop and mobile device, all those devices will have to trust anything their recursive name servers tell them.
In the fullness of time when many end users are running Secure DNS in their laptops and desktops and mobiles then it will become impossible for a recursive name server operator or their government to insert forged data into the DNS but it will even in that case be possible to induce lookup failures. So, a below-recursive policy whose goal is to make certain domain names unreachable will always be successful no matter how completely the world deploys Secure DNS. I wish it weren’t so but if someone upstream of you can interfere with your traffic then you’ll have to use anti-censorship tools rather than Secure DNS to frustrate that interference.
I’ve been asked by several people whether ISC’s Response Policy Zone technology (referenced above) can be used to implement government mandated DNS blocking, for example to protect Hollywood against intellectual property theft or to protect children against against abuse by the distribution and viewing of Child Abuse Materials or to protect a society against content deemed dangerous by its government. Sadly my answer to this is a qualified “yes.”
I say “qualified” because while I can agree that it’s worth perturbing the whole Internet ecosystem to wipe out a domain that’s being used for the distribution of Child Abuse Materials I simply cannot agree that this level of perturbation is warranted for the protection of intellectual property. One form of perturbation that I’m especially concerned about is wiping out a domain name that’s being used for both malicious and non-malicious purposes. I could imagine wiping out twitter.com or facebook.com if they were hosting Child Abuse Materials and did not respond instantly to a lawful takedown order. I can’t countenance that level of ecosystem disruption if the content in question is a copy of the latest Hollywood blockbuster movie or video game. Worriedly, I do not think that this level of fine distinction and finesse would inevitably guide the hands of governments in control of mandated “DNS blocking”.
Nevertheless the raw uncomfortable truth of the matter is that any form of mandated “DNS blocking” whose goal is to make certain domain names unreachable will be indistinguishable from the result of a Secure DNS failure – and a failure is a failure is a failure. We need informed debate on the question of mandated “DNS blocking” but we should be true to the facts and the details. Secure DNS and “DNS blocking” are ships in the night at the moment and whenever the goal of “DNS blocking” is merely domain name disappearance and not content insertion then “DNS blocking” will not break Secure DNS or even slow it down.
- By Adib Behjat on February 18, 2011
In response to our customers and colleagues, ISC has chosen to remove the RTT Banding feature from BIND 9, starting with BIND 9.8.0. Other supported versions will have RTT Banding removed in their next releases.
BIND 9.8.0 is scheduled to go out on March 1st, 2011. 9.8.1 will follow around a month later.
Prior to implementing RTT Banding, BIND 9 used a simple method of measurement with decay to ensure that the best known server is used to resolve queries. If one server for a domain was 10 ms away and another was 80 ms, BIND 9 would use the 10 ms server most often, but still periodically try the one that was further away. This provides a good mix of performance and adaptability in changing network situations.
About RTT Banding
RTT Banding was a security tool intended to add a small amount of randomness to make spoofing harder. This feature is implemented in BIND 9.5.x, 9.6.x, and 9.7.x versions of BIND. RTT Banding is a recursive server feature.
RTT stands for “Round Trip Time” – the time it takes for a question to reach a remote DNS server, and for the answer to come back. Typical times are within a small number of milliseconds for servers close by, up to 10 ms for servers at exchange points or within the same local area, and around 60 to 80 ms for US east to west coast traffic.
RTT Banding relies on a domain having at least two name servers, and that those name servers fall within the same band. If a domain has two name servers both of which fall into the first 0 – 128 ms band, an attacker cannot know which server was used for resolution, thus making a spoofing attack two times harder. If a domain has four servers in the same band, an attack is four times harder.
Compared to other anti-spoofing prevention mechanisms, this two to four times increase is minor. Port randomization can make an attacker’s likelihood of success between 4,000 and 65,000 times lower alone.
Why Banding is Bad
A very common scenario is for a large content provider to spend some time optimizing their DNS service. They may choose to install authoritative servers closer to customers to make DNS resolution as fast as possible.
RTT Banding defeats the benefit of locating servers closer to customers as queries may go to remote servers as frequently as to those which are closer.
For example, if a content provider has two servers which BIND may choose from, one 10 ms away and another 80 ms away, which is typical for US coast-to-coast traffic, with banding the average latency for queries is 45 ms. Without banding it would be slightly higher than 10 ms.
The minor security improvement experienced by using RTT Banding, compared to its serious effect on performance, has persuaded ISC to remove this feature from BIND 9.
- By Adib Behjat on February 15, 2011
Open Source is not unsupported
It’s a common misconception that open source software means it’s unsupported, that if you want to have 7×24 support you have to buy commercial software. Nothing could be further from the truth.
The reality is that open source software is written by professional coders, is fully production quality and support is available. The major difference between commercial software and open source software is this:
- With commercial software, you pay for the use of the software and you also have to pay for 7×24 support. Usually, you have to pay for the software itself on an annual basis or pay for every upgrade. And even paying for software fees and support won’t get you access to the source code.
- With open source software, you get the software for free, including access to the source code. And many open source companies like the Internet Systems Consortium (ISC) offer paid support for their products.
- Commercial software vendors have large marketing and sales staffs and spend lots of money on advertising. Open source companies (including ISC) tend to do a poor job at letting the world know what we can offer. We use our money to hire good technical staff.
Who needs support when you can look at the source code?
For many companies, the source code itself, along with manual pages and documentation included with the source code may be enough. Their needs are simple and it may not be business critical that they don’t have someone to call at 3am when something breaks.
For anyone who has a critical business need for the software to “just work”, or to comply with auditing requirements, such as Payment Card Industry (PCI) or Sarbanes-Oxley (SOX) requirements, that is not enough. These companies need 7×24 support, security and bug fixes and possibly even custom code.
ISC’s managed open source model
ISC has years of experience writing code that keeps the Internet running, including DNS software (BIND) and DHCP software. We have made our code and our expertise available to the Internet in a number of ways that give companies the options they need to use open source code in business critical functions.
We do this as part of our public benefit mission. We also do it because the more people who use our code and look at the source, the more likely it is that bugs are found, security flaws are exposed and fixed and useful features are added. It’s evolution and a rich genetic background at work and everyone on the Internet benefits.
What is BIND
BIND is the most widely used DNS software on the Internet. It is used by Internet infrastructure companies, commercial organizations, consumer ISPs and in a variety of specialized applications. It is an open source product, so anyone can download and use it at no cost. The open source license means that anyone can submit code back to ISC or make their own modifications, with no obligation to submit these changes to ISC.
How can you get support for BIND?
You’ve decided that you like the quality and flexibility of open source but stable DNS is a core business requirement. ISC can help you through a variety of means, including:
- Support through the BIND Open Source Community
- Professional DNS Operations Communities
- Individual and Organizational Membership Forums
- Contracted Professional Support
- Architecture, Design, and Configuration Consulting
- New Technology Deployment Packages
- Value-Added Commercial Implementations
- bind-announce – The BIND Announcement mailing list is where ISC announces important events for users of BIND, such as new releases, events and advisories. Subscribe here. You can browse the archives here.
- bind-users – The BIND Users list is an open discussion of all matters relating to bind, for users by users. This is also the main community support mailing list. Subcribe here and browse/search the archives here.
- bind9-bugs – This is the email used to submit bug reports with BIND. Anyone can submit a bug report to ISC. All bug reports are reviewed and fixes are put into new releases of BIND. This is also where anyone can report a security issue with BIND. Email here.
Professional DNS Operations Communities. DNS is critical to what most people consider the internet. Email addresses and names of web sites have to resolve or “the internet is broken”. The DNS is very resilient and redundant. However, for it to work, the operators of this infrastructure have to work together very closely. There is an organization that brings together these key operators, implementers and researchers who keep it all running: DNS Operations, Analysis, and Research Center (DNS-OARC).
ISC strongly encourages all DNS operators to join the open DNS-OARC operating mailing lists, become a member of DNS-OARC, and actively participate in the organization’s activities. For those networks who operate large and supercritical DNS networks, ISC recommends subscribing to the secure chat rooms. Real time operational issues having an impact on the global DNS are frequently resolved through these live and secure chat rooms.
Membership Forums – ISC also has Membership Forums, for both organizations and individuals, where you can get more involved with BIND development, interact with ISC developers and get valuable benefits, including early warning of security advisories and early releases of new code. Click here for more information, or click here to apply for membership.
Professional Support – ISC provides professional support for BIND. This provides expert support in configuring and maintaining BIND, priority bug fixes, escalation to engineering and 7×24 technical support. Response times and coverage hours vary by level of support. Click here for more information.
Consulting – ISC can help you figure out how to solve your DNS problems. Perhaps BIND can already do what you need but you don’t know how. Possibly there is some feature or option you need that stock BIND doesn’t provide. We can offer configuration help, architecture design and even custom code development to solve your need. Click here to get more information.
New Technology Deployment - Technology is always evolving. Your deployment may have worked in the past but you need to deploy secure DNS (DNSSEC) or add IPv6 capability to your network. ISC has engineers and operators who have developed and implemented new Internet standards available to help you determine your needs and a solid deployment strategy. Click here to get more information.
Training – ISC has hands on training in DNS, DNSSEC, DHCP and IPv6. Learn from the experts how to configure and deploy these technologies, with lecture, discussions and hands-on labs. We have a public training schedule but also offer private classes, done at your site and tailored to your needs. Complete this form for more information.
How can I help keep open source software alive and viable?
ISC has a full time staff of programmers maintaining BIND and our other software. That means that they don’t do this as a part time activity, juggled with a day job. It also means that we need to find ways to pay them.
ISC is a non-profit public benefit corporation. We accept tax deductible donations, grants and contractual support. We also take contributions from organizations, both unencumbered grants and for specific products or features.
Organizations who have a specific new feature they would like developed for their operation can ear mark a grant to ISC for that feature. The new feature will be included in future BIND releases. This benefits the Internet, while also solving the granting organization’s problem in a timely manner. ISC would also support the new feature via contractual support.
Click here for more information on grants for custom development.