Categories
Networking Security xISP

Updating your Bind DNS for latest trust anchors

A little Background on the rollover

From: https://www.icann.org/resources/pages/ksk-rollover/#overview
ICANN
 is planning to perform a Root Zone Domain Name System Security Extensions (DNSSEC) KSK rollover as required in the Root Zone KSK Operator DNSSEC Practice Statement [TXT, 99 KB].

Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root’s “trust anchor.” The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet’s DNS.

Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.

If you are running bind the quickest way to check is this:

If your configuration shows dnssec-validation yes;, you must change it to dnssec-validation auto;and restart your server before taking the steps below. This is in your named.conf

Categories
xISP

Client subnet in DNS requests

Some Light Reading:
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00

Many Authoritative nameservers today return different replies based
   on the perceived topological location of the user.  These servers use
   the IP address of the incoming query to identify that location.
   Since most queries come from intermediate recursive resolvers, the
   source address is that of the recursive rather than of the query
   originator.

   Traditionally and probably still in the majority of instances,
   recursive resolvers are reasonably close in the topological sense to
   the stub resolvers or forwarders that are the source of queries.  For
   these resolvers, using their own IP address is sufficient for
   authority servers that tailor responses based upon location of the
   querier.

   Increasingly though a class of remote recursive servers has arisen
   that serves query sources without regard to topology.  The motivation
   for a query source to use a remote recursive server varies but is
   usually because of some enhanced experience, such as greater cache
   security or applying policies regarding where users may connect.
   (Although political censorship usually comes to mind here, the same
   actions may be used by a parent when setting controls on where a
   minor may connect.)  When using a remote recursive server, there can
   no longer be any assumption of close proximity between the originator
   and the recursive, leading to less than optimal replies from the
   authority servers.

   A similar situation exists within some ISPs where the recursive
   servers are topologically distant from some edges of the ISP network,
   resulting in less than optimal replies from the authority servers.

   This draft defines an EDNS0 option to convey network information that
   is relevant to the message but not otherwise included in the
   datagram.  This will provide the mechanism to carry sufficient
   network information about the originator for the authority server to
   tailor responses.  It also provides for the authority server to
   indicate the scope of network addresses that the tailored answer is
   intended.  This EDNS0 option is intended for those recursive and
   authority servers that would benefit from the extension and not for
   general purpose deployment.  It is completely optional and can safely
   be ignored by servers that choose not to implement it or enable it.

   This draft also includes guidelines on how to best cache those
   results and provides recommendations on when this protocol extension
   should be used.

For those of you running BIND here is some practical information
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#whats-edns0-all-about

Categories
Networking

Change to H.ROOT-SERVERS.NET

Posted to NANOG
This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.

The new IPv4 address for this authority is 198.97.190.53.

The new IPv6 address for the authority is 2001:500:1::53.

This change is anticipated to be implemented in the root zone on 1 December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).

We encourage operators of DNS infrastructure to update any references to the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root “hints” file. This should be updated with
the new IP addresses.

New hints files will be available at the following URLs once the change has
been formally executed on December 1:

http://www.internic.net/domain/named.root
http://www.internic.net/domain/named.cache

The old IPv4 address will continue to work for six months after the
transition (until 1 June 2016), at which point it will be retired from
service. The address will remain under the control of the Army Research
Laboratory, never to be used again for DNS service. The old IPv6 address
will continue to work indefinitely, but may ultimately be retired from
service.

Simultaneous to the retirement of the old address on June 1, 2016, the
ASN for H-root will change from 13 to 1508.

You can monitor the transition of queries to the new addresses at the
following URL:

http://h.root-servers.org/old_vs_new.html