nsupdate for soa / mx records

[Kevin Darcy]

The Dynamic Update RFC (2136) explicitly forbids the creation or deletion
of SOA records. This was purposely done to sabotage zone-creation and
-delegation through Dynamic Update. For what reason, I still haven't been
able to clearly ascertain...

MX records shouldn't be a problem, though. I use nsupdate occasionally to
update MX records. Are you absolutely sure that the MX record changes
aren't "taking"?

It should be safe to manipulate SOA records with named turned off. For
adding or deleting NS records (e.g. delegation NS records, when creating
or deleting a zone), it might not be so safe, because it might interfere
with the journalling mechanism. In BIND 9's nsupdate, you can specify what
zone to make the update in, so (finally!) it becomes possible to delegate
a subzone via Dynamic Update; the BIND 8 nsupdate didn't have any such
option, so it would try to add the delegation records to the child zone
(duh!).


- Kevin

Bryan Hodgson wrote:

> A new arrival to the list, folks.  If this one is in the archives, I
> didn't find it after a modestly thorough search.
>
> Compiled bind 9.1.1.rc5 on a Solaris 2.7 box, wanting to gain some
> experience with how DDNS actually works, in practice, and planning to
> (shortly) explore how (un-)well it works with w2k.
>
> Noted the various caveats about manually editing the zone files, and
> that's understandable ... but what would be the 'official' methodology
> to use to update/alter the SOA refresh / retry / expire / ttl values?
> Or to add / alter an MX record?
>
> I've successfully run nsupdate to do these tasks; successful in the
> sense that (with the debugger on) the return status was NOERROR ... but
> I cannot detect that the zone data actually changed (e.g. via dig -t
> axfr, for example.)  (Found it amusing that nsupdate swallowed "update
> delete my.zone.com IN SOA" without complaint.)
>
> Now I'm wondering if it's safe to manually edit zone-level RRs if named
> is turned off.
>
> Perfectly willing to follow pointers to documents discussing same.
>
> TIA.
>
> Bryan