dns 4.0 spec

Overview Four parts contribute to this feature:

Completion of the existing pull-based DNS by adding DnsResolver plugins for the remaining record types.
Revise the configuration scheme for the properties which govern the behaviour of the DNS server.
Address limitations of the current implementation which have been reported from the field.
Define the standard practice for deploying DNS and connecting it to the environment.
Develop push-based DNS for zone records which are amenable to this data model.
Work towards support for Route53

Context & Background Background information about the state of the pull-based DNS implementation can be found indns-3.4-spec.

Related to both implementation and test planning is the list of bugs against the current DNS.

Ultimately, push-based DNS is both in demand today and required for implementation of Route53. Work in that direction is subsequent to, but not directly dependent on, acceptance of the pull-based implementation.

Dependencies & Assumptions The primary assumption here is two fold:

The system must service DNS requests directly for records which are based only on in-memory state. This implies continued operation of the libdnsjava based server.
The system must integrate with DNS at large in deployments. Delegation is the first step to formalizing support for this. Subsequently, the work towards push-based DNS will enabled more integration alternatives.

Requirements User Stories (Functional)

Architectural Priorities & Constraints (Non-functional)

Availability & Robustness

The DNS server is essential to identifying ENABLED services in the system– there is not other viable alternative today. To that end, it must be able to:

run in an active-active configuration
be start/stop/restart-able to support maintenance

Specification 1. Update bucket and ELB DNS.

Fix/Centralize configuration of DNS.

-- Instance subdomain configured at CLC, must send to CC, used as

'searcdomain' in resolv.conf

-- Internal Eucalyptus instance DNS must send to CC and needs to be

first 'nameserver' in resolv.conf (used for, instance-data, split

horizon, etc resolvers)

-- Additional DNS servers need to be @Configurable: move from being

configured on CC in eucalyptus.conf. Should have a global default and

also cluster specific configuration. Must send to CC for use as

additional 'nameserver' entries in resolv.conf

-- Add @Configurable for the nameserver that Eucalytpus should use

when doing recursive resolution; done through

http://www.xbill.org/dnsjava/doc/org/xbill/DNS/ResolverConfig.html

-- Standardize per-service DNS subdomains and their configuration,

too. e.g., the way instance, ELB, bucket DNS subdomains are set.

Fixes to DNS server implementation (e.g. see attachment with comments there)
Define standard configuration for (e.g.) bind to do DNS zone delegation
IMPORTANT: Test plan for DNS functionality:

-- bind delegation setup

-- service-specific DNS (ELB, S3, EC2)

-- split-horizon DNS

-- system-service DNS

-- various system deployment topologies (co-located CLC/CC, all

remote, multi-cluster, etc)

-- also test w/o bind delegation setup?

Identify methodology for pushing DNS data to external servers

(e.g., using AXFR, nsupdate, denominator, similar)

As time/need allows add support for pushed to external DNS
Do Route53 service with above pieces

Detailed Specification Code Model Source Repository Included with eucalyptus.

Module Organization There are three parts to the

Technology Selection Software The solution is currently based on libdnsjava. In this release that may be extended to include an additional external DNS server: bind.

Services Should bind be added the expectation would be that the system administrator is responsible for the service liveliness of bind.

Security Protocols Communication Protocols DNS for queries and zone transfers over both UDP and TCP.

Deployment Topologies The internal DNS server must run on all front end hosts. The DNS server itself is active-active already. Its service lifecycle relationship will need to be updated to run on the appropriate hosts.

Operation & Administration Internal Server External Server (bind) Configuration

Testing & Evaluation Test planning for DNS functionality should address:

-- bind delegation setup

-- service-specific DNS (ELB, S3, EC2)

-- split-horizon DNS

-- system-service DNS

-- various system deployment topologies (co-located CLC/CC, allremote, multi-cluster, etc)

-- also test w/o bind delegation setup?

Packaging & Delivery

Appendix JIRA Survey [1] https://eucalyptus.atlassian.net/browse/EUCA-6079