Skip to content

Latest commit

 

History

History
102 lines (59 loc) · 4.84 KB

README.md

File metadata and controls

102 lines (59 loc) · 4.84 KB
Raw

DNS As A Service

Build Status

Overview

the DNS charm is unique in that it wraps several other services to provide a common gateway to automatically provisioning your DNS configuration. Regardless if you are setting up a BIND cluster, PowerDNS, or integrating with a third party provider (such as Amazon Rt53, or GoDaddy for example).

This charm provides DNS. By default the charm will deploy a configured Bind9 server, assuming it is the authoritative master of the configured domain(s).

Notes about architecture

The DNS charm implements an abstracted 'provider' concept, to ease integration of new services. Specific instructions how to extend/ add providers is outlined in docs/HACKING.md

Usage

juju deploy dns
juju set dns domain='superawesome.com'
juju add-relation myservice:programmable dns:programmable

Offline Environment Usage

juju set dns offline=true

You will need to branch the charm locally, and fill the required dependencies. Each dependency should be listed by the provider(s) specific documentation in docs/provider.md.

An example Heirarchy:

files
├── bind
│   ├── bind9_1%3a9.8.1.dfsg.P1-4ubuntu0.8_amd64.deb
│   ├── bind9utils_1%3a9.8.1.dfsg.P1-4ubuntu0.8_amd64.deb
│   └── pip
│       └── tldextract-1.3.1.tar.gz
└── core
    ├── python-pip_1.0-1build1_all.deb
    └── python-setuptools_0.6.24-1ubuntu1_all.deb

core is used to install the baseline dependencies for the bind service provider. This is agnostic to any specific provider, and required for the DNS charm itself to operate.

bind Specific to the bind provider, and exposes a sub-directory of pip for python modules consumed to make the bind provider function. The order of operation: the bind .deb files will be installed before the pip directory.

Charm Integration

To integrate with the DNS charm, there is a specific format to send data over the wire. There are Three interfaces that are possible, as documented below

autogenerated

Not implemented

programmable

An easy integration. Geared towards A, and CNAME records. But any record that conforms to this format will be acceptable.

Set your associated record resource configuration variables, and expect to receive a public-address value from the dns relation.

  • domain optional - If using a domain other than what the configured domain on the DNS server, this will create a new zone file, and append the record.
  • alias - sub portion of the domain. for example, given redis.example.com - redis is the alias.
  • addr - Assigned as the public/private address from your host.
  • rr - Record Resource type. Possible values: A, CNAME, AAAA, NS

programmable-multiple

A higly configurable interface to pass single/multiple records to the DNS host. This will expect a json list of records to add that conform to the named-checkzone output. Sent over the wire as resources

[{'alias': 'test', 'ttl': 1600, 'rr': 'A', 'addr': '127.0.0.1'}, {'alias': 'test2', 'ttl': 1600, 'rr': 'CNAME', 'addr': '127.0.0.1'}]

Note: this will be moving to a JSON datastructure in the near future. Parsing an array of strings when integrating with providers other than bind is not trivial, and the itnerfaces should expect consistent data. The Array notation will only be supported by the bind provider until the 1.0 release, when backword compatability is broken.

Known Limitations and Issues

The charm in it's current form does not support scale out operations. It's engineered towards a single Bind9 Authoritative master deployment for use in offline environments.

None of the 3rd party provider support has been added save for the provider architecture outlined in docs/HACKING.md

Configuration

domain: Used to configure the base domain provided by the DNS charm. Defaults to 'example.com'. This is used implicitly in the autogenerated relationship. eg: if you deploy redis, and relate it to the dns charm with the autogen relationship - it returns: redis0.example.com as the configured DNS.

offline: Predicate configuration option for determining if packages found in files/ are to be used for installation in an offline environment.

provider: Specify the underlying provider. Defaults to bind

proivider_keys: Used to warehouse provider specific configuration. For an example usecase, see the rt53 docs.

Contact Information

Dont forget to check the docs directory for additional resources!