Hi,
TL;DR
-----
DNSSEC validation will be enabled on BitFolk's resolvers on Monday
29th April.
The Plan
--------
After consultation¹, we've come up with a plan for enabling DNSSEC
validation on BitFolk's resolvers:
0. As of Wednesday 27th a test resolver has been available on
85.119.80.243, with validation enabled. You can either query
through it directly, e.g.:
dig -t a www.dnssec-failed.org @85.119.80.243
dig -t test.dnssec-or-not.net @85.119.80.243
or replace all IPs in your /etc/resolv.conf to send all your DNS
queries through it.
1. Sometime on Saturday 30th March (tomorrow) we'll enable Unbound's
"permissive mode" which performs validation and logs errors but
always passes answers back to clients anyway:
http://unbound.net/documentation/howto_turnoff_dnssec.html
Note that this can give the impression that DNSSEC is in use, but
it is strictly for testing and you are achieving no security
benefit while this setting is in effect.
2. Around Saturday 6th April we'll review the logs to see what sort
of impact real validation will have.
We will not be examining each and every failure and we will not
be providing per-customer details; it is your responsibility to
make use of the test resolver if you wish to test your own
queries.
3. Provided the results of stage 2 are not too shocking, validation
will be switched on sometime on Monday 29th April, deliberately a
working day so that those of you using your VPSes for business
purposes will hopefully be around to spot any issues in the
unlikely event of anything breaking.
Frequently Asked Questions
--------------------------
- What is DNSSEC?
DNSSEC is a means by which DNS domain owners can digitally sign
records in their zones, so that DNS resolvers can check that the
answers they are receiving have not been tampered with at any
stage.
Aside from routine mangling of DNS responses done by local
resolvers not under your control (think: the built-in DNS resolver
in the access point of your hotel, or an ISP resolver that for
some reason is set to monetise particular kinds of queries), there
are other threats such as the hijacking for DNS for popular or
critical sites.
Additionally, digital signing of zone content is needed before you
can trust other secure data that might be stored in the DNS such
as cryptographic public keys, e.g. SSH host keys and DANE data.
RFC 3833 - Threat Analysis of the Domain Name System (DNS):
http://tools.ietf.org/html/rfc3833
If a DNS zone is DNSSEC-signed but the signatures fail validation,
the query will typically fail with a SERVFAIL response instead of
the expected answer.
- Do I need to do anything?
No; validation is configured in the resolver, and BitFolk runs the
resolvers that are listed by default in your /etc/resolv.conf.
More and more resolvers will start enabling DNSSEC so you may like
to test it out for yourself ahead of time though.
- I'm running a DNS server on my VPS for my domain. Do I need to change
anything?
No; this is about the DNS resolvers you use which are defined in
your /etc/resolv.conf, not any DNS server you might be running to
serve authoritative DNS data. Whether or not you enable DNSSEC
signing for your domain is a separate (and more complicated)
issue.
- Does this mean bitfolk.com will be DNSSEC-signed?
No; having resolvers that validate DNSSEC signatures is a necessary
first step before we can consider DNSSEC-signing bitfolk.com and
bitfolk.co.uk.
- Am I secure as soon as this is enabled?
Only if the domains you query have enabled DNSSEC. And only for
the things that DNSSEC actually protects you against.
If you have any further questions about any of this, please do reply
here or contact us off-list at support(a)bitfolk.com.
Cheers,
Andy
¹ Thread on users list starts here:
http://lists.bitfolk.com/lurker/message/20130326.230706.21113786.en.html
--
http://bitfolk.com/ -- No-nonsense VPS hosting
> The optimum programming team size is 1.
Has Jurassic Park taught us nothing? — pfilandr
Hi,
At approximately 00:45Z this morning, customers with DNS domains
hosted by BitFolk would have started receiving lots of CRITICAL and
then RECOVERY alerts which went on through the night. Also,
customers who monitor external DNS servers with their own software
may have seen similar issues.
This was due to rate-limiting of UDP/53 traffic put in place by our
transit provider without our prior knowledge. I have been in
discussion with them and the change was backed out at around 08:20Z.
There is no need for you to take any action.
We are still investigating the full extent of what took place. If
you have any evidence that DNS queries (other than those from your
monitoring software) failed, I would be interested to know. Please
do let me know off-list.
Now that the rate-limiting is disabled I do not expect further
problems but I will follow up on what happened when I have more
information.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Although BitFolk only officially supports 32-bit VMs at present, a
couple of customers have installed 64-bit Linux distributions. They
have then found the rescue environment not particularly useful since
its 32-bit kernel can't execute any of their binaries.
I have now done an upgrade of the rescue environment's image to
Debian wheezy and used a 64-bit install. An x86_64 kernel can
execute i686 binaries as well, so this will work for everyone and is
in any case a prerequisite for supporting 64-bit installs.
For more information on the rescue environment:
https://tools.bitfolk.com/wiki/Rescue
(General support for 64-bit installs is still not here, but is not
far off, and is a topic for another day)
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Between around 1715Z and around 1940Z today there was intermittent
packet loss on both IPv4 and IPv6 to some destinations.
This coincided with some planned maintenance by our transit provider
so it was initially thought that something had gone wrong there. It
has so far been determined that it was actually a problem at the
LINX peering point, and unrelated to their maintenance.
Now that they've shifted traffic temporarily away from LINX the
issue appears to have been resolved.
Apologies for any disruption this may have caused you.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
If you don't have any domain names for which BitFolk serves
secondary DNS for then you can ignore the rest of this email. This
is mainly of interest for users of our secondary DNS service:
https://tools.bitfolk.com/wiki/Secondary_DNS_service
I've decided to rename a.authns.bitfolk.com to
a.authns.bitfolk.co.uk in order to have authoritative server names
in two different TLDs. This is so that your domains will still be
served in the event of some calamity such as one of those two TLDs
breaking, or one of those domains unexpectedly expiring.
Therefore when you find time you should adjust your registrar
details and zone files to list a.authns.bitfolk.co.uk instead of
a.authns.bitfolk.com.
There is no rush; a.authns.bitfolk.com remains in existence, will
always have the same IP address as a.authns.bitfolk.co.uk, and there
is no intention to move away from bitfolk.com in the future, so you
can put this off for as long as you like.
b.authns.bitfolk.com and c.authns.bitfolk.com remain unchanged.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
On Sat, Mar 02, 2013 at 07:13:37AM +0100, Andreas Olsson wrote:
> On Sat, Mar 2, 2013, at 2:40, Andy Smith wrote:
> > A flaw in the Linux kernel introduced in 3.3 allows a local user to
> > crash the kernel or obtain root access. Those running new enough
> > distributions (notably including Ubuntu 12.04) are vulnerable, so
> > please check whether you need to update.
> >
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1763
> > http://lwn.net/Articles/540082/
>
> Sure about Ubuntu 12.04? It running a 3.2 kernel it really shouldn't be
> affected.
No, not sure; I was only going by:
http://www.ubuntu.com/usn/usn-1749-1/
but I see that whilst it mentions 12.04, it also says Quantal (which
is 12.10).
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
