DNS news and blogs

 

DNS and IP Register news

CVE-2024-1737 - RRset limits in zones

2024-07-25 - News - Ian Clark

The ISC have made a breaking change to BIND in version 9.20.0.

We've updated the stealth secondary sample.named.conf with the required change, otherwise if you receive "too many records" errors you can add

max-records-per-type 0

to misbehaving zones.

This should not be a major problem with the security issue as you should not have too many clients, and there are only a few names with a large number of associated RRs.

Managed Zone Service CNAME relaxation

2020-06-03 - News - Tony Finch

The MZS is our service for registering non-cam.ac.uk domains.

Underscores are now allowed in the names and targets of CNAME records so that they can be used for non-hostname purposes.

Stealth secondaries and Cisco Jabber

2020-04-30 - News - Tony Finch

The news part of this item is that I've updated the stealth secondary documentation with a warning about configuring servers (or not configuring them) with secondary zones that aren't mentioned in the sample configuration files.

One exception to that is the special Cisco Jabber zones supported by the phone service. There is now a link from our stealth secondary DNS documentation to the Cisco Jabber documentation, but there are tricky requirements and caveats, so you need to take care.

The rest of this item is the story of how we discovered the need for these warnings.

Read more ...

Release announcement: nsdiff-1.79

2020-04-27 - News - Tony Finch

I have released a new version of nsdiff.

This release removes TYPE65534 records from the list of DNSSEC-related types that nsdiff ignores.

TYPE65534 is the private type that BIND uses to keep track of incremental signing. These records usually end up hanging around after signing is complete, cluttering up the zone. It would be neater if they were removed automatically.

In fact, it's safe to try to remove them using DNS UPDATE: if the records can be removed (because signing is complete), thy will be; if they can't be removed then they are quietly left in place, and the rest of the update is applied.

After this change you can clean away TYPE65534 records using nsdiff or nsvi. In our deployment, nspatch runs hourly and will now automatically clean TYPE65534 records when they are not needed.

Firefox and DNS-over-HTTPS

2020-02-27 - News - Tony Finch

The latest release of Firefox enables DoH (encrypted DNS-over-HTTPS) by default for users in the USA, with DNS provided by Cloudflare. This has triggered some discussion and questions, so here's a reminder of what we have done with DoH.

Read more ...

DNS server resilience and network outages

2020-02-18 - News - Tony Finch

Our recursive DNS servers are set up to be fairly resilient. Each server is physical hardware, so that they only need power and networking in order for the DNS to work, avoiding hidden circular dependencies.

We use keepalived to determine which of the physical servers is in live service. It does two things for us:

  • We can move live service from one server to another with minimal disruption, so we can patch and upgrade servers without downtime.

  • The live DNS service can recover automatically from things like server hardware failure or power failure.

This note is about coping with network outages, which are more difficult.

Read more ...

SHA-1 and DNSSEC validation

2020-02-14 - News - Tony Finch

This is a follow-up to my article last month about SHA-1 chosen-prefix collisions and DNSSEC.

Summary

DNSSEC validators should continue to treat SHA-1 signatures as secure until DNSSEC signers have had enough time to perform algorithm rollovers and eliminate SHA-1 from the vast majority of signed zones.

Read more ...

Managed Zone Service improvements

2020-01-24 - News - Tony Finch

The MZS is our service for registering non-cam.ac.uk domains.

The web user interface for the MZS has moved to https://mzs.dns.cam.ac.uk/; the old names redirect to the new place.

You can now manage TXT records in your zones in the MZS.

The expiry date of each zone (when its 5 year billing period is up) is now tracked in the MZS database and is visible in the web user interface.

SHA-1 chosen prefix collisions and DNSSEC

2020-01-09 - News - Tony Finch

Thanks to Viktor Dukhovni for helpful discussions about some of the details that went in to this post.

On the 7th January, a new more flexible and efficient collision attack against SHA-1 was announced: SHA-1 is a shambles. SHA-1 is deprecated but still used in DNSSEC, and this collision attack means that some attacks against DNSSEC are now merely logistically challenging rather than being cryptographically infeasible.

As a consequence, anyone who is using a SHA-1 DNSKEY algorithm (algorithm numbers 7 or less) should upgrade. The recommended algorithms are 13 (ECDSAP256SHA256) or 8 (RSASHA256, with 2048 bit keys).

Update: I have written a follow-up note about SHA-1 and DNSSEC validation

Read more ...

SHA-1 is a shambles

2020-01-07 - News - Tony Finch

Happy new (calendar) year!

Our previous news item on DNS delegation updates explained that we are changing the DNSSEC signature algorithm on all UIS zones from RSA-SHA-1 to ECDSA-P256-SHA-256. Among the reasons I gave was that SHA-1 is rather broken.

SHAmbles

Today I learned that SHA-1 is a shambles: a second SHA-1 collision has been constructed, so it is now more accurate to say that SHA-1 is extremely broken.

The new "SHAmbles" collision is vastly more affordable than the 2017 "SHAttered" collision and makes it easier to construct practical attacks.

DNSSEC implications

As well as the UIS zones (which are now mostly off RSA-SHA-1), Maths and the Computer Lab have a number of zones signed with RSA-SHA-1. These should also be upgraded to a safer algorithm. I will be contacting the relevant people directly to co-ordinate this change.

I have written some more detailed notes on the wider implications of SHA-1 chosen prefix collisions and DNSSEC.

DNS delegation updates

2019-12-18 - News - Tony Finch

Season's greetings! I bring tidings of great joy! A number of long term DNS projects have reached a point where some big items can be struck off the to-do list.

This note starts with two actions item for those for whom we provide secondary DNS. Then, a warning for those who secondary our zones, including stealth secondaries.

Read more ...

Jackdaw Apache upgrade

2019-11-21 - News - Tony Finch

This afternoon our colleagues who run Jackdaw will upgrade the web server software. (The IP Register database is an application hosted on Jackdaw, alongside the user-admin database and a few others.) This will entail a brief outage for the IP Register web user interface. The DNS will not be affected.

BIND security release

2019-10-17 - News - Tony Finch

Last night ISC.org published security releases of BIND.

For full details, please see the announcement messages: https://lists.isc.org/pipermail/bind-announce/2019-October/thread.html

The vulnerabilities affect two features that are new in BIND 9.14, mirror zones and QNAME minimization, and we are not affected because we are not using either feature.

Read more ...

Upcoming change to off-site secondary DNS

2019-10-01 - News - Tony Finch

This notice is mainly for the attention of those who run DNS zones for which the UIS provides secondary servers.

Since 2015 we have used the Internet Systems Consortium secondary name service (ISC SNS) to provide off-site DNS service for University domains.

ISC announced yesterday that the SNS is closing down in January 2020, so we need alternative arrangements.

We have not yet started to make any specific plans, so this is just to let you know that there will be some changes in the next few months. We will let you know when we have more details.

Firefox and DNS-over-HTTPS

2019-09-19 - News - Tony Finch

We are configuring our DNS to tell Firefox to continue to use the University's DNS servers, and not to switch to using Cloudflare's DNS servers instead.

Most of this article is background information explaining the rationale for this change. The last section below gives an outline of the implementation details.

Read more ...

Brexit and .eu domain names (update)

2019-07-22 - News - Tony Finch

There has been a change to the eligibility criteria for .eu domain names related to Brexit.

Previously, eligibility was restricted to (basically) being located in the EU. The change extends eligibility for domains owned by individuals to EU citizens everywhere.

Organizations in the UK that have .eu domain names will still need to give them up at Brexit.

Thanks to Alban Milroy for bringing this to our attention.

DNS update confirmations

2019-06-27 - News - Tony Finch

You might have noticed that the IP Register ops pages on Jackdaw now have a note in the title stating when the last DNS update completed. (Updates start at 53 minutes past each hour and usually take a couple of minutes.)

Occasionlly the update process breaks. It is written fairly conservatively so that if anything unexpected happens it stops and waits for someone to take a look. Some parts of the build process are slightly unreliable, typically parts that push data to other systems. Many of these push actions are not absolutely required to work, and it is OK to retry when the build job runs again in an hour.

Over time we have made the DNS build process less likely to fail-stop, as we have refined the distinction between actions that must work and actions that can be retried in an hour. But the build process changes, and sometimes the new parts fail-stop when they don't need to. That happened earlier this week, which prompted us to add the last update time stamp, so you a little more visibility into how the system is working (or not).

DNS-over-HTTPS and encrypted SNI

2019-06-24 - News - Tony Finch

Recent versions of Firefox make it easier to set up encrypted DNS-over-HTTPS. If you use Firefox on a fixed desktop, go to Preferences -> General -> scroll to Network Settings at the bottom -> Enable DNS over HTTPS, Custom: https://rec.dns.cam.ac.uk/. (Our DNS servers are only available on the CUDN so this setting isn't suitable for mobile devices.)

Very recent versions of Firefox also support encrypted server name indication. When connecting to a web server the browser needs to tell the web server which site it is looking for. HTTPS does this using Server Name Indication, which is normally not encrypted unlike the rest of the connection. ESNI fixes this privacy leak.

To enable ESNI, go to about:config and verify that network.security.esni.enabled is true.

MZS web site upgrade failed

2019-06-20 - News - Tony Finch

[ This problem has been resolved, with help from Peter Heiner. Thanks! ]

Unfortunately the Managed Zone Service operating system upgrade this evening failed when we attempted to swap the old and new servers. As a result the MZS admin web site is unavailable until tomorrow.

DNS service for MZS domains is unaffected.

We apologise for any inconvenience this may cause.

BIND 9.14.3 and CVE-2019-6471

2019-06-20 - News - Tony Finch

Last night, isc.org announced patch releases of BIND

This vulnerability affects all supported versions of BIND.

Hot on the heels of our upgrade to 9.14.2 earlier this week, I will be patching our central DNS servers to 9.14.3 today. There should be no visible interruption to service.

SACK panic

2019-06-18 - News - Tony Finch

I have applied a workaround for the Linux SACK panic bug (CVE-2019-11477) to the DNS and other servers, as a temporary measure until they can be patched properly later today.

MZS web site upgrade, Thurs 20 June

2019-06-13 - News - Tony Finch

On Thursday 20th June between 17:00 and 19:00, the Managed Zone Service web site will be unavailable for a few minutes while its operating system is upgraded. (This will not affect the DNS for MZS domains.)

DNS server upgrades, Tues 18 June

2019-06-12 - News - Tony Finch

On Tuesday 18th June our central DNS resolvers will be upgraded from BIND 9.12.4-P1 to BIND 9.14.2.

Read more ...

BIND 9.12.4-P1 and Ed25519

2019-04-25 - News - Tony Finch

Last night, isc.org announced patch releases of BIND

I have upgraded our DNS servers to 9.12.4-P1 to address the TCP socket exhaustion vulnerability.

At the same time I have also relinked BIND with a more recent version of OpenSSL, so it is now able to validate the small number of domains that use the new Ed25519 DNSSEC algorithm.

BIND 9.12.3-P4 and other patch releases

2019-02-27 - News - Tony Finch

Last week, isc.org announced patch releases of BIND

I have upgraded our DNS servers to 9.12.3-P4 to address the memory leak vulnerability.

Release announcement: nsdiff-1.77

2019-01-29 - News - Tony Finch

I have released a new version of nsdiff.

This release adds CDS and CDNSKEY records to the list of DNSSEC-related types that are ignored, since by default nsdiff expects them to be managed by the name server, not as part of the zone file. There is now a -C option to revert to the previous behaviour.

Old recdns.csx names have been abolished

2019-01-28 - News - Tony Finch

As previously announced, the old recursive DNS server names have been removed from the DNS, so the new names are now canonical.

131.111.8.42  recdns0.csx.cam.ac.uk -> rec0.dns.cam.ac.uk
131.111.12.20 recdns1.csx.cam.ac.uk -> rec1.dns.cam.ac.uk

A digression for the historically curious: the authdns and recdns names date from May 2006, when they were introduced to prepare for separating authoritative and recursive DNS service.

Until 2006, 131.111.8.42 was known as chimaera.csx.cam.ac.uk. It had been our primary DNS server since September/October 1995. Before then, our DNS was hosted on CUS, the Central Unix Service.

And 131.111.12.20 had been known as c01.csi.cam.ac.uk (or comms01) since before my earliest records in October 1991.

Happenings in DNS

2019-01-18 - News - Tony Finch

A couple of items worth noting:

DNS flag day

The major DNS resolver providers have declared February 1st to be DNS Flag Day. (See also the ISC blog item on the DNS flag day.)

DNS resolvers will stop working around broken authoritative DNS servers that do not implement EDNS correctly. The effect will be that DNS resolution may fail in some cases where it used to be slow.

The flag day will take effect immediately on some large public resolvers. In Cambridge, it will take effect on our central resolvers after they are upgraded to BIND 9.14, which is the next stable branch due to be released Q1 this year.

I'm running the development branch 9.13 on my workstation, which already includes the Flag Day changes, and I haven't noticed any additional breakage - but then my personal usage is not particularly heavy nor particularly diverse.

Old DNSSEC root key revoked

Last week the old DNSSEC root key was revoked, so DNSSEC validators that implement RFC 5011 trust anchor updates should have deleted the old key (tag 19036) from their list of trusted keys.

For example, on one of my resolvers the output of rndc managed-keys now includes the following. (The tag of the old key changed from 19036 to 19164 when the revoke flag was added.)

name: .
keyid: 20326
    algorithm: RSASHA256
    flags: SEP
    next refresh: Fri, 18 Jan 2019 14:28:17 GMT
    trusted since: Tue, 11 Jul 2017 15:03:52 GMT
keyid: 19164
    algorithm: RSASHA256
    flags: REVOKE SEP
    next refresh: Fri, 18 Jan 2019 14:28:17 GMT
    remove at: Sun, 10 Feb 2019 14:20:18 GMT
    trust revoked

This is the penultimate step of the root key rollover; the final step is to delete the revoked key from the root zone.

Old recdns.csx names to be abolished

2019-01-17 - News - Tony Finch

On Monday 28th January after the 13:53 DNS update, the old recursive DNS server names will be removed from the DNS. They have been renamed like this:

