DDNS updates for in-addr.arpa.

[Kevin Darcy]

Waltner, Steve wrote:

> Kevin, please send whatever information you feel you can share about your
> system. There was one other request for this info, so sharing it with the
> list would be a good idea. I would particularly like to see some HTML files
> that show the user interface for RR creation, editing, and deletion.

As I said, there are Intellectual Property concerns with sharing any of my
actual code. I can only describe things in fairly general terms. Plus, I'm
still working on improving it, so much of this is subject to change.

First of all, the system I have only currently allows the maintenance of A and
CNAME records (PTR's are generated automatically in response to the A-record
changes). In our environment, that covers the vast majority of our
administrators' needs. Anything else I do "manually" using nsupdate, or, in the
case of zone creation/deletion, by manually manipulating the zonefiles (since
in their infinite wisdom it's not possible to create or delete a zone via
Dynamic Update). I'll consider extending the web-interface system to other
kinds of record types as the need arises.

As far as HTML goes, I actually have 3 different user-interfaces. All of them
are pretty sparse, but the original (and simplest) interface consists of an
HTML form for A-record changes of just 4 text fields (old name, new name, old
address, new address) and a radio button for add/change/delete. The HTML form
for CNAME-changes is essentially identical, except the "old address" and "new
address" fields are relabeled as "old alias target" and "new alias target".
Each HTML form also has a hidden field indicating which version of the form
(A-record or CNAME) is being used.

So, from these forms, the CGI receives: a hidden-field value indicating A
record or CNAME, old and/or new name, old and/or new address and/or alias
target, and a radio-button value of add, change, or delete. Some combinations
are illegal, and an error is returned to the user. Also, malformed field values
(illegal characters in a name, badly-formed IP addresses, etc.) are rejected at
an early stage. Assuming that the input passes these initial checks (and the
ACL check, see below), the CGI then performs various lookups (making sure that
something which is to be added doesn't already exist, something to be deleted
does exist, and in the case of a change, that the old thing exists and the new
one doesn't; in the case of alias changes, it also checks whether or not the
alias target exists). Note that through the combination of fields submitted,
changes can be made on an RRset scope (add a name or alias, delete a name or
alias, change a name or alias) or on a specific RR scope (add an RR to an
existing RRset, delete an RR from an existing RRset, change an RR within an
existing RRset). For example, adding a new name is "add+A-record+(new
name)+(new address)" but adding an address to an existing name is
"add+A-record+(old name)+(new address)". The CGI can determine the scope of the
change by looking at what text fields were provided. For this reason, since
CNAMEs are strictly a one-to-one mapping, the "old alias target" text field is
never actually used -- it's just there to provide look-and-feel consistency
with the A-record HTML form. Some of the newer user-interfaces have no
"illegal" combinations of fields on their forms or "dead" fields. But they are
harder to explain.

The CGI performs validation by doing direct DNS lookups. Note that this
*requires* that the CGI talk directly to the master and *only* the master
server, otherwise propagation delays between masters and slaves or to a
non-authoritative server, could cause the validation to be performed
improperly. The CGI validates both forward and reverse records (in the case of
A-record changes) or alias targets (in the case of CNAME changes), and will,
for example, refuse to create an A record if the address reverse-resolves back
to some other name. The CGI also determines what PTR records to add or delete
in response to A-record changes. If the change fails validation, then feedback
is given to the user as to why, otherwise the change is performed via nsupdate
(the debug output of which is parsed in order to verify the success of the
Dynamic Update). Note that currently, the inability to add, change or delete a
PTR record in response to an A-record change -- because, for example, some
other machine is master for the zone containing the PTR -- is not considered a
fatal error. But I'm considering changing that. At least, the user should have
to *force* the change, so they don't get surprised later by the fact of a
missing or incorrect PTR.

Obviously, some of the work which is currently being done by separate
DNS queries (the old, pre-Dynamic DNS way that this maintenance system
worked) could in theory be performed more efficiently by using Dynamic Update
prerequisites. This is another area for future improvement.

Another aspect which I'll just briefly touch on is the whole
ACL (access-control list) subsystem which determines which user can perform
what changes on what record types, names and/or addresses and/or alias targets.
This is all based on regular expressions, which makes it quite flexible. I have
some users, for instance, who are only allowed to manipulate CNAMEs in a
particular domain. If I wanted to get really fancy, I could limit some users to
only change names which follow certain naming conventions. With the conversion
to Dynamic Update, I'm also adding another element to the ACL syntax: master.
In other words, a particular user may be permitted to change anything on a
particular master, but on some other master, may only be permitted to, say, add
PTR records. This is in expectation of "cross-maintenance" functionality where
a given CGI can update multiple master servers.


- Kevin