eNovance RAWR!! team @ Polar Hero Race

A couple of month back, we decided to run a spartan-type-of-race-but-in-the-snow. A team was born: RAWR!! We trained together for about a month; climbing the Mont-Royal with sandbags, and running under -20 degrees (Celsius) after work.

Eight of us from the Montreal office ran and climbed the Polar Hero Race this Saturday morning, February 22nd.

Please join me in congratulating them for they are official polar heroes!!

A big thank you to Jean Norman for backing us up and eNovance for sponsoring and supporting this kind of extra-curricular activity!!

Here is a footage of the race:

The track record can be found here.

More info on the Polar Hero Race event.

And more pictures thanks to Sylvain Granier from mtlblog.com!

RAWR!! team

RAWR!! team


DNSaaS with Designate, PowerDNS and NSD4

As part of our OpenStack Professional Services and Managed Services entities, the need to have a DNS as a service has been growing for a while now.

As you all already know (I hope! :)), eNovance is a major contributor to the different Openstack projects, no need to argue about that. One of our latest recruits is Designate, formerly known as the Moniker project.

I have been working together with Artom Lifshitz, one of our brilliant engineer, on contributing to Designate. At the OpenStack summit in Hong Kong I attended a presentation of Designate by Kiall Mac Innes and Patrick Galbraith from HP who have been working on making the project happen.

Introducing Designate

Designate is a DNS as-a-service project, it is intended to provide a DNS service for creating, updating, maintaining and deleting DNS data using its API, as well as providing DNS resolution for users.

In a nutshell, the main bricks of Designate are the following:

  • Authentication is handled by keystone

  • A REST API for user to interact with the DNS back-end

  • Designate Central service that handles RPC requests via the MQ

  • A DNS back-end that stores and delivers requests. Currently supported back-ends are PowerDNS, MySQLBind, and Bind.

Complete architecture documentation can be found on readthedocs: http://designate.readthedocs.org/en/latest/architecture.html

Designate @ eNovance


In order for us, at eNovance, to work with Designate, there were a couple of prerequisites:

  • being able to seamlessly import all of our existing DNS zones

  • store the DNS entries in a database for internal queries

  • have slave DNS servers in our DMZ to deliver our DNS services to the Internet

Why NSD?

As we did not want every public DNS server to have a local MySQL (slave) database, we chose NSD because it:

  • offered the simplicity of having a single-flat-file configuration

  • coupled with scalability

  • and, most important, security and stability reasons

The architecture

In a nutshell, our Designate architecture has:

  • Keystone as authentication back-end

  • PowerDNS as back-end and internal DNS server

  • NSD4 as public DNS servers

A drawing says more than a thousand words..

architecture schema

Bind-like zonefile import/export

An import/export functionality is needed, and has just been merged allowing for domains to be imported and exported from BIND9 format zonefiles. Big-up goes to Artom Lifshitz for his work on this feature.

You can find more details in the relevant blueprint: https://blueprints.launchpad.net/designate/+spec/domain-import-export

A dedicated article will be published about this feature.

Designate notification handlers

As creating/deleting zones is always a tricky business when no database is sitting behind the DNS server, we took the chance to develop hooks based on (what was at the time) the unreleased NSD4. Fortunately, NSD4 has been officially released on October 29th. Why did we choose NSD4 and not NSD3? Mainly because it includes nsd-control(8), a remote server control utility that takes care of critical actions that are not handled by AXFR and IXFR.

Introducing Designate Notification Handler, aka dnh, written by Artom Lifshitz. This module listens on the MQ for Designate related messages, and is able to launch actions depending on the message. In our case, it would be creating/deleting/etc. zones from our NSD servers.

The design has been made in such a way that a handler for every type of DNS server can be plugged to dnh as a plugin. For the moment, only the NSD4 handler has been written. Designate Notification Handler has not yet been included upstream, but discussion is on its way.

The source code is available on eNovance’s github: https://github.com/enovance/designate-notifications-handlers/

Discussing with Kiall and Patrick @ the Honk Kong Summit

I just got out of Designate presentation by Kiall and Patrick. After the talk, I got the chance to discuss with Kiall about the next steps for eNovance to continue participating in this project.

  • I will be working together with Kiall and Thomas Goirand (aka. zigo) on the Debian packaging in order to get Designate uploaded in the official Debian repositories.

  • From what I saw during the Q/A session, it seems that many actors might be interested in architectures involving ‘private master’ and many ‘any-back-end-based-slave’ for the public DNS requests. We are discussing the potential integration of dnh upstream.

Many features are in Designate’s roadmap, including dnssec, new pool manager service, integration with horizon, etc.

And of course, we hope to see the Designate project incubated soon. ;)

Cheers from Hong Kong.