131.111.8.42  recdns0.csx.cam.ac.uk -> rec0.dns.cam.ac.uk
131.111.12.20 recdns1.csx.cam.ac.uk -> rec1.dns.cam.ac.uk

Although there should not be much that depends on the old names, we are giving you a warning in case things like monitoring systems need reconfiguration.

This is part of the ongoing DNS server reshuffle project.

Brexit and .eu domain names

2019-01-09 - News - Tony Finch

This message is for the attention of anyone who has used a third-party DNS provider to register a .eu domain name, or a domain name in another European country-class two-letter top-level domain.

Last year, EURID (the registry for .eu domain names) sent out a notice about the effect of Brexit on .eu domain names registered in the UK. The summary is that .eu domains may only be registered by organizations or individuals in the EU, and unless any special arrangements are made (which has not happened) this will not include the UK after Brexit, so UK .eu domain registrations will be cancelled.

https://eurid.eu/en/register-a-eu-domain/brexit-notice/

Other European country-class TLDs may have similar restrictions (for instance, Italy's .it).

Sadly we cannot expect our government to behave sensibly, so you have to make your own arrangements for continuity of your .eu domain.

The best option is for you to find one of your collaborators in another EU country who is able to take over ownership of the domain.

We have contacted the owners of .eu domains registered through our Managed Zone Service. Those who registered a .eu domain elsewhere should contact their DNS provider for detailed support.

Edited to add: Thanks to Elliot Page for pointing out that this problem may apply to other TLDs as well as .eu

Edited to add (2019-07-22): There has been an update to the .eu eligibility criteria.

More DNS server rebuilds

2018-12-19 - News - Tony Finch

As announced last week the remaining authoritative DNS servers will be upgraded this afternoon. There will be an outage of authdns1.csx.cam.ac.uk for several minutes, during which our other authoritative servers will be available to provide DNS service.

The primary server ipreg.csi.cam.ac.uk will also be rebuilt, which will involve reconstructing all our DNS zone files from scratch. (This is less scary than it sounds, because the software we use for the hourly DNS updates makes it easy to verify that DNS zones are the same.)

These upgrades will cause secondary servers to perform full zone transfers of our zones, since the incremental transfer journals will be lost.

Authoritative DNS server rebuilds

2018-12-12 - News - Tony Finch

Tomorrow (13 December) we will reinstall the authoritative DNS server authdns0.csx.cam.ac.uk and upgrade its operating system from Ubuntu 14.04 "Trusty" to Debian 9 "Stretch".

During the upgrade our other authoritative servers will be available to provide DNS service. After the upgrade, secondary servers are likely to perform full zone transfers from authdns0 since it will have lost its incremental zone transfer journal.

Next week, we will do the same for authdns1.csx.cam.ac.uk and for ipreg.csi.cam.ac.uk (the primary server).

During these upgrades the servers will have their hostnames changed to auth0.dns.cam.ac.uk, auth1.dns.cam.ac.uk, and pri0.dns.cam.ac.uk, at least from the sysadmin point of view. There are lots of references to the old names which will continue to work until all the NS and SOA DNS records have been updated. This is an early step in the DNS server renaming / renumbering project.

New servers in Maths, and other sample.named.conf changes

2018-11-26 - News - Tony Finch

The Faculty of Mathematics have a revamped DNS setup, with new authoritative DNS servers, authdns0.maths (131.111.20.101) and authdns1.maths (131.111.20.202).

I have updated sample.named.conf and catz.arpa.cam.ac.uk to refer to these new servers for the 11 Maths zones. Also, I have belatedly added the Computer Lab's new reverse DNS range for 2a05:b400:110::/48.

The stealth secondary server documentation now includes separate, simpler configuration files for forwarding BIND resolvers, and for stealth secondaries using catz.arpa.cam.ac.uk. (As far as I can tell I am still the only one using catalog zones at the moment! They are pretty neat, though.)

New DNS web site

2018-11-20 - News - Tony Finch

There is a new web site for DNS in Cambridge at https://www.dns.cam.ac.uk/

The new site is mostly the old (sometimes very old) documentation that was hosted under https://jackdaw.cam.ac.uk/ipreg/. It has been reorganized and reformatted to make it easier to navigate; for example some pages have been rescued from the obscurity of the news archives. There are a few new pages that fill in some of the gaps.

The old pages (apart from the IP Register database interface) will shortly be replaced by redirects to their new homes on the new site.

News feeds

Our DNS news mailing list has been renamed to uis-dns-announce; those who were subscribed to the old cs-nameservers-announce list have been added to the new list. This mailing list is for items of interest to those running DNS servers on the CUDN, but which aren't of broad enough relevance to bother the whole of ucam-itsupport.

There are now Atom feeds for DNS news available from https://www.dns.cam.ac.uk/news/.

This news item is also posted at https://www.dns.cam.ac.uk/news/2018-11-20-web-site.html

Infrastructure

The new site is part of the project to move the IP Register database off Jackdaw. The plan is:

  • New web server; evict documentation. (done)

  • Replcate IP Register web user interface on new server. (This work will mostly be about porting Jackdaw's bespoke "WebDBI" mod_perl / Oracle application framework.)

  • Move the IP Register database off Jackdaw onto a new PostgreSQL database, without altering the external appearance. (This will involve porting the schema and stored procedures, and writing a test suite.)

After that point we should have more tractable infrastructure, making it easier to provide better user interface and APIs.

The new site is written in Markdown. The Project Light templates use Mustache, because it is programming-language-agnostic, so it will work with the existing mod_perl scripts, and with TypeScript in the future.

DNSSEC root key rollover this Thursday

2018-10-11 - News - Tony Finch

The rollover has occurred, and everything is OK at least as well as we can tell after one hour.

Before: http://dnsviz.net/d/root/W79zYQ/dnssec/ After: http://dnsviz.net/d/root/W790GQ/dnssec/

There's a lot of measurement happening, e.g. graphs of the view from the RIPE Atlas distributed Internet measurement system at: https://nlnetlabs.nl/

I have gently prodded our resolvers with rndc flushname . so they start using the 2017 key immediately, rather than waiting for the TTL to expire, since I am travelling tomorrow. I expect there will be a fair amount of dicsussion about the rollover at the DNS-OARC meeting this weekend...

DNSSEC root key rollover this Thursday

2018-10-08 - News - Tony Finch

This Thursday at 16:00 UTC (17:00 local time), the 2010 DNSSEC root key (tag 19036) will stop being used for signing, leaving only the 2017 root key (tag 20326). The root key TTL is 2 days so the change might not be visible until the weekend.

If you run a DNSSEC validating resolver, you should double check that it trusts the 2017 root key. ICANN have some instructions at the link below; if in doubt you can ask ip-register at uis.cam.ac.uk for advice.

ICANN's DNSSEC trust anchor telemetry data does not indicate any problems for us; however the awkward cases are likely to be older validators that predate RFC 8145.

I am away for the DNS-OARC and RIPE meetings starting on Friday, but I will be keeping an eye on email. This ought to be a non-event but there hasn't been a DNSSEC root key rollover before so there's a chance that lurking horrors will be uncovered.

BIND 9.12.2-P2 and other patch releases

2018-09-20 - News - Tony Finch

Yesterday, isc.org announced patch releases of BIND

I have upgraded our DNS servers to 9.12.2-P2 mainly to address the referral interoperability problem, though we have not received any reports that this was causing noticable difficulties.

There is a security issue related to Kerberos authenticated DNS updates; I'll be interested to hear if anyone in the University is using this feature!

Those interested in DNSSEC may have spotted the inline-signing bug that is fixed by these patches. We do not use inline-signing but instead use nsdiff to apply changes to signed zones, and I believe this is also true for the signed zones run by Maths and the Computer Lab.

DNS-over-TLS and DNS-over-HTTPS

2018-09-05 - News - Tony Finch

The University's central recursive DNS servers now support encrypted queries. This is part of widespread efforts to improve DNS privacy. You can make DNS queries using:

  • Traditional unencrypted DNS using UDP or TCP on port 53 ("Do53")

  • DNS-over-TLS on port 853 - RFC 7858

  • DNS-over-HTTPS on port 443 - RFC 8484

Amongst other software, Android 9 "Pie" uses DoT when possible and you can configure Firefox to use DoH.

There is more detailed information about Cambridge's DNS-over-TLS and DNS-over-HTTPS setup on a separate page.

Renaming and renumbering the DNS servers

2018-09-04 - News - Tony Finch

There is now a draft / outline plan for renaming and renumbering the central DNS servers. This is mainly driven by the need to abolish the old Computing Service domains and by the new IPv6 prefix, among other things. See the reshuffle notes for more details.

Non-interactive access to the xlist_ops page

2018-08-13 - News - Tony Finch

Automated access to the IP Register database has so far been limited to the list_ops page. In order to allow automated registration of systems with IPv6 addresses, it is now possible to use long-term downloaded cookies for the xlist_ops page as well.

BIND 9.12.2 and serve-stale

2018-08-03 - News - Tony Finch

Earlier this year, we had an abortive attempt to turn on BIND 9.12's new serve-stale feature. This helps to make the DNS more resilient when there are local network problems or when DNS servers out on the Internet are temproarily unreachable. After many trials and tribulations we have at last successfully enabled serve-stale.

Popular websites tend to have very short DNS TTLs, which means the DNS stops working quite soon when there are network problems. As a result, network problems look more like DNS problems, so they get reported to the wrong people. We hope that serve-stale will reduce this kind of misattribution.

Read more ...

New IPv6 prefix and reverse zone

2018-06-21 - News - Tony Finch

Our new IPv6 prefix is 2a05:b400::/32

As part of our planning for more eagerly rolling out IPv6, we concluded that our existing allocation from JISC (2001:630:210::/44) would not be large enough. There are a number of issues:

  • A typical allocation to a department might be a /56, allowing for 256 subnets within the department - the next smaller allocation of /60 is too small to allow for future growth. We only had space for 2048 x/56 allocations, or many fewer if we needed to make any /52 allocations for large institutions.

  • There is nowhere near enough room for ISP-style end-user allocations, such as a /64 per college bedroom or a /64 per device on eduroam.

As a result, we have asked RIPE NCC (the European regional IP address registry) to become an LIR (local internet registry) in our own right. This entitles us to get our own provider-independent ISP-scale IPv6 allocations, amongst other things.

We have now been allocated 2a05:b400::/32 and we will start planning to roll out this new address range and deprecate the old one.

We do not currently have any detailed plans for this process; we will make further announcements when we have more news to share. Any institutions that are planning to request IPv6 allocations might want to wait until the new prefix is available, or talk to networks@uis.cam.ac.uk if you have questions.

The first bit of technical setup for the new address space is to create the reverse DNS zone, 0.0.4.b.5.0.a.2.ip6.arpa. This is now present and working on our DNS servers, though it does not yet contain anything interesting! We have updated the sample stealth secondary nameserver configuration to include this new zone. If you are using the catalog zone configuration your nameserver will already have the new zone.

Edited to add: Those interested in DNSSEC might like to know that this new reverse DNS zone is signed with ECDSA P256 SHA256, whereas our other zones are signed with RSA SHA1. As part of our background project to improve DNSSEC key management, we are going to migrate our other zones to ECDSA as well, which will reduce the size of our zones and provide some improvement in cryptographic security.

DNSSEC validation and the root key rollover

2018-06-14 - News - Tony Finch

Those running DNSSEC validating resolvers should be aware that ICANN is preparing to replace the root key later this year, after last year's planned rollover was delayed.

Some of you need to take action to ensure your validating resolvers are properly configured.

There is more information at https://www.icann.org/resources/pages/ksk-rollover

ICANN have started publishing IP addresses of resolvers which are providing RFC 8145 trust anchor telemetry information that indicates they do not yet trust the new KSK. The announcement is at https://mm.icann.org/pipermail/ksk-rollover/2018-June/000418.html

IP addresses belonging to our central DNS resolvers appear on this list: 2001:630:212:8::d:2 and 2001:630:212:12::d:3

ICANN's data says that they are getting inconsistent trust anchor telemetry from our servers. Our resolvers trust both the old and new keys, so their TAT signals are OK; however our resolvers are also relaying TAT signals from other validating resolvers on the CUDN that only trust the old key.

I am going to run some packet captures on our resolvers to see if I can track down where the problem trust anchor telemetry signals are coming from, so that I can help you to fix your resolvers before the rollover.

External references to IP addresses

2018-06-13 - News - Tony Finch

After some experience with the the relaxed rules for references to off-site servers we have changed our process slightly. Instead of putting the IP addresses in the ucam.biz zone, we are going to enter them into the IP Register database, so that these non-CUDN IP addresses appear directly in the cam.ac.uk zone.

There are a few reasons for this:

  • Both the ucam.biz and IP Register setups are a bit fiddly, but the database is more easily scripted;

  • It reduces the need for us to set up separate HTTP redirections on the web traffic managers;

  • It reduces problems with ACME TLS certificate authorization at off-site web hosting providers;

  • It is closer to what we have in mind for the future.

The new setup registers off-site IP addresses in an OFF-SITE mzone, attached to an off-site vbox. The addresses are associated with web site hostnames using aname objects. This slightly round-about arrangement allows for IP addresses that are used by multiple web sites.

Long-form domain aliases

2018-05-31 - News - Tony Finch

Our documentation on domain names now includes a page on long-form aliases for top-level domains under cam.ac.uk.

Web servers on bare domains

2018-05-30 - News - Tony Finch

The DNS does not allow CNAME records to exist at the same name as other records. This restriction causes some friction for bare domains which you want to use for both mail and web. The IP Register database does not make it particularly easy to work around this restriction in the DNS, but we now have some tips for setting web sites on bare domain names

BIND security release

2018-05-21 - News - Tony Finch

On Friday, ISC.org released a security patch version of BIND 9.12.

The serve-stale vulnerability (CVE-2018-5737) is the one that we encountered on our live servers on the 27th March.

There are still some minor problems with serve-stale which will be addressed by the 9.12.2 release, so I plan to enable it after the next release.

More upgrades

2018-03-27 - News - Tony Finch

Edited to add:

A few hours after the item below, we disabled the new serve-stale feature following problems on one of our recursive DNS servers. We are working with ISC.org to get serve-stale working better.

Original item follows:

The DNS servers are now running BIND 9.12.1. This version fixes an interoperability regression that affected resolution of bad domains with a forbidden CNAME at the zone apex.

We have also enabled the new serve-stale feature, so that when a remote DNS server is not available, our resolvers will return old answers instead of a failure. The max-stale-ttl is set to one hour, which should be long enough to cover short network problems, but not too long to make malicious domains hang around long after they are taken down.

In other news, the DNS rebuild scripts (that run at 53 minutes past each hour) have been amended to handle power outages and server maintenance more gracefully. This should avoid most of the cases where the DNS build has stopped running due to excessive caution.

Upgraded to BIND 9.12.0

2018-02-20 - News - Tony Finch

The DNS servers are now running BIND 9.12.0. This version includes official versions of all the patches we needed for production, so we can now run servers built from unpatched upstream source.

First, a really nice DNSSEC-related performance enhancement is RFC 8198 negative answer synthesis: BIND can use NSEC records to generate negative responses, rather than re-querying authoritative servers. Our current configuration includes a lot of verbiage to suppress junk queries, all of which can be removed because of this new feature.

Second, a nice robustness improvement: when upstream authoritative DNS servers become unreachable, BIND will serve stale records from its cache after their time-to-live has expired. This should improve your ability to reach off-site servers when there are partial connectivity problems, such as DDoS attacks against their DNS servers.

Third, an operational simplifier: by default BIND will limit journal files to twice the zone file size, rather than letting them grow without bound. This is a patch I submitted to ISC.org about three years ago, so it has taken a very long time to get included in a release! This feature means I no longer need to run a patched BIND on our servers.

Fourth, a DNSSEC automation tool, dnssec-cds. (I mentioned this in a message I sent to this list back in October.) This is I think my largest single contribution to BIND, and (in contrast to the previous patch) it was one of the fastest to get committed! There's still some more work needed before we can put it into production, but we're a lot closer.

There are numerous other improvements, but those are the ones I am particularly pleased by. Now, what needs doing next ...

Support for Ed25519 SSHFP records

2018-01-23 - News - Tony Finch

The IP Register database now allows SSHFP records with algorithm 4 (Ed25519) See our previous announcement for details about SSHFP records.

Relaxed rules for external references from the cam.ac.uk domain

2017-10-13 - News - Tony Finch

We have relaxed the rules for external references from the cam.ac.uk domain so that CNAMEs are no longer required; external references can refer to IP addresses when a hostname isn't available.

One of the reasons for the old policy was that the IP Register database only knows about IP addresses on the CUDN. However, an old caveat says, "CUDN policy is not defined by this database, rather the reverse." The old policy proved to be inconvenient both for the Hostmaster team and for our colleagues around the University who requested external references. We didn't see any benefit to compensate for this inconvenience, so we have relaxed the policy.

At the moment we aren't easily able to change the structure of the IP Register database. In order to work around the technical limitations, when we need to make an external reference to an IP address, the Hosmaster team will create the address records in the domain ucam.biz and set up a CNAME in the database from cam.ac.uk to ucam.biz. This is slightly more fiddly for the Hostmaster team but we expect that it will make the overall process easier.

DNSSEC lookaside validation decommissioned

2017-10-02 - News - Tony Finch

In the bumper July news item there is a note about DNSSEC lookaside validation (DLV) being deprecated.

During the DNS OARC27 meeting at the end of last week, DLV was decommissioned by emptying the dlv.isc.org zone. The item on the agenda was titled "Deprecating RFC5074" - there are no slides because the configuration change was made live in front of the meeting.

If you have not done so already, you should remove any dnssec-lookaside (BIND) or dlv-anchor (Unbound) from your server configuration.

The effect is that the reverse DNS for our IPv6 range 2001:630:210::/44 and our JANET-specific IPv4 ranges 193.60.80.0/20 and 193.63.252.0/32 can no longer be validated.

Other Cambridge zones which cannot be validated are our RFC 1918 reverse DNS address space (because of the difficulty of distributing trust anchors); private.cam.ac.uk; and most of our Managed Zone Service zones. This may change because we would like to improve our DNSSEC coverage.

DNSSEC root key rollover postponed

2017-09-29 - News - Tony Finch

In the bumper July news item there is a note about the DNSSEC root key rollover, which has been in careful preparation this year.

ICANN announced last night that the DNSSEC root key rollover has been postponed, and will no longer take place on the 11th October. The delay is because telemetry data reveals that too many validators do not trust the new root key.

Split views for private.cam.ac.uk

2017-09-27 - News - Tony Finch

Since private.cam.ac.uk was set up in 2002, our DNS servers have returned a REFUSED error to queries for private zones from outside the CUDN. Hiding private zones from the public Internet is necessary to avoid a number of security problems.

In March the CA/Browser Forum decided that after the 8th September 2017, certificate authorities must check CAA DNS records before issuing certificates. CAA records specify restrictions on which certificate authorities are permitted to issue certificates for a particular domain.

However, because names under private.cam.ac.uk cannot be resolved on the public Internet outside the CUDN, certificate authorities became unable to successfuly complete CAA checks for private.cam.ac.uk. The CAA specification RFC 6844 implies that a CA should refuse to issue certificates in this situation.

In order to fix this we have introduced a split view for private.cam.ac.uk.

There are now two different versions of the private.cam.ac.uk zone: a fully-populated internal version, same as before; and a completely empty external version.

With the split view, our authoritative servers will give different answers to different clients: devices on the CUDN will get full answers from the internal version of private.cam.ac.uk, and devices on the public Internet will get negative empty answers (instead of an error) from the external version.

There is no change to the "stealth secondary" arrangements for replicating the private.cam.ac.uk zone to other DNS servers on the CUDN.

The authoritative server list for private.cam.ac.uk has been pruned to include just the UIS authdns servers which have the split view configuration. Our thanks to the Computer Lab and the Engineering Department for providing authoritative service until this change.

A Cambridge Catalog Zone

2017-09-06 - News - Tony Finch

Catalog Zones are a new feature in BIND 9.11 which allow a econdary server to automatically configure itself using a specially-formatted zone. The isc.org knowledge base has an introduction to catalog zones and Jan-Piet Mens has some notes on his catalog zone tests.

We can use this new feature to make "stealth secondary" configurations much shorter and lower-maintenance. Accordingly, there is now a catz.arpa.cam.ac.uk catalog zone corresponding to our recommended stealth secondary configuration, and our sample BIND configuration has been updated with notes on how to use it.

Background

This started off with some testing of the in-progress BIND 9.12 implementation of RFC 8198, which allows a validating DNSSEC resolver to use NSEC records to synthesize negative responses. (This spec is known as the Cheese Shop after an early draft which refers to a Monty Python sketch, https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop / https://tools.ietf.org/html/rfc8198)

RFC 8198 is very effective at suppressing unnecessary queries especially to the root DNS servers and the upper levels of the reverse DNS. A large chunk of my DNS server configuration previously tried to help with that by adding a lot of locally-served empty zones (as specified by RFC 6761 etc.) With the cheese shop all that becomes redundant.

The other big chunk of my configuration is the stealth slave list. I have previously not investigated catalog-zones in detail, since they aren't quite expressive enough for use by our central DNS servers, and in any case their configuration is already automated. But it's just right for the stealth slave configuration on my test server (and ppsw, etc.)

Setting up a Cambridge catalog zone was not too difficult. Altogether it allowed me to delete over 100 zone configurations from my test server.

Deleting "localhost" entries from the cam.ac.uk DNS zone

2017-09-01 - News - Tony Finch

Between the 4th and 8th September we will delete all the localhost entries from the cam.ac.uk DNS zone. This change should have no effect, except to avoid certain obscure web security risks.

RFC 1537, "Common DNS Data File Configuration Errors", says "all domains that contain hosts should have a localhost A record in them." and the cam.ac.uk zone has followed this advice since the early 1990s (albeit not entirely consistently).

It has belatedly come to our attention that this advice is no longer considered safe, because localhost can be used to subvert web browser security policies in some obscure situations.

Deleting our localhost DNS records should have no effect other than fixing this security bug and cleaning up the inconsistency. End-user systems handle queries for localhost using their hosts file, without making DNS queries, and without using their domain search list to construct queries for names like localhost.cam.ac.uk. We verified this by analysing query traffic on one of the central DNS resolvers, and the number of unwanted queries was negligible, less than one every 15 minutes, out of about 1000 queries per second.

CST delegated, plus DNSSEC-related news

2017-07-18 - News - Tony Finch

From October, the Computer Laboratory will be known as the Department of Computer Science and Technology.

Our colleagues in the CL have set up the zone cst.cam.ac.uk to go with the new name, and it has been added to our sample nameserver configuration file.

The first root DNSSEC key rollover is happening

The new key (tag 20326) was published on 11th July, and validating resolvers that follow RFC 5011 rollover timing will automatically start trusting it on the 10th August. There's a lot more information about the root DNSSEC key rollover on the ISC.org blog. I have added some notes on how to find out about your server's rollover state on our DNSSEC validation page.

DNSSEC lookaside validation is deprecated

The DLV turndown was announced in 2015 and the dlv.isc.org zone is due to be emptied in 2017. You should delete any dnssec-lookaside option you have in your configuration to avoid complaints in named's logs.

Annoyingly, we were relying on DLV as a stop-gap while waiting for JISC to sign their reverse DNS zones. Some of our IPv4 address ranges and our main IPv6 allocation are assigned to us from JISC. Without DLV these zones can no longer be validated.

BIND 9.11

2017-07-11 - News - Tony Finch

The central DNS servers have been upgraded from BIND 9.10 to BIND 9.11, which has a number of new features a few of which are particularly relevant to us.

On the authoritative servers, the minimal-any anti-DDOS feature was developed by us and contributed to isc.org. Happily we no longer have to maintain this as a patch.

On the recursive servers, there are a couple of notable features.

Firstly, BIND 9.11 uses EDNS cookies to identify legitimate clients so they can bypass DDoS rate limiting. Unfortunately EDNS options can encounter bugs in old badly-maintained third-party DNS servers. We are keeping an eye out for problems and if necessary we can add buggy servers to a badlist of those who can't have cookies.

Secondly, we now have support for "negative trust anchors" which provide a workaround for third party DNSSEC failures. Fortunately we have not so far had significant problems due to the lack of this feature.

BIND CVE-2017-3142 and CVE-2017-3143

2017-06-30 - News - Tony Finch

In case you have not already seen it, last night ISC.org announced a serious vulnerability in BIND: if you have a server which allows dynamic DNS UPDATE then a remote attacker may me able to alter your zones without proper authentication. For more details see:

Note that update-policy local; uses a well-known TSIG key name, and does not include any IP address ACL restrictions, so it is extremely vulnerable to attack. To mitigate this you can replace update-policy local; with

allow-update { !{ !localhost; any; }; key local-ddns; };

This denies updates that come from everywhere except localhost, and then allows updates with the built-in local-ddns key. For a longer explanation, see https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html You can still use nsupdate -l with this configuration.

Our master DNS server has very strict packet filters which should be effective at mitigating this vulnerability until I can update the servers.

April BIND security release

2017-04-13 - News - Tony Finch

Yesterday evening there was a BIND security release fixing three vulnerabilities.

The most serious one is CVE-2017-3137 which can crash recursive servers. (It is related to the previous DNAME/CNAME RRset ordering bugs which led to security releases in January and November.)

The other vulnerabilities are in DNS64 support (which I don't think any of us use) and in the rndc control channel (which is mainly a worry if you have opened up read-only access in BIND 9.11).

More details on the bind-announce list, https://lists.isc.org/pipermail/bind-announce/2017-April/thread.html

I have patched the central DNS servers and the ppsw-specific resolvers.

An update on Cloudflare

2017-03-20 - News - Tony Finch

The UIS no longer plans to deploy Cloudflare on a large scale; we will use Cloudflare only for www.cam.ac.uk.

As such the automated Cloudflare provisioning system described previously has been decommissioned.

Security upgrade

2017-03-06 - News - Tony Finch

A number of security vulnerabilities in the IP Register web user interface have been fixed.

Read more ...

SPF records

2017-01-30 - News - Tony Finch

The Sender Policy Framework is a way to publish in the DNS which mail servers may send email "from" a particular mail domain. It uses specially formatted TXT records alongside the mail domain's MX records.

Over the last several months, we have added SPF records for mail domains under cam.ac.uk which have mail hosted offsite. The most common offsite host is Microsoft Office 365 Exchange Online, but we have a few others using survey or mailshot services.

These SPF records are managed by the IP Register / Hostmaster team, in co-operation with the Mail Support / Postmaster team. Please email us if you would like any changes.

Name servers need patching: four BIND CVEs

2017-01-12 - News - Tony Finch

ISC.org have just announced several denial-of-service vulnerabilities in BIND's handling of DNS responses. Recursive DNS servers are particularly vulnerable.

I am in the process of patching our central DNS servers; you should patch yours too.

These bugs appear to be a similar class of error to the previous BIND CVE a couple of months ago.

Cloudflare

2016-11-29 - News - Tony Finch

Cloudflare is a web content delivery network with an emphasis on denial-of-service protection.

The UIS are aiming to deploy Cloudflare in front of the University's most prominent / sensitive web sites; this service might be extended more widely to other web sites, though it is not currently clear if this will be feasible.

There is a separate document with more details of how the IP Register database and Cambridge DNS setup support Cloudflare.

Recursive servers need patching: BIND CVE 2016-8864

2016-11-01 - News - Tony Finch

ISC.org have just announced a denial-of-service vulnerability in BIND's handling of DNAME records in DNS responses. Recursive DNS servers are particularly vulnerable.

I am in the process of patching our central DNS servers; you should patch yours too.

(This bug was encountered by Marco Davids of SIDN Labs, and I identified it as a security vulnerability and reported it to ISC.org. You can find us in the acknowledgments section of the security advisory.)

Urgent patching required: BIND CVE 2016-2776

2016-10-05 - News - Tony Finch

On 28th September we wrote:

Yesterday evening, ISC.org announced a denial-of-service vulnerability in BIND's buffer handling. The crash can be triggered even if the apparent source address is excluded by BIND's ACLs (allow-query).

All servers are vulnerable if they can receive request packets from any source.

If you have not yet patched, you should be aware that this bug is now being actively exploited.

Urgent patching required: BIND CVE 2016-2776

2016-09-28 - News - Tony Finch

Yesterday evening, ISC.org announced a denial-of-service vulnerability in BIND's buffer handling. The crash can be triggered even if the apparent source address is excluded by BIND's ACLs (allow-query).

All servers are vulnerable if they can receive request packets from any source.

Most machines on the CUDN are protected to a limited extent from outside attack by the port 53 packet filter. DNS servers that have an exemption are much more at risk.

http://www.ucs.cam.ac.uk/network/infoinstitutions/techref/portblock

I am in the process of patching our central DNS servers; you should patch yours too.

(This is another bug found by ISC.org's fuzz testing campaign; they have slowed down a lot since the initial rush that started about a year ago; the last one was in March.)

recovering from the DNS update service outage

2016-04-06 - News - Tony Finch

Sorry about the extended lack of DNS updates today.

Unfortunately the VM host system lost the RAID set that held the filesystem for our DNS master server (amongst others). We determined that it would be faster to rebuild some servers from scratch rather than waiting for more intensive RAID recovery efforts.

The DNS master server is set up so it can be rebuit from scratch without too much difficulty - all the data on its filesystem comes from our configuration management systems, and from the IP register and MZS databases.

The main effect of this is that the zone transfers following the rebuild will be full transfers from scratch - incremental transfers are not possible. There is likely to be some additional load which slows down zone transfers while everything catches up.

BIND CVE-2016-1286 etc.

2016-03-10 - News - Tony Finch

Last night the ISC announced another security release of BIND to fix three vulnerabilities. For details see https://lists.isc.org/pipermail/bind-announce/2016-March/thread.html

Probably the most risky is CVE-2016-1286 which is a remote denial-of-service vulnerability in all versions of BIND without a workaround. CVE-2016-1285 can be mitigated, and probably is already mitigated on servers with a suitably paranoid configuration. CVE-2016-2088 is unlikely to be a problem.

I have updated the central DNS servers to BIND 9.10.3-P4.

I have also made a change to the DNS servers' name compression behaviour. Traditionally, BIND used to compress domain names in responses so they match the case of the query name. Since BIND 9.10 it has tried to preserve the case of responses from servers, which can lead to case mismatches between queries and answers. This exposed a case-sensitivity bug in Nagios, so after the upgrade it falsely claimed that our resolvers were not working properly! I have added a no-case-compress clause to the configuration so our resolvers now behave in the traditional manner.

recursive DNS server packet filters

2016-03-02 - News - Tony Finch

Yesterday I changed the iptables packet filters on the central recursive DNS servers, 131.111.8.42 and 131.111.12.20, to harden them against denial of service attacks from outside the CUDN.

Previously we were rejecting queries from outside the CUDN using DNS-level REFUSED responses; now, TCP connections from outside the CUDN are rejected at the network layer using ICMP connection refused.

This change should not have any visible effect; I am letting you know because others who run DNS servers on the CUDN might want to make a similar change, and because there is some interesting background.

For most purposes, incoming DNS queries are blocked by the JANET border packet filters. http://www.ucs.cam.ac.uk/network/infoinstitutions/techref/portblock You only really need an exemption to this block for authoritative DNS servers. If you are running recursive-only DNS servers that are exempted from the port 53 block, you should consider changing your packet filters.

The particular reason for this change is that BIND's TCP connection listener is trivially easy to flood. The inspiration for this change is a cleverly evil exploit announced by Cloudflare earlier this week which relies on TCP connection flooding. Although their particular attack doesn't work with BIND, it would still be unpleasant if anyone tried it on us.

I have published a blog article with more background and context at http://fanf.livejournal.com/141807.html

January BIND security release

2016-01-20 - News - Tony Finch

Last night the ISC published yet another security release of BIND.

For details, please see the announcement messages: https://lists.isc.org/pipermail/bind-announce/2016-January/thread.html

The central DNS servers have been upgraded to BIND 9.10.3-P3.

BIND security release

2015-12-17 - News - Tony Finch

On Tuesday night the ISC published security releases of BIND which fix a couple of remote denial of service vulnerabilities. If you are running a recursive DNS server then you should update as soon as possible.

If you build your own BIND packages linked to OpenSSL 1.0.1 or 1.0.2 then you should also be aware of the OpenSSL security release that occurred earlier this month. The new versions of BIND will refuse to build with vulnerable versions of OpenSSL.

For more information see the bind-announce list, https://lists.isc.org/pipermail/bind-announce/2015-December/thread.html

The central nameservers and the resolvers on the central mail relays were updated to BIND 9.10.3-P2 earlier today.

Isaac Newton Institute delegated

2015-10-22 - News - Tony Finch

There are two new zones in the sample nameserver configuration,

  • newton.cam.ac.uk
  • 145.111.131.in-addr.arpa

These have been delegated like the other domains managed by the Faculty of Mathematics.

(lack of) DNS root hints

2015-09-28 - News - Tony Finch

Another change I made to sample.named.conf on Friday was to remove the explicit configuration of the root name server hints. I was asked why, so I thought I should explain to everyone.

BIND comes with a built-in copy of the hints, so there is no need to explicitly configure them. It is important to keep BIND up-to-date for security reasons, so the root hints should not be stale. And even if they are stale, the only negative effect is a warning in the logs.

So I regard explicitly configuring root hints as needless extra work.

It is worth noting that the H-root name server IP addresses are going to change on the 1st December 2015. We will not be making any special effort in response since normal BIND updates will include this change in due course.

There is a history of root name server IP address changes at http://root-servers.org/news.html

New CUDN-wide private addresses 10.128.0.0/9

2015-09-25 - News - Tony Finch

You should be aware of our previous announcements about changing the status of 10.128.0.0/9 to CUDN-wide private address space.

The central name servers now have DNS zones for 10.128.0.0/9. There are not yet any registrations in this address space, so the zones are currently almost empty. We have updated the name server configuration advice to cover these new zones.

https://jackdaw.cam.ac.uk/ipreg/nsconfig/

On the CUDN the RFC 1918 address block 10.0.0.0/8 is divided in two. The bottom half, 10.0.0.0/9, is for institution-private usage and is not routed on the CUDN. The top half, 10.128.0.0/9, was previously reserved; it has now been re-assigned as CUDN-wide private address space.

To provide DNS for 10.0.0.0/8 we have a mechanism for conveniently sharing the zone 10.in-addr.arpa between institution-private and CUDN-wide private uses. The arrangement we are using is similar to the way 128.232.0.0/16 is divided between the Computer Lab and the rest of the University.

We have two new zones for this address space,

  • 10.in-addr.arpa
  • in-addr.arpa.private.cam.ac.uk

The sample nameserver configuration has been updated to include them.

Institutions that are using the bottom half, 10.0.0.0/9, should provide their own version of 10.in-addr.arpa with DNAME redirections to in-addr.arpa.private.cam.ac.uk for the CUDN-wide addresses.

BIND security update

2015-09-03 - News - Tony Finch

Last night the ISC released new versions of BIND, 9.9.7-P3 and 9.10.2-P4, which address a couple of remote denial-of-service vulnerabilities, CVE-2015-5722 (DNSKEY parsing bug) and CVE-2015-5986 (OPENPGPKEY parsing bug). There is some background information on the recent spate of security releases at https://www.isc.org/blogs/summer_security_vulnerabilities/

If you are running BIND as a recursive DNS server you should update it urgently. We will be patching the central DNS servers this morning.

CVE-2015-5477: critical remote crash bug in BIND

2015-07-29 - News - Tony Finch

If you have a DNS server running BIND, you should apply the latest security patch as soon as possible.

The bind-announce mailing list has the formal vulnerability notification and release announcements:

The authors of BIND have also published a blog post emphasizing that there are no workarounds for this vulnerability: it affects both recursive and authoritative servers and I understand that query ACLs are not sufficient protection.

Our central DNS servers authdns* and recdns* have been patched.

More frequent DNS updates

2015-02-18 - News - Tony Finch

DNS updates now occur every hour at 53 minutes past the hour. (There is a mnemonic for the new timing of DNS updates: 53 is the UDP and TCP port number used by the DNS.) Previously, the interval between DNS update runs was four hours.

The update job takes a minute or two to run, after which changes are immediately visible on our public authoritative DNS servers, and on our central recursive servers 131.111.8.42 and 131.111.12.20.

We have also reduced the TTL of our DNS records from 24 hours to 1 hour. (The time-to-live is the maximum time old data will remain in DNS caches.) This shorter TTL means that users of other recursive DNS servers around the University and elsewhere will observe DNS changes within 2 hours of changes to the IP Register database.

There are two other DNS timing parameters which were reduced at the time of the new DNS server rollout.

The TTL for negative answers (in response to queries for data that is not present in the DNS) has been reduced from 4 hours to 1 hour. This can make new entries in the DNS available faster.

Finally, we have reduced the zone refresh timer from 4 hours to 30 minutes. This means that unofficial "stealth secondary" nameservers will fetch DNS updates within 90 minutes of a change being made to the IP Register database. Previously the delay could be up to 8 hours.

New DNS servers

2015-02-15 - News - Tony Finch

The DNS servers have been replaced with an entirely new setup.

The immediate improvements are:

  • Automatic failover for recursive DNS servers. There are servers in four different locations, two live, two backup.

  • DNSSEC signing moved off authdns0 onto a hidden master server, with support for signing Managed Zone Service domains.

There are extensive improvements to the DNS server management and administration infrastructure:

  • Configuration management and upgrade orchestration moved from ad-hoc to Ansible.

  • Revision control moved from SCCS to git, including a history of over 20,000 changes dating back to 1990.

  • Operating system moved from Solaris to Linux, to make better use of our local knowledge and supporting infrastructure.

DNS server upgrade

2015-02-09 - News - Tony Finch

This week we will replace the DNS servers with an entirely new setup. This change should be almost invisible: the new servers will behave the same as the old ones, and each switchover from an old to a new server will only take a few seconds so should not cause disruption.

The rollout will switch over the four service addresses on three occasions this week. We are avoiding changes during the working day, and rolling out in stages so we are able to monitor each change separately.

Tuesday 10 February, 18:00 -

  • Recursive server recdns1, 131.111.12.20 (expected outage 15s)

Wednesday 11 February, 08:00 -

  • Recursive server recdns0, 131.111.8.42 (expected outage 15s)
  • Authoritative server authdns1, 131.111.12.37 (expected outage 40s)

Thursday 12 February, 18:00 -

  • Authoritative server authdns0, 131.111.8.37 (expected outage 40s)

There will be a couple of immediate improvements to the DNS service, with more to follow:

  • Automatic failover for recursive DNS servers. There are servers in three different locations, two live, one backup, and when the West Cambridge Data Centre comes online there will be a second backup location.

  • DNSSEC signing moved off authdns0 onto a hidden master server, with support for signing Managed Zone Service domains.

There are extensive improvements to the DNS server management and administration infrastructure:

  • Configuration management and upgrade orchestration moved from ad-hoc to Ansible. The expected switchover timings above are based on test runs of the Ansible rollout / backout playbooks.

  • Revision control moved from SCCS to git, including a history of over 20,000 changes dating back to 1990.

  • Operating system moved from Solaris to Linux, to make better use of our local knowledge and supporting infrastructure.

Some small changes to sample.named.conf

2014-07-23 - News - Tony Finch

The UIS have taken over the management of the DNS entries for the MRC Biostatistics Unit subnets 193.60.[86-87].x. As a result, the zones

  • 86.60.193.in-addr.arpa
  • 87.60.193.in-addr.arpa

can now be slaved from the authdns*.csx servers by hosts within the CUDN, and they have been added to the sample BIND configuration at

https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

Those who feel they must slave enough reverse zones to cover the whole CUDN may want to include them. These zones are not yet signed, but we expect them to be within a week or two.

A number of cosmetic changes to the comments in the sample configuration have also been made, mostly bringing up to date matters like the versions of BIND still being actively supported by ISC.

Those who use an explicit root hints file may want to note that a new version was issued in early June, adding an IPv6 address to B.ROOT-SERVERS.NET. The copy at https://jackdaw.cam.ac.uk/ipreg/nsconfig/db.cache was updated.

SRV records

2014-07-14 - News - Chris Thompson

There is now a service_ops web page available which allows authorised users to create service (SRV) records in the DNS for names in the domains to which they have access. See the service_ops help page for more details.

SSHFP records

2014-07-08 - News - Chris Thompson

SSH fingerprint records can now be added to the DNS via the IP registration database. Such records are described in RFC 4225 as updated by RFC 6594.

More information can be found on the IP Register SSHFP documentation page

DHCP-related data in the IP registration database

2014-07-07 - News - Chris Thompson

Many users of the IP registration database web interface will have noticed the appearance some time ago of mac and dhcp_group fields on the single_ops page, as well as related changes visible via the table_ops page.

These were intended in the first instance for maintaining a DHCP service for internal use in the UCS. It was perhaps unwise of us to make them visible outside and raise users' expectations prematurely. It remains a work in progress, and we have had to make changes of detail that affected some of those who had set these fields. The notes here describe the current state.

Although the single_ops page doesn't make this obvious, the mac and dhcp_group fields are properties of the IP address rather than the box. If a box or vbox has multiple IP addresses, each one can have its own values for them. The fields are cleared automatically when the IP address is rescinded.

MAC addresses can be entered in any of the usual formats but are displayed as colon-separated. Because the intent is to support DHCP servers, MAC addresses (if set) are required to be unique within any particular mzone/lan combination. A non-null dhcp_group value is intended to indicate non-default DHCP options. To support automated processing, it must correspond to a registered dhcp_group object for the given mzone/lan which can be created, modified or deleted via table_ops. The values should contain only alphanumeric, hyphen and underline characters.

The degree to which any of this is of use to users outside the UIS is currently very limited. We do intend to add more usability features, though.

Representing network access controls in the database

2014-05-20 - News - Chris Thompson

The scheme described in news item 2008-12-15 has been reworked to represent a larger number of references to specific IP addresses from the various parts of the CUDN infrastructure. The intention remains the same: to prevent such IP addresses being rescinded or reused without appropriate changes being made to the CUDN configuration.

There are now four "anames" used instead of three:

  • janet-filter.net.private.cam.ac.uk for exceptions at the CUDN border routers, often permitting some network traffic that would otherwise be blocked. This is essentially the same as the old janet-acl.net.private.cam.ac.uk which is temporarily an alias.

  • cudn-filter.net.private.cam.ac.uk for exceptions at internal CUDN routers. This includes the old high-numbered port blocking, where it is still in use, but also many other sorts of exception which were previously not represented. The old name cudn-acl.net.private.cam.ac.uk is temporarily an alias.

  • cudn-blocklist.net.private.cam.ac.uk for addresses for which all IP traffic is completely blocked, usually as the result of a security incident. This is essentially the same as the old block-list.net.private.cam.ac.uk which is temporarily an alias.

  • cudn-config.net.private.cam.ac.uk for addresses that are referred to in the CUDN routing infrastructure. This is completely new.

Both IPv4 and IPv6 addresses may appear in these lists (although at the moment only cudn-config has any IPv6 addresses).

Requests for the creation or removal of network access control exceptions, or explanations of existing ones, should in most cases be sent to network-support@uis.cam.ac.uk in the first instance, who will redirect them if necessary. However, the CERT team at cert@cam.ac.uk are solely responsible for the cudn-blocklist contents in particular.

Upgrade to BIND 9.9.5 may possibly cause problems

2014-02-18 - News - Chris Thompson

The most recently released BIND versions (9.9.5, 9.8.7, 9.6-ESV-R11) have implemented a more pedantic interpretation of the RFCs in the area of compressing responses. It is just possible that this will cause problems for some resolving software. ISC have written a Knowledge Base article about it, which can be found at https://kb.isc.org/article/AA-01113

In particular, the name in the answer section of a response may now have a different case from that in the question section (which will always be identical to that in the original query). Previously they would (after decompression) have been identical. Resolvers are meant to use case- insensitive comparisons themselves, but this change could expose non- conformance in this area.

However, experiments we have performed so far, and information from the DNS community at large, suggests that such non-conformance is quite rare. We are therefore planning to upgrade the CUDN central nameservers (both authoritative and recursive) to BIND 9.9.5 over the next few days. Please keep an eye out for any problems that might be caused by the change, and let us (hostmaster at ucs.cam.ac.uk) know as soon as possible, while we still have the option of backing off.

The "consolidated reverse zone" in-addr.arpa.cam.ac.uk is now signed

2014-01-26 - News - Chris Thompson

In November, I wrote to this list (cs-nameservers-announce):

As regards DNSSEC validation, cl.cam.ac.uk now has a chain of trust from the root zone. We expect that 232.128.in-addr.arpa will also have one before long.

This last happened earlier in January. That made it sensible to sign the "consolidated reverse zone" in-addr.arpa.cam.ac.uk which provides reverse lookup results for IPv4 addresses in the range 128.232.[128-255].x. This has now been done, and the results of such reverse lookup can be fully validated using chains of trust from the root zone.

There is more information at

https://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-signed.html

  • Moved to https://www.dns.cam.ac.uk/domains/signed.html

    https://jackdaw.cam.ac.uk/ipreg/nsconfig/consolidated-reverse-zones.html

  • Moved to https://www.dns.cam.ac.uk/domains/reverse/

which have been brought up to date.

Computer Laboratory zones are now signed

2013-11-19 - News - Chris Thompson

First, a note that the IPv6 reverse zone delegated to the Computer Laboratory, 2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa, has been added to the list of zones in https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf that can be slaved stealthily within the CUDN. Some of the commentary in that file has also been brought up to date.

The main news is that the zones

  • cl.cam.ac.uk
  • 232.128.in-addr.arpa
  • 2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa

are now all signed. They are therefore much larger than before, and have larger and more frequent incremental updates. Those who are slaving them may need to be aware of that.

As regards DNSSEC validation, cl.cam.ac.uk now has a chain of trust from the root zone. We expect that 232.128.in-addr.arpa will also have one before long. The IP reverse zone has DS (delegation signer) records in 1.2.0.0.3.6.0.1.0.0.2.ip6.arpa, but that itself can be validated only via the dlv.isc.org lookaside zone, as JANET have not yet signed its parent zone 0.3.6.0.1.0.0.2.ip6.arpa (despite an 18-month-old promise on their part).

New xlist_ops web page

2013-07-01 - News - Chris Thompson

There is a new xlist_ops page that provides more general list operations on the IP registration database than does the list_ops page. In particular it allows downloads of lists of boxes, vboxes, cnames or anames, and uploads to perform bulk operations on multihomed boxes, vboxes, cnames or (for registrars only) anames. See the xlist_ops help page for details.

The opportunity has been taken to make a number of other small modifications. The order of links in the standard page header has been altered, and multihome_ops has been relegated to a link from the preferred box_ops page.

Removing some registrations in dlv.isc.org

2012-07-08 - News - Chris Thompson

The following will be relevant primarily to those who are performing DNSSEC validation.

It will soon be the second anniversary of the date on which the root zone was signed, 15 July 2010. By now, everyone seriously into the business of DNSSEC validation should be using a trust anchor for the root zone, whether or not they also use lookaside validation via a trust anchor for dlv.isc.org. The latter facility was always meant to be an aid to early deployment of DNSSEC, not a permanent solution. While it remains useful to cover the many unsigned gaps in the tree of DNS zones, it no longer seems appropriate to have dlv.isc.org entries for DNS zones that can be validated via a chain of trust from the root zone.

Therefore, on or about 15 July 2012, we shall be dropping the entries for the two zones cam.ac.uk and 111.131.in-addr.arpa from the dlv.isc.org zone, as these have now have had chains of trust from the root zone for well over a year. We will be retaining the entries for a number of our signed reverse zones whose parent zones are not yet signed - for details see

https://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-signed.html

Phasing out of the old IPv6 address block

2012-02-07 - News - Chris Thompson

Nearly all IPv6 use within the CUDN has now been transferred from the old block 2001:630:200::/48 to the new block 2001:630:210::/44. Therefore the following changes have been made to the sample configuration for stealth servers at https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

  1. The old block has been dropped from the definition of the "camnets" ACL.

  2. The reverse zone 0.0.2.0.0.3.6.0.1.0.0.2.ip6.arpa has been dropped from the list of those which may be slaved.

We advise you to make the corresponding changes in your nameserver configurations if they are relevant.

New BIND vulnerability CVE-2011-4313

2011-11-16 - News - Chris Thompson

ISC have issued the BIND advisory

http://www.isc.org/software/bind/advisories/cve-2011-4313

It concerns a bug, thought to be a remotely exploitable, that crashes recursive nameservers, and they have provided new BIND versions (9.4-ESV-R5-P1, 9.6-ESV-R5-P1, 9.7.4-P1, 9.8.1-P1) which are proof against crashing from this cause, although the precise sequence of events that leads to it remains obscure.

Although we are not aware of any local nameservers that have been affected by this problem, several other sites have been badly affected in the last 24 hours.

The CUDN central recursive nameservers at 131.111.8.42 & 131.111.12.20 are now running BIND 9.8.1-P1.

IPv6 addresses of the CUDN central nameservers

2011-08-23 - News - Chris Thompson

The IPv6 routing prefixes for the vlans on which the CUDN central nameservers are located are being altered. As a result, their IPv6 addresses are changing as follows:

               Old IPv6 address          New IPv6 address
authdns0.csx   2001:630:200:8080::d:a0   2001:630:212:8::d:a0
authdns1.csx   2001:630:200:8120::d:a1   2001:630:212:12::d:a1
recdns0.csx    2001:630:200:8080::d:0    2001:630:212:8::d:0
recdns1.csx    2001:630:200:8120::d:1    2001:630:212:12::d:1

The new addresses are working now, and the old addresses will continue to work as well until Monday 5 September, when they will be removed. If you are using them (e.g. in nameserver or stub resolver configuration files) you should switch to the new addresses (or the IPv4 ones) before then.

The comments in the sample configuration file

https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

about using IPv6 addresses to address the nameservers have been modified appropriately.

Two ISC advisories about BIND

2011-07-05 - News - Chris Thompson

ISC have issued two BIND advisories today:

http://www.isc.org/software/bind/advisories/cve-2011-2464

This affects most still-supported versions of BIND. A suitably crafted UPDATE packet can trigger an assertion failure. Apparently not yet seen in the wild...

http://www.isc.org/software/bind/advisories/cve-2011-2465

This affects only users of Response Policy Zones in 9.8.x.

Fixed versions are 9.6-ESV-R4-P3, 9.7.3-P3 and 9.8.0-P4.

New IPv6 address block for Cambridge

2011-06-21 - News - Chris Thompson

You may be aware that we have been negotiating with JANET for a larger IPv6 address block. These negotiations have (eventually) been successful. We are being allocated 2001:630:210::/44, and the existing use of 2001:630:200::/48 will be phased out over (we hope) the next few months. Details of how the new space will be divided up will be available from Networks in due course.

As immediate consequences, the following changes have been made to http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf:

  • The "camnets" ACL has 2001:630:210::/44 added to it.

  • The reverse zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" is listed as available for (stealth) slaving.

Of course, the reverse zone has nothing significant in it yet! But if you are slaving the existing IPv6 reverse zone, you should probably start slaving the new one as well.

There will of course be other changes during the transition that may affect local nameserver administrators. In particular the IPv6 addresses

of the CUDN central authoritative and recursive nameservers will change at some point: this list will be informed before that happens.

A few minor issues while I have your attention:

  1. The zone amtp.cam.ac.uk (old name for damtp.cam.ac.uk) is no longer delegated, and is about to vanish entirely. If you are still slaving it even after the message here on 9 March, now is the time to stop.

  2. There has been another small change to the official root hints file ftp://ftp.internic.net/domain/named.cache, and the copy at http://jackdaw.cam.ac.uk/ipreg/nsconfig/db.cache has been updated accordingly. The change is the addition of an IPv6 address for d.root-servers.net, and rather appropriately it was made on "IPv6 day".

  3. My description of the BIND vulnerability CVE-2011-1910 was defective in two directions:

    • It isn't necessary to have DNSSEC validation turned on to be vulnerable to it.

    • On the other hand, only moderately recent versions of BIND are vulnerable: old enough ones are not.

    The information at

    http://www.isc.org/software/bind/advisories/cve-2011-1910

    about which versions are affected is accurate (bearing in mind that some OS vendors make their own changes without altering the version number). If you are compiling from source, I can advise you on the code fragment to look for.

BIND high severity advisory CVE-2011-1910

2011-05-27 - News - Chris Thompson

ISC have issued a high severity advisory

http://www.isc.org/software/bind/advisories/cve-2011-1910

and several fixed BIND versions are now available (9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1, 9.8.0-P2).

This bug can only be exercised if DNSSEC validation is turned on, but that is increasingly becoming the default setup these days.

New box_ops web page

2011-05-22 - News - Chris Thompson

There is a new box_ops page which can be used as an alternative to the multihome_ops page to manipulate the registrations of hosts ("boxes" in the terminology of the IP registration database) with more than one IP address.

Its functions and display are simpler than those of multihome_ops and more in line with those of the other web pages. Unlike multihome_ops it supports the addition or removal of IPv6 addresses (if any are assigned to the user's management zones) as well as IPv4 ones. However, it is lacking some of the facilities available with multihome_ops such as: using wildcards with display, selecting by address, and displaying detailed properties of the associated IP address objects.

We hope to add at least some of these facilities to box_ops (and to other pages, such as vbox_ops) in due course, and to eliminate the necessity to keep mutihome_ops in its current form. The main reason for releasing box_ops now in this somewhat undeveloped state is its support for IPv6 addresses.

Changes to sample.named.conf for delegated Maths domains

2011-03-09 - News - Chris Thompson

There is a new version of the sample nameserver configuration at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

The following zones, which were not previously delegated, have been added:

  • maths.cam.ac.uk
  • statslab.cam.ac.uk
  • 20.111.131.in-addr.arpa

The following zone, which is being phased out, has been removed:

  • amtp.cam.ac.uk

There are no other changes.

Consolidated reverse zone in-addr.arpa.cam.ac.uk

2011-03-03 - News - Chris Thompson

We have progressed past step (2), as in:

  1. If all goes well, during the first week in March we will get the delegations of the 32 zones replaced by DNAMEs in the parent zone 232.128.in-addr.arpa.

with thanks to the Computer Lab hostmaster for his co-operation. We have no reports of any problems at this stage.

The sample nameserver configuration

https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

has been updated to remove the 32 zones [224-255].232.128.in-addr.arpa from the list that may be slaved. (Apart from some modifications to the comments before "in-addr.arpa.cam.ac.uk", that is the only change.)

If you are slaving any or all of these 32 reverse zones, you should stop doing so now. Sometime next week we will start logging such slaving activity, and alert the administrators of any hosts involved.

The target date for step (3), the complete removal of these 32 reverse zones, remains Monday 14 March.

Consolidated reverse zone in-addr.arpa.cam.ac.uk

2011-02-25 - News - Chris Thompson

We performed step (1) -

  1. On Monday 21 February we will replace the the 32 zones [224-255].232.128.in-addr.arpa by versions using DNAMEs that indirect into in-addr.arpa.cam.ac.uk.

on Monday as planned, but had to back off for 12 out of the 32 zones (those covering PWF subnets) because of a problem with a local script used in the PWF re-imaging process. This has now been fixed, and all 32 zones are using indirecting DNAMEs again.

At present we do not think that this delay will significantly affect the schedule for steps (2) and (3). If you are experiencing any problems which you think might be related to these changes, please contact hostmaster at ucs.cam.ac.uk as soon as possible.

Consolidated reverse zone in-addr.arpa.cam.ac.uk

2011-02-16 - News - Chris Thompson

We are planning to extend the IP address range covered by the consolidated reverse zone in-addr.arpa.cam.ac.uk, described here last November, to include 128.232.[224-255].x. The web page

http://jackdaw.cam.ac.uk/ipreg/nsconfig/consolidated-reverse-zones.html

has been updated with the planned schedule and some new advice for users of Windows DNS Server.

To summarise:

  1. On Monday 21 February we will replace the the 32 zones [224-255].232.128.in-addr.arpa by versions using DNAMEs that indirect into in-addr.arpa.cam.ac.uk.

  2. If all goes well, during the first week in March we will get the delegations of the 32 zones replaced by DNAMEs in the parent zone 232.128.in-addr.arpa.

  3. If all still goes well, we plan to remove the 32 zones [224-255].232.128.in-addr.arpa completely on Monday 14 March.

The schedule is rather tight because we want to complete this work during full term if possible. If there have to be substantial delays, some of the later steps will be postponed until after Easter.

BIND users who want to slave zones providing reverse lookup for substantially the whole CUDN should slave "in-addr.arpa.cam.ac.uk" and "232.128.in-addr.arpa" (the latter from the CL nameservers) if they are not already doing so, and they should cease slaving the 32 zones [224-255].232.128.in-addr.arpa after step (2) but before step (3). [There will be a further announcement here when step (2) has been completed.]

Windows DNS Server users should note that we no longer recommend that they should stealth slave any zones, see

http://www-tus.csx.cam.ac.uk/windows_support/Current/activedirectory/dns/dnssec.html

If you do feel you must continue such stealth slaving, the earlier link contains advice about which versions support zones

containing DNAMEs and which do not. In particular, those using Windows 2003 or 2003R2 should cease slaving any of the zones

[224-255].232.128.in-addr.arpa as soon as possible, before step (1).

Consolidated reverse zone in-addr.arpa.cam.ac.uk

2010-11-26 - News - Chris Thompson

The sample nameserver configuration at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

has been updated to include the zone in-addr.arpa.cam.ac.uk. Until recently this was contained within the cam.ac.uk zone, but it is now a separate (unsigned) delegated zone. It currently provides the reverse lookup records for IP addresses in the range 128.232.[128-223].x but we hope to extend that to cover the whole of 128.232.[128-255].x eventually.

A description of the zone and our plans for it can be found at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/consolidated-reverse-zones.html

Please be reassured that there will be further announcements here (and probably elsewhere) before the extension to cover 128.232.[224-255].x is implemented.

Signed root zone

2010-07-19 - News - Chris Thompson

As expected, the DNS root zone became properly signed on 15 July. See http://www.root-dnssec.org/ for details.

A trust anchor for the root zone has now been added to the configuration of the CUDN central recursive nameservers (at 131.111.8.42 & 131.111.12.20), in addition to the existing one for dlv.isc.org used for "lookaside validation". There is no immediate prospect of being able to drop the latter, as there are still huge gaps in the signed delegation tree (the "ac.uk" zone, for example).

For those running their own validating recursive nameservers, the pages

https://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-validation.html
https://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-testing.html

have been updated with some relevant information.

New root hints file, and validating DNSSEC-signed zones

2010-06-21 - News - Chris Thompson

A new version of the root zone hints file has been published, and http://jackdaw.cam.ac.uk/ipreg/nsconfig/db.cache has been updated with a copy. The substantive change is the addition of an IPv6 address for i.root-servers.net. As usual with such changes, there is little urgency to update your copies.

The rest of this posting is about validating DNSSEC-signed zones.

ICANN have held their first "key signing ceremony" and appear to be on target to sign the root zone on Thursday 15 July. See http://www.root-dnssec.org/ for details. We expect to be including a trust anchor for the signed root zone on the CUDN central recursive nameservers (131.111.8.42 and 131.111.12.20) shortly after it is available.

If you are operating a validating nameserver, there are issues about the supported signing algorithms. There are currently three important ones:

Mnemonic    Code    Supported by    Can be used with which
                  BIND versions[1]    negative responses

RSASHA1        5       9.4          Only zones using NSEC
NSEC3RSASHA1   7       9.6          Zones using NSEC or NSEC3[2]
RSASHA256      8    9.6.2 or 9.7    Zones using NSEC or NSEC3

[1] or later.

[2] but as NSEC3RSASHA1 is otherwise identical to RSASHA1, it is almost invariably used with zones using NSEC3 records.

Zones signed only with algorithms unsupported by particular software will be treated by them as unsigned.

Only RSASHA1 is officially mandatory to support according to current IETF standards, but as the intention is to sign the root zone with RSASHA256, it will become effectively mandatory as well. (Other organisations are already assuming this. For example, Nominet have signed the "uk" top-level domain using RSASHA256, although they do not intend to publish a trust anchor for it other than by having a signed delegation in the root zone.)

Therefore, if you want to be able to use a trust anchor for the root zone you will need software that supports the RSASHA256 algorithm, e.g. BIND versions 9.6.2 / 9.7 or later. As an aid for checking this, the test zone dnssec-test.csi.cam.ac.uk is now signed using RSASHA256. For details on how to test, see http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-testing.html

There are no immediate plans to change the algorithm used to sign our production DNS zones from RSASHA1.

cs-nameservers-announce copies on ucam.comp.tcp-ip newsgroup

2010-06-09 - News - Chris Thompson

On Sep 30 2008, I wrote:

It has been the practice to post copies of messages posted to the cs-nameservers-announce mailing list to the local newsgroup ucam.comp.tcp-ip.

The local newsgroups ucam.* are expected to be phased out before long, so I propose that we discontinue this practice. If anyone feels differently, please let us know.

At that time, we received pleas to continue the copies to the ucam.comp.tcp-ip newsgroup for as long as it remained in existence (which has in fact been much longer than was then anticipated). However, its demise now really is imminent, see e.g.

http://ucsnews.csx.cam.ac.uk/articles/2010/03/30/newsgroups-and-bulletin-boards

Therefore I have removed the references to ucam.comp.tcp-ip from the mailing list description and from the sample.named.conf file, and this message will be the last one copied to the newsgroup.

Updates to sample.named.conf

2010-04-26 - News - Chris Thompson

There is a new sample configuration for nameservers on the CUDN at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

The following changes have been made:

Some references relating to DNSSEC validation have been added. For more details, though, consult as before

http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-validation.html

A recommended setting for "max-journal-size" is included. Without this, the journal files for incrementally updated zones will grow indefinitely, and for signed zones in particular they can become extremely large.

The most significant change concerns the zone private.cam.ac.uk. Previously, there was no delegation for this zone in cam.ac.uk. However, we have found that with the most recent versions of BIND, defining private.cam.ac.uk as either "type stub" or "type forward" in combination with using DNSSEC validation, led to validation failures due to BIND's inability to prove private.cam.ac.uk unsigned while cam.ac.uk is signed.

On consideration, we have decided to create a delegation for private.cam.ac.uk after all. (The only effect for users outside the CUDN should be that they will consistently get a REFUSED response for names in that zone, instead of sometimes getting NXDOMAIN instead.) This will also allow us to increase the number of official nameservers for private.cam.ac.uk (within the CUDN, obviously), and perhaps to sign it without having to advertise a trust anchor for it by special means.

Nameservers on the CUDN should therefore either slave private.cam.ac.uk, or not define it at all in their configuration. (Using "type stub" or "type forward" will continue to work for non-validating servers, but should be phased out.)

However, our corresponding reverse zones 16.172.in-addr.arpa through 30.172.in-addr.arpa cannot be delegated from the parent zone "172.in-addr.arpa". Luckily there are delegations there to the IANA "black hole" (AS112) servers, and this suffices to make the zones provably unsigned. Any of "type slave", "type stub" or "type forward" can be used for these zones (with or without validation) and one of them must be used or reverse lookups will fail.

Rationale for the recent changes to recommended AD configurations

2010-02-03 - News - Chris Thompson

You will probably have seen Andy Judd's message to ucam-itsupport last Friday announcing new recommendations for Active Directory and Windows DNS Server configurations within the CUDN, described more fully at

http://www-tus.csx.cam.ac.uk/windows_support/Current/activedirectory/dns/ad_dns_config_info.html

These were the result of discussions between our PC Support group and our Hostmaster group. This message gives part of the background to our thinking, and some points may be relevant to institutions not using Windows DNS Server at all.

It will be no surprise that the advice not to ("stealth") slave zones from the CUDN central (authoritative) nameservers was motivated by the deficiencies of the various versions of Windows DNS Server when slaving signed zones (not to mention other defects in its treatment of unknown DNS record types and SOA serial number handling). Not slaving zones such as cam.ac.uk does have the disadvantage that resolving of names and addresses of hosts local to the institution may fail if it is cut off from the rest of the CUDN, but we think this should be tolerated because of the other advantages.

The advice to forward requests not resolved locally to the CUDN central (recursive) nameservers may seem contrary to advice given in https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf and in previous messages to this list. In the case of Windows DNS Server configurations the primary intent was to make sure that queries for names in private.cam.ac.uk and corresponding reverse lookups worked correctly. (Configured laboriously via GUI, many zones were omitted from Windows DNS Server setups in the past.) However, there is the more general point that the central servers provide DNSSEC validation for the increasing proportion of names for which it is available, and forwarding requests to them takes advantage of that if validation is not being performed locally. We should admit, though, that the communication path between the institution and the CUDN central nameservers is not yet secured cryptographically. (If there is a fully functional validating recursive nameserver local to the institution, that could of course be used instead of the CUDN central nameservers.)

Another issue is the likelihood that we will be changing the set of reverse zones available for slaving during the next year. In particular we are likely to want to extend the scheme described at http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones which we are already using for reverse lookup of the 128.232.[128-223].x range to cover 128.232.[224-255].x as well, eliminating the 32 individual zones used for the latter range at present.

Unicode in the IP registration database

2009-12-09 - News - Chris Thompson

(These changes first went into service on 2009-12-07, but had to withdrawn due to problems with uploads, in particular. They are now back in service.)

When the Jackdaw Oracle server was moved to new hardware and upgraded to Oracle 10 earlier this year, the opportunity was taken to change the encoding it uses for character data from ISO Latin 1 to UTF-8. However, little change will have been apparent at the user interfaces, because translation from and to ISO Latin 1 were made for input and output.

This has now been changed so that all interfaces use UTF-8. In particular, the IP registration web pages now use UTF-8 encoding, and so do files downloaded from the list_ops page. Files uploaded should also be in UTF-8: invalid encodings (such as might be caused by using the ISO Latin 1 encoding instead) will be replaced by Unicode replacement characters '�' (U+FFFD).

Only those fields that are allowed to contain arbitrary text (such as equipment, location, owner, sysadmin, end_user, remarks) are affected by this change. Values (the great majority) that are in 7-bit ASCII will not be affected because it is the common subset of ISO Latin 1 and UTF-8.

We have identified a few values in the IP registration data which have suffered the unfortunate fate of being converted from ISO Latin 1 to UTF-8 twice. We will be contacting the relevant institutional COs about them.

Problem with SOA serial numbers and Windows DNS Server

2009-09-29 - News - Chris Thompson

In conjunction with PC Support we suggest the following guidelines for dealing with Windows DNS servers in the wake of the SOA serial number wrap-around:

All zones which are copied from any of the UCS servers (cam.ac.uk, private.cam.ac.uk, and the reverse zones) need to be refreshed so they have a serial number which starts 125... rather than 346... The serial number can be found in the Start of Authority tab for the zones properties.

To refresh the zones try the following steps;

  1. In a DNS MMC select the DNS server, right click and select clear cache. For any zone you copy, right click and select Transfer from Master. Check the serial number for the zone once it has loaded.

    If the serial number hasn't been updated you may have tried too soon, wait a couple more minutes and try again. However if after ten minutes it hasn't updated you can also try;

  2. If the serial number hasn't been updated delete the zone, clear the cache and re-create. Check the serial number once it has fully loaded.

  3. Final resort: delete the zone, clear the cache, delete the files from C:\Windows\System32\DNS then re-create.

In most cases methods 1 or 2 will work.

For those with older copies of notes from the Active Directory course which are being used as reference, don't. You should check your configuration information at the following locations.

http://www-tus.csx.cam.ac.uk/windows_support/Current/activedirectory/dns/configureserver.html

http://www-tus.csx.cam.ac.uk/windows_support/Current/activedirectory/dns/dnssec.html

Incidentally, Windows 2008 DNS Server is not immune to the problem (but method 1 above should normally work for it).

Problem with SOA serial numbers and Windows DNS Server

2009-09-28 - News - Chris Thompson

Last Saturday (26 September) we started to change SOA serial numbers for the zones managed by the Computing Service from "seconds since 1900" to "seconds since 1970" (the latter being familiar as the POSIX time_t value). We had made sure that this was an increase in RFC 1982 (published August 1996) terms. No version of BIND has any problem with this.

Unfortunately, we did not foresee that many versions of Windows DNS Server (apparently even those as late as Windows 2003 R2) cannot cope with this change, repeatedly attempting to transfer the zone at short intervals and discarding the result. We are seeing a great deal of churning on our authoritative nameservers as a result. (This affects servers that are fetching from 131.111.12.73 [fakedns.csx.cam.ac.uk] as well.)

It is too late for us to undo this change. If you are running Windows DNS Server and are failing to fetch cam.ac.uk and similar DNS zones, you should discard your existing copy of the zone(s). Andy Judd advises us that you "need to delete the zone in a DNS MMC and then delete the zone files from C:\Windows\System32\dns and C:\Windows\System32\dns\backup, then re-create the zone". Please ask Hostmaster and/or PC Support for assistance if necessary.

We shall be contacting the administrators of the hosts that are causing the most continuous zone-fetching activity on our servers.

Two reverse zones to be signed on Tuesday 29 September

2009-09-24 - News - Chris Thompson

We judge that the signing of the DNS zone cam.ac.uk since 3 August has been a success. We intend to start signing two reverse zones

111.131.in-addr.arpa
0.0.2.0.0.3.6.0.1.0.0.2.ip6.arpa

next Tuesday morning, 29 September 2009.

For those who stealth slave either or both of these zones, but cannot cope with signed zones, unsigned versions will remain available from fakedns.csx.cam.ac.uk [131.111.12.73]. Other relevant information may be found via the DNSSEC-related links on

https://jackdaw.cam.ac.uk/ipreg/nsconfig/

In future, we may not always announce when particular zones are expected to become signed.

Any problems should be referred to hostmaster@ucs.cam.ac.uk

cam.ac.uk to be signed on Monday 3 August

2009-07-31 - News - Chris Thompson

We intend to make cam.ac.uk a signed DNS zone next Monday morning, 3 August 2009. We believe that those most likely to be adversely affected are the Windows DNS Server clients within the CUDN that are slaving it. The following is taken from

http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-windows.html

which we will update in the light of experience.

Only Windows 2008 R2 is practically trouble-free in this context. Earlier versions will generate very large numbers of messages in the system log about unknown record types, and may not result in a usable copy of the zone.

However, with Windows 2003 R2 or Windows 2008 you can use the registry option described at

(using the 0x2 setting) and this should allow you to slave a signed zone, although not actually to use the signatures.

For other versions, or in any case if problems arise, you can slave the zone from 131.111.12.73 [fakedns.csx.cam.ac.uk] instead of from 131.111.8.37 and/or 131.111.12.37. This server provides unsigned versions of all the zones described as available for slaving from

the latter addresses in

http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

for transfer to clients within within the CUDN. It should not be used for any other purpose.

Any problems should be referred to hostmaster@ucs.cam.ac.uk.

BIND security alert

2009-07-29 - News - Chris Thompson

If you are using BIND and are not already aware of it, please see the security advisory at https://www.isc.org/node/474

This is high severity denial-of-service bug which is being exploited in the wild. Nameservers are vulnerable if

  • They have any zone of "type master", whose name is known to the attacker. Note that this includes zones such as "localhost" (but apparently not BIND's generated "automatic empty zones").

  • The attacker can get a DNS update request through to the server. For example, those with a port 53 block at the CUDN border router can be attacked (directly) only from within the CUDN. Access controls within BIND cannot protect against the vulnerability.

Those who use versions of BIND supplied with their operating system should look for advisories from their respective suppliers.

SOA serial numbers in UCS-maintained zones

2009-07-21 - News - Chris Thompson

This should only be of concern to those who look at SOA serial numbers for diagnostic information. Up to now we have used the

<4-digit-year><2-digit-month><2-digit-day><2-more-digits>

format for the zones the Computing Service maintains. We are about to switch to using "seconds since 1900-01-01" (not 1970-01-01, because we need the change to be an increase, in RFC 1982 terms). This is part of the preparations for using DNSSEC-signed zones, where some SOA serial increases are imposed by BIND as part of the re-signing operations.

All of our zones now contain an HINFO record at the apex which contains version information in the old format; e.g.

$ dig +short hinfo cam.ac.uk
"SERIAL" "2009072120"

We expect these to remain a human-readable version indication, although not necessarily in exactly this format.

More about DNSSEC validation, and signing the cam.ac.uk zone

2009-07-01 - News - Chris Thompson

The web page describing how to set up DNSSEC validation on your own recursive nameservers, using the dlv.isc.org lookaside validation zone dlv.isc.org, has been updated and is now at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-validation.html

We continue to make progress towards signing cam.ac.uk. The previous signed near-clone "cam.test" will be removed at the end of this week. Instead we have a new such zone "dnssec-test.csi.cam.ac.uk" which is properly delegated and registered at dlv.isc.org. Instructions on how to slave it or validate against it are at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-testing.html

We have had almost no feedback so far. We would like to hear from anyone who has successfully slaved it, but even more from those who tried and failed. We believe that much old nameserver software will be unable to cope, and expect to have to provide "dumbed-down" unsigned versions of the signed zones for such clients. We need to estimate how large the demand will be for such a service.

Recursive nameservers using DNSSEC validation

2009-06-16 - News - Chris Thompson

We have been using DNSSEC validation on the main recursive nameservers at

131.111.8.42   or 2001:630:200:8080::d:0
131.111.12.20  or 2001:630:200:8120::d:1

since the morning of Tuesday 9 June, and no significant problems have arisen. We now expect this state to persist indefinitely.

Therefore, will all those who kindly assisted us by pointing their resolvers at the testing validating nameservers please switch back to using the regular ones. We shall be monitoring the use of the testing addresses and in due course contacting those who are still using them. Eventually they will be reused for other testing purposes.

More about DNSSEC validation, and signing the cam.ac.uk zone

2009-05-28 - News - Chris Thompson

Further to the request posted on 6 May to try using the testdns*.csi validating nameservers (and with thanks to the few who did so!) there have been some queries as to how you can configure DNSSEC validation in your own recursive nameservers. There are some notes on that here:

http://people.pwf.cam.ac.uk/cet1/dnssec-validation.html

As a separate but related exercise, we plan to sign our own zones, starting with cam.ac.uk, as soon as we can. To investigate the problems involved, we have set up a signed almost-clone of cam.ac.uk, called cam.test, and made it available in various ways within the CUDN. Some of the things you could try doing with it are described here:

http://people.pwf.cam.ac.uk/cet1/signed-cam.html

[The fact that these web pages are in a personal space rather than in, say, http://jackdaw.cam.ac.uk/ipreg/ emphasizes their temporary and provisional nature. Please don't let that stop you reading them!]

Recursive nameservers using DNSSEC validation available for testing

2009-05-06 - News - Chris Thompson

We are hoping to turn on DNSSEC ("Secure DNS") validation in our main central recursive nameservers within the next few weeks. We have set up testing nameservers with essentially the expected configuration, and Computing Service staff have already been exercising them. You are now invited to do the same: details can be found at

http://people.pwf.cam.ac.uk/cet1/dnssec-testing.html

Use of DNAMEs for reverse lookup of CUDN addresses

2009-03-18 - News - Chris Thompson

We have started to use a scheme involving DNAMEs (domain aliases) for the reverse lookup up of some IP addresses within the CUDN. The primary motivation is to reduce the number of individual reverse zones. A description of the mechanism, written for an audience not restricted to the university, can be found in

http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones
  • Moved to https://www.dns.cam.ac.uk/domains/reverse/

At the moment we are using this method for these address ranges:

  • 192.153.213.*

  • 192.84.5.*

    • these subnets are or will be used for CUDN infrastructure (although within the CUDN, the corresponding reverse zones are not listed in the sample.named.conf configuration)

  • 128.232.[128-223].*

    • some of this address space will be used for Eduroam

Some nameserver software (especially Windows DNS Server) may be unable to cope with zones containing DNAMEs: they will have to avoid stealth slaving (for example) 232.128.in-addr.arpa. We don't believe that any stub resolvers fail to cope with the "synthesised CNAMEs" generated from DNAMEs, although at least some versions of the glibc resolver log warning messages about the DNAME (but give the right answer anyway). If anyone experiences problems as a result of what we are doing, please let us know.

In the light of experience, we may later extend this scheme to other address ranges, e.g. 128.232.[224-255].* which is currently covered by 32 separate reverse zones. However, we will give plenty of warning before making such a change.

Balancing the use of CUDN central recursive nameservers

2009-03-18 - News - Chris Thompson

The Computing Service provides two general-purpose recursive nameservers for use within the CUDN, at IPv4 addresses 131.111.8.42 and 131.111.12.20 (or IPv6 addresses 2001:630:200:8080::d:0 and 2001:630:200:8120::d:1).

Historically, there were compelling reasons to favour 131.111.8.42 over 131.111.12.20, and therefore to list them in that order in resolver configurations. The machine servicing 131.111.12.20 was severely overloaded and often had much poorer response times.

For the last two years, this has not been the case. The two services run on machines with equal power and for nearly all locations within the CUDN there is no reason to prefer one over the other. Since last September, one of them has been in our main machine room on the New Museums Site, and one at Redstone, providing improved physical redundancy.

However. we observe that the load on 131.111.8.42 is still several times that on 131.111.12.20, presumably as a result of the historical situation. For a while now we have been randomising the order in which the two addresses appear in the "nameservers:" line generated when the "register" or "infofor*" functions are used on the ipreg/single_ops web page, but we suspect that COs rarely act on that when actually setting up resolver configurations.

We would like to encourage you to do a bit of randomising yourselves, or even to deliberately prefer 131.111.12.20 to redress the current imbalance. If you have resolvers which support it, and you are configuring only these two addresses as nameservers, then you could sensibly use "options rotate" to randomise the order they are tried within a single host. (Unfortunately, this doesn't work well if you have a preferred local resolver and want to use the two CS nameservers only as backups.)

Frequency of DNS updates

2009-03-17 - News - Chris Thompson

This message, like the earlier ones referred to, was sent to ucam-itsupport at lists because it is of concern to all IPreg database updaters, not just to stealth slave administrators. However, it has been plausibly suggested that they ought to have been sent to cs-nameservers-announce at lists as well, if only so that they appear in its archives. Therefore, this one is being so sent!

Subsequent to the changes of schedule to every 12 hours (September) and every 6 hours (November), we have now made a further increase in the number of (potential) updates to our DNS zones. Currently the regular update job runs at approximately

01:00, 09:00, 13:00, 17:00 and 21:00

each day (the exact times are subject to variation and should not be relied upon). We are reserving the 05:00 slot, at which actual changes would be very rare, for other maintenance activity.

The "refresh" parameter for these zones has also been reduced from 6 hours to 4 hours: this is the amount by which stealth slaves may be out of date (in the absence of network problems). The TTL values for individual records remains 24 hours: this is how long they can remain in caches across the Internet.

Representing network access controls in the database

2008-12-15 - News - Chris Thompson

(Updated and partly obsoleted on 2014-05-20)

(Updated 2009-01-13)

Various exceptions to the general network access controls are applied at CUDN routers for some individual IP addresses. Some of these are at the border routers between the CUDN and JANET, and others at the individual CUDN routers interfacing to institutional networks.

We have implemented a scheme which we hope will enable us to keep better control over these exceptions. When an exception is created for a registered IP address, that address is added to one of the following anames

  • janet-acl.net.private.cam.ac.uk for exceptions at the border routers, usually permitting some network traffic that would otherwise be blocked,

  • cudn-acl.net.private.cam.ac.uk for exceptions at the local CUDN routers, usually allowing some use of high-numbered ports for those vlans for which such a restriction is imposed.

  • block-list.net.private.cam.ac.uk for addresses for which all IP traffic is completely blocked, usually as the result of a security incident.

As long as the attachment to the aname remains, it prevents the main registration from being rescinded. The intent is that this will result in the institutional COs requesting removal of the exception at that point.

If the IP address is not registered, then it is first registered as reserved.net.cam.ac.uk or reserved.net.private.cam.ac.uk as appropriate, and then processed as above. This prevents it being reused while the exception still exist. (Some of these cases are due to the fact that we did not have the scheme in the past, and there are several now-unregistered IP addresses whose exceptions were never removed.)

Note that this apparatus only deals with exceptions for individual IP addresses, not those for whole subnets.

Requests for the creation or removal of network access control exceptions should be sent to cert@cam.ac.uk.

cs-nameservers-announce copies on ucam.comp.tcp-ip newsgroup

2008-09-30 - News - Chris Thompson

It has been the practice to post copies of messages posted to the cs-nameservers-announce mailing list to the local newsgroup ucam.comp.tcp-ip. This is promised both in the descriptive text for the mailing list, and in the initial comments in

The local newsgroups ucam.* are expected to be phased out before long, so I propose that we discontinue this practice. If anyone feels differently, please let us know.

The archives of the mailing list are accessible to non-members, at

and there is no intention to change that.

pmms.cam.ac.uk zone should no longer be slaved

2008-08-03 - News - Chris Thompson

The zone pmms.cam.ac.uk has been removed from the list of zones that may be slaved given in

http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf

Historically, this zone was a clone of "dpmms.cam.ac.uk", but it is now essentially empty and will soon be removed entirely. If your nameserver currently slaves pmms.cam.ac.uk, you should remove it from its configuration file as soon as is convenient.

Independently, some comments have been added to the sample configuration file about IPv6 addresses that can be used as alternative to the IPv4 ones for fetching zones or forwarding requests, for those whose nameservers themselves have IPv6 connectivity.

Multiple DNS implementations vulnerable to cache poisoning

2008-07-09 - News - Chris Thompson

There has been a lot of recent publicity, some of it rather garbled, on this subject. Please refer to

for an authoritative account. The remainder of this note refers specifically to what to do if you are running a recursive nameserver using BIND. (Authoritative-only servers have [almost] no cache and are not affected.)

For full details, see http://www.isc.org/ , especially the links under "Hot Topics" - "Upgrade Now!". In summary, ISC have released the following new versions:

if you are using upgrade to or if you are prepared use a "beta" version BIND 9.5.x 9.5,0-P1 9.5.1b1 BIND 9.4.x 9.4.2-P1 9.4.3b2 BIND 9.3.x 9.3.5-P1 BIND 9.2.x (or earlier) - no fix available - time to move!

Note that the earlier round of changes in July last year (versions 9.2.8-P1, 9.3.4-P1, 9.4.1-P1, 9.5.0a6), that improve defences against cache poisoning by randomising query ids, are no longer considered adequate. The new fixes rework the randomisation of query ids and also randomise the UDP port numbers used to make queries. Note that if you specify a specific port in the "query-source" setting, e.g. to work your way through a recalcitrant firewall, you will lose much of the advantage of the new fixes.

If you are not in a position to upgrade, you can forward all requests to other recursive nameservers that you trust. The recursive nameservers provided by the Computing Service, at IP addresses 131.111.8.42 and 131.111.12.20, are now running BIND 9.4.2-P1 and can be used in this way by hosts on the CUDN.

If you need advice about this, please contact hostmaster@ucs.cam.ac.uk.

General relaxation of the rules on use of sub-domains

2008-05-13 - News - Chris Thompson

The restructuring of the database to allow free use of sub-domains, mooted in a previous article, has now been implemented.

As before, all names in the database have an associated domain whose value must be in a predefined table and is used to control user access. However this can now be any suffix part of the name following a dot (or it can be the whole name). If a CO has access to the domain dept.cam.ac.uk, then they can register names such as foobar.dept.cam.ac.uk (as previously) or foo.bar.dept.cam.ac.uk, or even dept.cam.ac.uk alone (although this last may be inadvisable). Such names can be used for "boxes" as registered and rescinded via the single_ops page, and also (to the rather limited extent that COs have delegated control over them) for vboxes and anames.

There are cases when one already registered domain name is a suffix of another, e.g. sub.dept.cam.ac.uk and dept.cam.ac.uk. Often these are in the same management zone and the longer name is present only to satisfy the previously enforced constraints. In these cases we shall phase out the now unnecessary domain. However, in a few cases they are in different management zones, with different sets of COs having access to them. It is possible for a CO with access only to dept.cam.ac.uk to register a name such as foobar.sub.dept.cam.ac.uk, but its domain part will be taken as dept.cam.ac.uk and not sub.dept.cam.ac.uk. This is likely to cause confusion, and we will be relying on the good sense of COs to avoid such situations.

For CNAMEs, the mechanism using strip_components described in the previous article still exists at the moment, but it will be soon be replaced by a cname_ops web page in which the domain part is deduced automatically, as for the other database object types mentioned above, rather than having to be specified explicitly. (Now implemented, 2008-06-05.)

We advise that COs should not use sub-domains too profligately, and plan their naming schemes carefully. Any questions about the new facilities should be emailed to us.

IPv6 addresses for the root nameservers

2008-02-05 - News - Chris Thompson

Six of the thirteen root nameservers are now advertising IPv6 addresses. There is some background information about this change at

There is also a new root hints file with these addresses added, and the copy at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/db.cache

has been updated.

Of course, the IPv6 addresses are not useful if your nameserver does not (yet) have IPv6 connectivity, but they should do no harm, and on general principles it's inadvisable to let one's root hints file get too out of date.

More changes to the sample nameserver configuration

2008-01-30 - News - Chris Thompson

A number of changes have been made to the sample configuration for "stealth" nameservers at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/

None of these require urgent action.

First, the set of locally defined empty reverse zones, intended to stop queries for the corresponding IP addresses being sent to the Internet's root nameservers, has been brought into line with those created automatically by BIND 9.4 and later. Some of the IP address ranges covered are larger than before, while some are smaller. If you are actually running BIND 9.4 or later, then you can omit most of these zone definitions, but note that "0.in-addr.arpa" should not yet be omitted (as of BIND 9.4.2), and nor should those for the RFC1918 institution-wide private addresses.

There are new versions of the zone files db.null, db.localhost, and db.localhost-rev. The first has been made identical to that which BIND 9.4 generates internally, except that the SOA.mname value is "localhost" rather than a copy of the zone name (this avoids a warning message from BIND when it is loaded). The other two, intended to provide forward and reverse lookup for the name "localhost", have been modified in a similar way. These files no longer have "sample" in their name, because they no longer require any local modification before being used by BIND.

Some changes to sample.named.conf have been made in support of IPv6. The CUDN IPv6 range 2001:630:200::/48 has been added to the "camnets" ACL definition: this becomes relevant if you are running a nameserver providing service over IPv6. The corresponding reverse zone "0.0.2.0.0.3.6.0.1.0.0.2.ip6.arpa" has been added to the list that can be slaved from 131.111.8.37 and 131.111.12.37: it may be desirable to do that if your nameserver is providing a lookup service to clients on IPv6-enabled networks, whether it uses IPv6 itself or not.

In addition, a number of comments have been corrected or clarified. Note in particular that BIND does not require a "controls" statement in the configuration file to make run-time control via the "rndc" command work. See the comments for more details. It should only rarely be necessary to actually restart a BIND daemon due to a change in its configuration.

Change of address of a root nameserver

2007-11-03 - News - Chris Thompson

The IP address of one of the root nameservers, l.root-servers.net, has changed from 198.32.64.12 to 199.7.83.42. (Such changes are rare: the last one was in January 2004.)

If you are running a nameserver with a root hints zone file, that should be updated. There are a number of ways of generating a new version, but the official with-comments one is at

ftp://ftp.internic.net/domain/named.root

and there is a copy of that locally at

http://jackdaw.cam.ac.uk/ipreg/nsconfig/db.cache

Modern versions of BIND 9 have a compiled-in version of the root hints zone to use if none is defined in the configuration file. As a result of this change, the compiled-in version will be out of date for existing BIND versions: a corrected version has been promised for the next versions of BIND 9.3.x, 9.4.x and 9.5.x.

Using a slightly out-of-date root hints zone is unlikely to cause serious problems, but it is something that should not be allowed to persist indefinitely.

Relaxation of the name-to-domain rules for CNAMEs

2007-08-23 - News - Chris Thompson

All names in the database have an associated domain whose value must be in a predefined table and is used to control user access. Until now, the domain has always been formed by stripping exactly one leading component from the name. This leads, for example, to the often unwelcome advice to use www-foo.dept.cam.ac.uk rather than www.foo.dept.cam.ac.uk.

We have tentative plans to restructure the database to liberalise this constraint everywhere, but this is a major undertaking and will not happen soon. However, we have been able to provide partial relief in the special case of CNAMEs.

In the table_ops page under object type cname there is now a field strip_components. This can be set to a number which controls how many leading components are stripped from the name value to convert it to a domain. (Note that it has no affect on the treatment of target_name.) For example, setting it to 2 for www.foo.dept.cam.ac.uk associates it with the domain dept.cam.ac.uk rather than the (probably non-existent) domain foo.dept.cam.ac.uk. Leaving the field null is equivalent to setting it to 1. (0 is an allowed value, but note that creating a CNAME dept.cam.ac.uk is disallowed if there is a mail domain with that name.)

Changes to the sample nameserver configuration

2007-08-20 - News - Chris Thompson

Three changes have been made to the sample configuration for "stealth" slave nameservers on the CUDN.

First, the configuration files have been moved from

ftp://ftp.cus.cam.ac.uk/pub/IP/Cambridge

to

http://jackdaw.cam.ac.uk/ipreg/nsconfig

and internal references have been adjusted to match. The old location will contain copies of the updated files only for a very limited overlap period.

Second, the sample.named.conf file now recommends use of

notify no;

in the "options" statement. BIND is by default profligate with its use of notify messages, and a purely stealth nameserver can and should dispense with them. See the comments in the file for what to do if you also master or officially slave other DNS zones.

Third, comments in the file previously suggested that one could use a "type forward" zone for private.cam.ac.uk. Although this does work for the corresponding private reverse zones, it does not for the forward zone if cam.ac.uk itself is being slaved. In that case, if you don't want to slave the whole of private.cam.ac.uk, then you should use a "type stub" zone instead. See the new comments for details.

Recent problems with CUDN central nameservers

2007-07-16 - News - Chris Thompson

In the normal state, one machine hosts 131.111.8.37 [authdns0.csx] and 131.111.8.42 [recdns0.csx] while another hosts 131.111.12.37 [authdns1.csx] and 131.111.12.20 [recdns1.csx]. (On each machine the different nameservers run in separate Solaris 10 zones.) On the evening of Friday 13 July, work being done on the second machine (in preparation for keeping the machines running during the electrical testing work on Sunday) caused it to lose power unexpectedly, and recovery took us some time, so that the authdns1 and recdns1 services were unavailable from about 17:24 to 19:20.

Unfortunately, our recovery procedure was flawed, and introduced creeping corruption into the filing system. The relevant machine became unusable at about 14:45 today (Monday 16 July). In order to get the most important services functional again,

  • the recursive nameserver at 131.111.12.20 [recdns1.csx] was moved to a new Solaris 10 zone on the machine already hosting authdns0 & recdns0: this was functional from about 15:45 (although there were some short interruptions later);

  • the non-recursive authoritative nameserver at 131.111.12.37 [authdns1.csx] had its address added to those being serviced by the authdns0 nameserver at about 20:10 this evening.

Of course, we hope to get the failed machine operational again as soon as possible, and authdns1 & recdns1 will then be moved back to it.

Please send any queries about these incidents or their consequences to hostmaster@ucs.cam.ac.uk.

Splitting of authoritative from recursive nameservers

2007-04-23 - News - Chris Thompson

A few weeks ago we told you

We currently plan to lock down the recursive nameservers at 131.111.8.42 and 131.111.12.20, so that they do not respond to queries from outside the CUDN and also do not allow zone transfers, during the first week of the Easter term (23-27 April). We will update you on this closer to the time.

We now intend to make these changes, at least insofar as zone transfers are concerned, early on Thursday 26 April.

We would like to thank all those who made changes to nameservers in their jurisdiction to fetch DNS zones from 131.111.8.37 / 131.111.12.37 instead. Logging has shown that the number of hosts still fetching from 131.111.8.42 / 131.111.12.20 is now quite small. Some final reminders will be sent to those who still have not made the change.

Splitting of authoritative from recursive nameservers

2007-03-21 - News - Chris Thompson

Some minor changes have been made to the sample configuration for "stealth" slave nameservers on the CUDN at

ftp://ftp.cus.cam.ac.uk/pub/IP/Cambridge/sample.named.conf

Firstly, one of the MRC-CBU subnets was incorrectly omitted from the "camnets" ACL, and has been added.

Secondly, questions were asked about the setting of "forwarders" in the "options" statement, and so I have added some comments about that. We used to recommend its use, but have not done so for some time now, except in situations where the nameserver doing the forwarding does not have full access to the Internet. However, if query forwarding is used, it should always be to recursive nameservers, hence to 131.111.8.42 and 131.111.12.20 rather than to the authoritative but non-recursive nameservers at 131.111.8.37 and 131.111.12.37.

We are now logging all outgoing zone transfers from 131.111.8.42 and 131.111.12.20, and will be contacting users who have not made the change to fetch from 131.111.8.37 and 131.111.12.37 instead, as time and effort permit. Help us by making the change before we get around to you!

We currently plan to lock down the recursive nameservers at 131.111.8.42 and 131.111.12.20, so that they do not respond to queries from outside the CUDN and also do not allow zone transfers, during the first week of the Easter term (23-27 April). We will update you on this closer to the time.

Splitting of authoritative from recursive nameservers

2007-03-08 - News - Chris Thompson

There is a new version of the sample configuration for "unofficial" slave nameservers on the CUDN at

ftp://ftp.cus.cam.ac.uk/pub/IP/Cambridge/sample.named.conf

This is a major revision, which includes new reverse zones, advice on access control settings, and several other changes. However the most important, and one which anyone managing such a slave nameserver should act on as soon as possible, is that the zones which were previously being fetched from

 masters { 131.111.8.42; 131.111.12.20; };

should now be fetched from

 masters { 131.111.8.37; 131.111.12.37; };

instead. The background to this is described below.

We are in the process of separating the authoritative nameservers for the Cambridge University DNS zones from those providing a recursive DNS lookup service for clients on the CUDN. To minimise the pain, it is the latter which have to retain the existing IP addresses. When the transformation is complete we will have

authdns0.csx.cam.ac.uk [131.111.8.37]
authdns1.csx.cam.ac.uk [131.111.12.37]

providing non-recursive authoritative access to our zones (and zone transfer for appropriate zones to clients on the CUDN) while

recdns0.csx.cam.ac.uk [131.111.8.42]
recdns1.csx.cam.ac.uk [131.111.12.20]

will provide a recursive lookup service to CUDN clients (but not zone transfers), and no service at all outside the CUDN.

Announcement list converted to Mailman

2006-10-04 - News - Chris Thompson

The mailing list cs-nameservers-announce@lists.cam.ac.uk has been converted from an old-style list to a Mailman list. (See https://www.lists.cam.ac.uk for background information.)

The list options attempt to match the previous state of affairs. The list is moderated, and subscription requires administrator action (but you can now request it via the web pages as well as by message). On the other hand, unsubscription by end-user is enabled.

Digests are not available. Archives will be kept and can be read even by non-members.

Non-interactive use of the IP registration database

2006-05-08 - News - Chris Thompson

There are situations in which there is a requirement for non-interactive access to the IP registration database. A new method of using the web interface has been provided, in which cookies with a long life can be downloaded and used to authenticate subsequent non-interactive https access, for example by using programs such as curl.

See the download-cookie page on Jackdaw for a more complete description of the scheme. At the moment only the list_ops page can be used with downloaded cookies for the ipreg realm, and it requires a certain amount of reverse engineering to be used with a non-interactive tool. Pages more suitable for this sort of use may be provided later in the light of experience. The current state is quite experimental and we would ask anyone planning to use it in production to let us know.

Some departments and colleges are using firewall software written by Ben McKeegan at Netservers Ltd., which interacts with the IP registration database using the old method of authentication via an Oracle account password. A version of this software that uses downloaded cookies as described above is under development and we hope it will be available soon.

For several reasons we want to restrict the number of people who have SQL-level access to the underlying Oracle database, and there has been a recent purge of unused Oracle accounts. If you have good reason to need such access to the IP registration part of the database, please let us know.

More delegated control of CNAMEs

2005-12-19 - News - Chris Thompson

Up until now ordinary users of the IP registration database have only been allowed to modify certain fields (targetname, purpose, remarks) in existing CNAMEs, and in particular not to create or delete them. These restrictions have now been removed. CNAMEs for which both the name and the targetname are in domains which the user has access to can be freely created, updated and deleted, subject to the existing consistency constraints: for example, that the target_name actually refers to an existing database record.

Such operations can be done using the table_ops page after selecting object type cname, in ways that will be familiar to those who have performed modifications to existing CNAMEs in the past. We recognise that this interface is somewhat clunky, and a tailored cname_ops web page may be made available in the future.

There is a maximum number of CNAMEs associated with each management zone in the database, which can be altered only by us. hese limits have been set high enough that we do not expect sensible use of CNAMEs to reach them very often. Users will be expected to review their existing CNAMEs before asking for an increase.

Related Links

Provided by Cambridge University Information Services
Contact: ip-register@uis.cam.ac.uk

This page updated: 2024-07-26 09:47:45

Privacy information
Cookie information

Study at Cambridge

About the University

Research at Cambridge