nsupdate for soa / mx records

[Bryan Hodgson]

> 
> 
> 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...
>

OK.

> 
> 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"?
> 

Well ... it appears that I mis-spoke.  Although I wasn't getting answers
returned from dig, when I shut down named the MX records had been written
to the zone file.  So I'm going to go back and get that one again.

It does seem impossible to add "	IN MX 99 name" to handle the zone
as a whole, but I suspect that problem is nsupdate's parsing mechanism.

>
> 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!).
> 

OK, I'll keep an eye on that one.  Thanks!