Storing Configuration Information in DNS

This idea may seem odd, but DNS is nothing but a configuration information -a tree of servers that provide the hostname to IP address mapping for the planet's machines. DNS can also provide SMTP mail delivery information for domains, SPF email verification metadata and other entries.

There is no requirement to stop there. DNS can be used to provide standard hostnames for standard services, so that applications expecting to find a web proxy look for the standard port in the host 'proxy'; applications looking for a mail server look up the host 'mail'/

Features

• DNS entries point to different services. Such as mail, database, ntp, proxy. For an intranet, (or home) these machines would be visible to all. For a server farm, the entire farm would need to be placed into a private subdomain, so that the services' hostnames do not clash with other services.
• Statically configured DNS entries can be set up by the operations team.
• Dynamically configured DNS entries can be created as machines/services deploy.
• Commercial Dynamic DNS services (such as dyndns.org) offer internet address management for private subnets.
• Multicast DNS, as popularised by Apple, let dynamically deployed services be discovered through DNS requests multicast over the local subnet. Separate network subdomains are used to register different application protocols; by enumerating all hosts in a specific protocol subnet, all implementations of a specific service can be located.

Advantages

• Makes every URL and hostname a configuration point for an application.
• Provides service discovery to REST services and web browsers
• Adding a new DNS entry in a DNS table is very cheap.
• Easy to test by hand, just learn to use nslookup
• Caching makes for fault tolerance.
• Dynamic DNS Enables dynamically deployed hosts to be located, even if their IP address is not known in advance.
• Good for laptops.

Having custom hostnames for different services is an easy way to provide some late binding information to any application.

Disadvantages

• mDNS does not scale well to a large flat network full of active hosts, such as the WiFi network on an apple conference.
• DNS security has always been a bit weak, but it is improving.
• Java programs cache DNS responses for their duration, unless told otherwise in a system property set on the command line. Java applets do not have the option of disabling permanent DNS entry caching for security reasons.
• If hosts are dynamically deployed, the IP address of a terminated host must not be reused until after the expiry time of its DNS entry has been reached. Otherwise clients may connect to the new application that is deployed at that IP Address.
• Java security prevents applets talking to more hosts than the one it was deployed on. An applet can therefore not talk to billing.example.org and security.example.org, even if both hostnames map to the same IP address -the one on which they were deployed.
• People are not so good at remembering many hostnames.
• Requires separate subdomains for each set of servers.

SmartFrog support

1. The [sf-dns] component can create BIND configuration files when deployed, so a classic 'static' DNS server can be setup.
2. The LivenessPage component in the sf-www package can be used to register an entry under a dyndns.org account; simply construct the URL to register a hostname (including login details), and declare that this web page should be deployed on startup. When the component is deployed, the host entry is registered. Do note the DynDNS rules about how often a service should be registered, and try not to abuse their service. There are preconfigured DynDNS components that can do the lookup and registration of a host.