Press Release

  • End to Bandaids for Broken EDNS

    By vicky risk on March 19, 2018

    Extension Mechanisms for DNS were standardized in 2013

    Despite this, there continue to be non-compliant implementations.  DNS software developers have tried to solve the problems with the interoperability of the DNS protocol and especially its EDNS extension (RFC 6891 standard) by various workarounds for non-standard behaviors. However, temporary workarounds are not a long-term solution. These workarounds excessively complicate DNS software and are now also negatively impacting the DNS as a whole. The most obvious problems caused by these workarounds are slower responses to DNS queries and the difficulty of deploying new DNS protocol features. Some of these new features (e.g. DNS Cookies) would help reduce DDoS attacks based on DNS protocol abuse.

    Open source DNS software developers agree

    To prevent further deterioration of DNS services, the developers of four major open source DNS software systems have agreed to discontinue support for these non-standard solutions. All new releases of DNS software from CZ.NIC, ISC, NLnetlabs, and PowerDNS after February 1, 2019 will not contain workaround code for non-compliance with EDNS standard RFC 6891.

    Test your domains and servers

    You can test your domains and authoritative DNS servers using the web application A test result with a green message “All Ok” indicates that you are already prepared for the changes and do not need to do anything. If the result of the test is anything else than the green message “All Ok”, please update your DNS software. If you are using the latest version of your server software, please contact its developer and ask for a fix. In this case, we recommend attaching a link to the test result, which contains technical details, to your message.

    Note to DNS software vendors

    Please note that full EDNS support (RFC 6891) in DNS software is not mandatory.

    In case you decide not to support EDNS it is mandatory to correctly answer queries with EDNS in accordance with RFC 6891 section 7, i.e. namely to answer with valid DNS message containing RCODE=FORMERR. Please follow the RFC mentioned above while implementing this. Thank you!

    Non-compliant domains may become unavailable

    Domains served by DNS servers that, according to the above mentioned tests, are not compliant with the standard, will not function reliably after February 1, 2019, and may become unavailable.

    We are aware of the importance of this change and we want to inform as many people as possible. We are going to keep drawing attention to this change, which will begin to apply in less than a year. If you have the ability to spread this information to people who are in charge of networks and DNS servers, we will be glad if you shared the link to this blog post. Our goal is a reliable and properly functioning DNS that cannot be easily attacked.

    Adapted (with permission) from a blog post at CZNIC by:
  • ISC Receives Mozilla MOSS Award

    By vicky risk on October 4, 2016

    We are thankful that Mozilla chose to give a MOSS award to ISC to help fund development of the Kea DHCP server, through the Mozilla Foundational Technology track.  This is a wonderful program, through which Mozilla gives back to the Internet community by sponsoring development of the open source that everyone can use.

    Kea is modern software that we hope will eventually replace the extremely popular, but also very mature, ISC DHCP, also known as dhcpd. DHCP software is classic infrastructure.  People expect that DHCP software will be available in their operating system, but few people wonder where it comes from, or how the development is funded.  Kea is already packaged for most major Linux and Unix operating systems, but is still missing a few very desirable features.

    ISC’s MOSS award was for $100,000, which we will use to support design and development of a management api, and a secure remote management client.  Remote management is an important feature, one that is frequently requested by prospective users.  We have a preliminary requirements document posted in the Kea project wiki and are starting work on a design.

    Kea is already a fully functional DHCPv4 and DHCPv6 server.  We have just released Kea version 1.1, which greatly expanded support for leveraging an external database for host reservations, and added a flexible client classification system. Kea is accepting community contributions on Github, with significant contributions enabling initial support for a Cassandra database backend and lightweight DHCPv4 over v6 in version 1.1.

    We sometimes joke that ISC puts the “non” in “non-profit.”  ISC has been funding Kea internally, and with 3+ developers and a test engineer, it is a significant effort.  We are offering Kea support contracts, which we hope will eventually fund on-going maintenance, but grants like this are essential to add major new functionality, to continue to create open source infrastructure for the future.  We look forward to spending this award money on adding an important feature users are asking for to the Kea open source.

  • Kea 1.1 Released

    By vicky risk on October 3, 2016

    Kea 1.1 is available!

    We are please to announce the availability of Kea 1.1.  Kea is ISC modern DHCP server, which brings new functionality to the datacenter, and any ISP or enterprise who needs to tie dynamic host control into external provisioning systems.

    New features in Kea 1.1 include:

    Host Reservations

    Kea 1.0 contained limited support for storing host reservations in the database backend.  Kea 1.1.0 has expanded that
    capability, allowing host reservations to be stored in a MySQL or PostgreSQL database. In particular, Kea 1.1.0:
    – Adds host reservation (DHCPv4 and DHCPv6) using the PostgreSQL backend.
    – Adds host reservation for DHCPv6 to the existing MySQL support.
    – Significantly extends the existing host reservation capabilities to include reservations of specific DHCP options, reservations of siaddr, sname, and file fields within DHCPv4 messages, and reservations of multiple IPv6 addresses/prefixes.
    – Allows the MySQL or PostgreSQL host reservation database to be configured read-only, in which case Kea will be able to retrieve reservations
    from it, but not insert or update existing reservations. This feature is useful when a database (or database view) exists for the particular deployment and the administrator doesn’t want to grant read-write access for
    security reasons.

    Client Classification

    In Kea 1.1 the client classification system has been expanded. A class definition contains a name and a test expression of
    arbitrary complexity; if the test expression evaluates to “true” the client is a member of that class.  A client may be a member of multiple
    classes and can acquire options from different classes.   If the configuration contains multiple definitions for data for an option in two or more of the global, class, subnet or host entries, the server will choose the definition from the most specific entry.

    There are a number of objects and operators available for use in the test
    – Operators include: equal, not, and, or, substring, concat
    – Objects include:
    – literals: string, hexadecimal, IP address and integer
    – options: existence and content
    – relay options for DHCPv4 and DHCPv6: existence and content
    – subfields within vendor and vendor class options: existence, enterprise-id value and content
    – selected fields from DHCPv4 and DHCPv6 packets
    – Classes may be used to select subnets
    – Classes and class specific subnets may contain option data to serve to
    clients within that class

    Hook Library Parameters

    It is now possible to specify parameters for hook libraries in the Kea configuration file. In earlier versions of Kea, hook library authors had to use a external mechanism (such as file of a known name) to pass information across.


    RFC7341 defines an architecture that allows dual-stack clients to communicate with DHCPv4 server in IPv6-only networks. Kea 1.1 introduces support for this mode of operation. It requires running both DHCPv4 and DHCPv6 servers in special mode, where DHCPv6 component does not allocate anything, but decapsulates incoming DHCPv4 messages, sends the to the DHCPv4 server and then relay back the responses.

    Cassandra Database Backend

    Kea 1.1.0 has added preliminary support for Cassandra as a database backend.  In this release of Kea it can only
    be used to store lease information, it is not able store host reservations. Cassandra support is currently considered experimental. Use with caution.

    MPL 2.0 License

    Kea 1.1.0 has been released under the Mozilla Public License, version 2.0.


    Professional support for Kea is available from ISC. Free best-effort support is provided by our user community via a mailing list. Information on all
    public email lists is available at

    If you have any comments or questions about working with Kea, please share them on the Kea Users List
    Bugs and feature requests may be submitted via the ticket tracking system at

  • 2014 Annual Report

    By vicky risk on July 17, 2015

    Letter from the President


    We are now a trimmer and more functional organization, with financial controls, stability and predictability.

    We determined that BIND revenues had been subsidizing our other efforts, so we put more back into BIND, adding three DNS engineers in early 2015. On the operations side, we are cutting back on subsidized programs that no longer make sense, like commercial hosting and commercial SNS, while refocusing our efforts on public benefit F-Root and ccTLD DNS publishing. We have had virtually no personnel turnover in more than a year since our reductions in force, and our customers and partners have stuck with us, too, maintaining a 93% renewal rate.

    Going forward, ISC continues to balance our public benefit mission with financial stability; we are working cooperatively with other open source providers to provide commercial support for products like NLnet Lab’s Unbound and are in talks to add more. We’ve removed restrictions on our Knowledge Base so that everyone, not just paying customers, can access our technical documentation, and added 36 new feature articles and a comprehensive BIND DNSSEC guide just in 2014.

    We are reaching out to our external contributors, accepting patches as a greater priority, and granting accounts in our bug tracking system to our frequent contributors. We opened public access read-only GITs for BIND and ISC DHCP, and posted our new DHCP project, Kea, on Github. We continue making significant contributions to industry standards development and have strong roles in NANOG, the IETF, RIPE NCC, DNS/OARC, ISOC, and ICANN to name a few.

    ISC carries no debt, is approximately break even, and has sufficient financial reserves to carry us through normal downturns in the business. We are proud of our past and excited about our future. We are aggressively in discussions around the globe to research emerging problems we can help solve and playing fields we can help level. We aren’t going anywhere but forward. We hope you will consider supporting our mission financially and furthering our common goals.



    Jeff Osborn

    President, Internet Systems Consortium

    Attached: 2014 Annual Report

  • ISC is now offering Advance Security Notification for Unbound and NSD

    By vicky risk on November 10, 2014

    ISC has signed a memo of understanding with NLnet Labs, makers of Unbound and NSD, to collaborate in providing support to users of our DNS software. NSD is a popular alternative to BIND for authoritative DNS services, and Unbound is a high-performance recursive resolver. As a first step in this collaboration, ISC is now selling advance security notification of vulnerabilities in NSD and Unbound, the same service we have been offering for ISC’s BIND and DHCP. ISC will cover the expense of the administrative overhead, and pass the entire amount paid for the NLNet Labs portion off to them.

    As a bonus for organizations already supporting ISC’s open source, existing BIND ASN subscribers will automatically be given the Unbound and NSD ASN for the remainder of their current contract with ISC. When their contract is up for renewal, they will be offered the opportunity to add Unbound and NSD to their BIND ASN agreement.

    We hope this is the beginning of a trend towards greater cooperation among providers of open source that is critical to the Internet. As we all saw with the Heartbleed incident, the mere fact that open source is critical to the Internet does not mean that it’s development and maintenance is funded or supported by the community. Getting adequate support requires an organization to solicit funding, provide and administer services based on that software.

    This in no way represents a consolidation of software or technology; conversely, it’s an attempt to more strongly fund diverse offerings. We are leveraging the administrative overhead, and offering a united front to promote funding open source. Please join us by subscribing to Advance Security Notifications for BIND, Unbound and NSD, or by making a donation to NLNET Labs, either directly or through ISC. To inquire about subscribing or donating, fill out this web form, or email to info at ISC dot org.

    Thank you.

Last modified: January 30, 2014 at 11:49 am