Zone Creation via Dynamic DNS (Was - Re: add a zone with nsupdate ?

[Kevin Darcy]

Bill Larson wrote:

> I'm now slightly confused by dynamic DNS in light of your suggestion.
>
> According to RFC2136, dynamic DNS updates the information on the primary master DNS
> server, and this server is identified by the SOA MNAME field.  This presupposes that
> an SOA record for a zone already exists.
>
> If to create a sub-zone of an example.com zone, the following were run:
>
>     # nsupdate <<EOF
>     update add test.example.com $TTL SOA ns1.test.example.com.
> hostmaster.test.example.com. \
>         $SERIAL  $REFRESH $RETRY $EXPIRE $minTTL
>     update add test.example.com $TTL NS ns1.test.example.com.
>     update add ns1.test.example.com. $TTL A 1.2.3.4
>
>     EOF
>
> (excuse my folding the SOA record across multiple lines, I'm assuming that a long
> line would wrap), then the update would be directed to the primary server for the
> example.com zone as defined in the SOA record for this zone rather than the
> "ns1.test.example.com" host (which doesn't even exist because the zone doesn't
> exist)?  This would cause a second SOA record to be entered into the zone for the
> example.com zone, which I thought was illegal (a zone can only contain a single SOA
> RR - RFC1035, Section 5.2 - unless I am reading this too strictly or incorrectly).
>
> Also, according to RFC2136, Section 3.4.2.2, "if the TYPE is SOA and there is no Zone
> SOA RR ... the Update RR is ignored".  This would imply that you could NOT create a
> new SOA record using dynamic DNS.  It would be possible to modify RFC2136 such that
> dynamic DNS could create SOA records, but then the issue of which server should the
> new zone be created on would have to be addressed.

Sorry if I was unclear. SOA addition and/or deletion are _currently_ explicitly
forbidden by RFC 2136 (see Section 7.6). I was just explaining that the required minimum
quantity of resource-record information _could_ be provided in the Dynamic Update itself
so that a master server _could_ create a new zone if it were allowed to. As section 7.6
explains, the reason zone-creation and -deletion are forbidden is not because of a lack
of resource-record information, but because there's no standardized way in the protocol
to transmit "metadata" about the zone. My point is that the metadata doesn't belong in
the protocol anyway, it's implementation-specific.

> This idea is not necessarily a bad one, but it has to be completely thought through
> to insure compatibility with the RFCs and operation of name servers.  I would like to
> suggest that a better way to create new zones would be to use a mechanism that
> operates outside of the scope of the DNS protocols.  The current mechanism, direct
> editing of the configuration file, fits this requirement.  Another possibility would
> be use create a dummy zone which maintains a list of all zones that the server is
> configured for, and then a dynamic update of this zone could then trigger the
> creation of a new zone.  Although this makes use of the DNS protocols, it is still
> outside of the scope of the DNS protocols itself.  This idea has been regularly
> proposed as a solution for advertising a list of zones administered on a server.
> Still another possibility would be to use SNMP for managing the DNS configuration.
> This is implied in RFC1611, if the SNMP MIB values are both read and write.  Again, a
> mechanism outside the scope of the DNS protocol itself.

I agree that the "metadata" associated with a zone should still continue to exist
outside of the protocol (outside of the *DNS* protocol, at least). Whether it's pulled
in from a template, instantiated via SNMP, or whatever, the fact that it can't currently
be expressed in a standard way within the DNS protocol itself, IMO shouldn't stand in
the way of implementing automatic zone creation and deletion.

As for maintaining a list of zones, I think that solution is usually suggested to
address a slightly _different_, but related problem, i.e. how do slaves learn what zones
their master serves, so that they know what to slave? My proposal for *that* problem is
to allow NOTIFY messages to be signed. If a slave can trust a NOTIFY, then it can use
the receipt of one to auto-configure itself as a slave for the relevant zone.


- Kevin