moving DNSSEC to a hidden master

[David Newman]

On 10/4/13 10:23 AM, David Newman wrote:
> On 10/3/13 5:27 PM, Sten Carlsen wrote:
>> This works for me and is the standard method:
>>
>> rndc freeze
>> update serial
>> rndc thaw
> 
> Bingo. Thanks!

Sorry, spoke too soon. I followed your instructions and Mark's but I'm
not seeing the zone file serial number increment on the new machine,
even after making other edits to the zone file.

Here are the steps I'm following. Both old and new nameservers run bind
9.9.4.

1. "copy the .key and .private files over" - did this with rsync -prv
and verified ownerships and permissions are unchanged

2. "Disable updating on the old master" - did this with 'rndc freeze'

3. "Transfer the zone contents by setting up as a slave using
"masterfile-format text"; or using by using dig."

- did this with 'dig axfr zone +multi +onesoa @oldmaster > zonefile',
then edited zone file to remove top and bottom lines from dig, then
changed file ownership to the named owner.

Then I edited named.conf to make the new nameserver master for this zone.

Then I ran 'rndc reload' on the new nameserver. A 'dig soa' query
returns the same serial as on the old master.

4. "Check that the new server is working and you can update
the zone by using nsupdate."

This is where things fall apart. I run 'rndc freeze' and increment the
zone file's serial number (or make any other change), and then run 'rndc
thaw' and 'rndc reload'.

There's no change in serial number, and there's no error reported in the
logs.

What am I missing?

Thanks!

dn

> 
> dn
> 
>>
>> Rndc freeze merges the .jnl files into the zone files and stops dynamic
>> updates. Thaw allows dynamic updates to resume.
>>
>> On 04/10/13 02.12, David Newman wrote:
>>> Thanks all for your responses.
>>>
>>> On 10/1/13 6:42 PM, Mark Andrews wrote:
>>>> As Alan said copy the .key and .private files over.
>>>>
>>>> Disable updating on the old master.
>>>>
>>>> Transfer the zone contents by setting up as a slave
>>>> using "masterfile-format text"; or using by using dig.
>>>> This will give you the most up to date version of the
>>>> zone.
>>>>
>>>> 	dig axfr zone +onesoa @oldmaster
>>>>
>>>> Check that the new server is working 
>>> Converting the new secondary to a new master worked. But incrementing
>>> the zone's serial number did not, producing an error after 'rndc reload'
>>> like this:
>>>
>>> Oct  3 16:00:29 host named[35249]: malformed transaction:
>>> dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 !=
>>> transaction first serial 2013092700
>>>
>>>> and you can update
>>>> the zone by using nsupdate.
>>> Although the zone file lives under dynamic/mydomain.com so DNSSEC
>>> updates can happen, I don't have dynamic updates configured, so nsupdate
>>> won't work. This arrangement -- with static zone files under the dynamic
>>> directory -- worked OK on the old master. Permissions are the same on both.
>>>
>>> This thread suggested the journal issue was separate views pointing to
>>> the same zone file:
>>>
>>> https://lists.isc.org/pipermail/bind-users/2008-June/070807.html
>>>
>>> Indeed I had pointers to the same zone file in separate views, but
>>> removing them and restarting named did not clear the issue. Now I have
>>> the zone in just one view, and still can't manually increment the serial
>>> number without that journal complaint.
>>>
>>> Thanks in advance for clues on resolving the journal version issue.
>>>
>>> dn
>>>
>>>> Convert the old master server into a slave.
>>>>
>>>> Update the other slaves to talk to a new master.
>>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>> -- 
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>>
>>        "MALE BOVINE MANURE!!!" 
>>
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>