Possible Bug - Multi Server Setup - Issuing named rewrite does not transfer modified DNS Records

Meiji

Verified User
Joined
Jul 2, 2019
Messages
72
I was testing multi-server setup.

Installed DirectAdmin on two VPSes, and added VPS1 in VPS2 > Multi Server Setup.

VPS2 already had a domain with one custom DMARC record. When the zone was transferred to VPS1, The default DMARC record was sent to VPS1, not the custom record after issuing the command:

Code:
echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue

The DMARC record on VPS2 was also reset to the default DNS record.

@smtalk I know you are busy with the next DA update, which does have some impressive feature updates, it would be nice if you could have a look.
 
Let me rephrase this.

Is it possible to transfer the DNS zones from the Web Server to the Master DNS Server without changing and DNS records on the Web Server or issuing a named rewrite on the Web Server?
 
My understanding is that it's a "rewrite" as in, revert your zones back to default.

The Multi Server Set up should transfer your zones from server 1 to server 2 automatically.

Does this not happen for you without issuing the rewrite command manually? If not, check and test the connection, firewalls, etc.
 
First this may help https://help.directadmin.com/item.php?id=97

the 2 serves are they both da servers? If yes they are both web servers and primary DNS servers by default. Unless you customized the config.

Each server is master of its own records. As far a as I know you can’t edit server a records from server b or the other way b to a

There are some checks in the Multiserver setup area. Which I think are talked about in the doc.

yes if setup correctly a to B and B to a they can copy. So both server have All records.

if it’s not happening check the password with test connection. If it fails put in the password save it and test again. You would need to do this on both a and b.
 
My understanding is that it's a "rewrite" as in, revert your zones back to default.

That is what I am thinking too. It also transfers the zones at the time of the rewrite.

The Multi Server Set up should transfer your zones from server 1 to server 2 automatically.

Does it transfer existing zones, too (zones added before enabling MSS)? If so, how much time it takes?

It didn't appear to me that it automatically sends existing zones.


First this may help https://help.directadmin.com/item.php?id=97

the 2 serves are they both da servers? If yes they are both web servers and primary DNS servers by default. Unless you customized the config.

I was transferring existing zones, as the above guide instructs:

If you need to transfer all of your zones from your current machine to the servers listed in your multi-server IP list, then you can type:

echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue

New zones got transferred automatically without any issues.

if it’s not happening check the password with test connection.


The test connection is alright. Besides, the server transferred all zones after issuing the above command, so the connection is functional.
 
Ok so you should be good then. If you edit a record on server a then look at server b is it updated?
 
Ok so you should be good then. If you edit a record on server a then look at server b is it updated?

It is not realistic to manually edit all the zones on a server. Perhaps okay for one or two or even ten at best. I haven't tried it.
 
This seems to be a DirectAdmin issue. Anyone from DirectAdmin Support?
 
Last edited:
I still could not do this.

I did not find any documentation on how to transfer existing zones to the slave DNS server.
 
I did not find any documentation on how to transfer existing zones to the slave DNS server.
??? What do you mean? You stated that in your first message
Code:
echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue
This is the command to be used, it's stated in the helpfile that this is what it does. And it does. So it is documented.
Seems you're having some trouble with it, I don't know why yet.

I never had issues with it, and it copy's dnssec and dmarc records also.
I'm only not sure if you need to have dmarc and dnssec enabled on the slave server too.
On my server I also have some custom dmarc stuff.[/code]
 
This is the command to be used, it's stated in the helpfile that this is what it does. And it does. So it is documented.
Seems you're having some trouble with it, I don't know why yet.

The task queue rewrites DNS records. That means, if I have modified a DNS record, it resets it to the server's default value.

I want the existing record to be pushed to the slave server, without resetting it to the default value.

I never had issues with it, and it copy's dnssec and dmarc records also.

Can you confirm, it does not reset custom DNS records for you?


I'm only not sure if you need to have dmarc and dnssec enabled on the slave server too.

It is not required on the slave server. I have not tried with dmarc and skim, but I have tried with DNSSEC and it works.
 
My understanding is that it's a "rewrite" as in, revert your zones back to default.
No, it Reads the current published zone file/s on said server and rewrites them as it is currently written. Like you were copying and pasting the same text over the same document.
It also transfers the zones at the time of the rewrite.
Yes, it Read and writes the exact file which transfers the records to the other servers setup in the Source server in the Multiserver area.
It didn't appear to me that it automatically sends existing zones.
If it's in the current zone it sends it. If it's not in there it cant send it.

Ok here is the feature https://www.directadmin.com/features.php?id=405

"rewrite all DNS files with the named.db file. (The dns_*.conf files are not used because they are just for new zones.)"

So if it's in the current zone file it goes. Lock stock and barrel.

I have run this on 2 separate servers.

One with multiple custom added entries. No issue all entries are still there in both servers.

Now it is important to run it on the correct server.
If you need to transfer all of your zones from your current machine (the one you want to send the records from) to the servers listed in your multi-server IP list (the other server that is out of sync) which will rewrite all local zone, thus triggering the transfer of them to the remote servers.

Source server with all good and custom record (run command on this server). >>> to send to other servers in Multi-server list AKA (Target servers without all the records in the source server.

One server I went and changed on record and saved. Ran it did not set it to default it sent the exact record.

The only thing you keep saying that is scaring me is
the slave DNS server
if all the servers in question are all DA servers NONE of them are Slaves they are all Masters. So unless you have some NON DA servers you are trying to send records to the Multiserver approach will work. There is no Native Slave functionality in DA.

Now what will reset the zone to default is in the GUI the big red button RESET DEFAULTS. Don't use that unless you want the zone to reset to your standard settings.
 
Last edited:
Can you confirm, it does not reset custom DNS records for you?
Yes I can confirm this.
At first it did not copy over the dnssec .db.signed over either until I enabled dnssec on the other server too I thought.
You say you don't need it and it works without, then I believe you. I don't quite remember exactly which issue I had in the beginning transferring the dnssec .db.signed records.

Anyway, the task queue does not reset records to the default. However, it should be executed from the server which is main server and has the custom records. The rewrite only takes care of the fact that the current records on the server where the command is executed are reloaded (maybe also soa record update) so it will also send it to the slave server.
This is the reason it should not be executed on the slave server if you only use it as master/slave.

Be aware of timing issues. If I'm correct, the synching is done via the task queue. This means it can take up to a minute before the command even starts and transfers begin.
You should be able to see this in the system log and also the domains which are reloaded.

I think the explanation of Brent can also help you further.
 
@Richard G thank you for your confirmation.

I finally tested it again, and what you said is correct. I tested with modified A and DMARC records, it synchronized but didn't reset the records back to default.

I no longer have the setup when I originally tested, and it reset the record back to default. Maybe I did something wrong then.
 
You're welcome.
I'm glad to see you managed to get it working like it should. Maybe you did something wrong, maybe there was a hickup somewhere.
Important part is that it's fixed. ;)
 
Back
Top