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

[Bill Larson]

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.

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.

Bill Larson

Kevin Darcy wrote:

> If you're adding an SOA RR and one or more NS RRs via Dynamic Update, then the
> server has all of the resource-record information it needs to create a zone.

[Kevin Darcy]

Bill Larson wrote:

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