Skip to main content

DNS Cluster - Case where "Setup Reverse Trust Relationship" is not set

lorio
In one sentence: cpanel WHM should only write to cpanel DNSOnly without having reverse relationship activated. Example: cPanel WHM whm.domain.tld cPanel DNSonly dns.domain.tld First and second NS runs on whm.domain.tld Second NS runs on dns.domain.tld If "Setup Reverse Trust Relationship" is checked on the entry of dns.domain.tld IN the cluster section OF whm.domain.tld the cpanel access key of whm.domain.tld remains on dns.domain.tld. Correct? If whm.domain.tld should only write dns changes to dns.domain.tld and should not accept annything from dns.domain.tld a reverse trust is not needed. But Cpanel shows activation of reverse trust relationship when adding/changing an entry everytime. Even if the checkmark is not set. I find it a risk to put a root access key of cpanel on dnsonly if it is not needed. The wording might be is still confusing. The difference between Standalone and WriteOnly in terms of reverse trust relationship is what? Keep in mind that on the cpanelDNSOnly the cluster function is off. In the Onlineguide: [url=http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/ConfigureCluster#Use%20the%20primary%20nameserver%20as%20an]Guide to DNS Cluster Configuration [QUOTE]Select an option from the DNS role menu to specify the server's DNS role. The Standalone option is used for DNSONLY servers. The Synchronize changes option causes the web server to synchronize any changes you make on a server throughout the cluster. The Write-only option causes the web server to write DNS data to the nameserver
In WHM: [QUOTE] DNS Role Notes: Synchronize Changes: All changes made on this server will propagate to any server in the cluster that is linked to this server. Synchronization is one-way: changes made on another server will not propagate to this server unless Synchronize changes is selected on the other server as well. Standalone: No changes made on this server will propagate to any other servers. Write Only: This server will write changes to the remote server, but when this server loads zone files, it will not obtain zone data from the remote server.

Comments

5 comments

Date Votes
  • cPanelMichael
    Hello :) Per our documentation, here is a description of each role: Synchronize - This method synchronizes records between the local server and the remote server. Standalone - This method fetches DNS records from the remote server, but does not write records from the local server to the remote server. Write-only - This method pushes the local server's records to write to the remote server, but does not query records from the remote server to write to the local server. To clarify, the issue you are experiencing is that the remote access hash for the local machine is installed onto the remote system? Have you verified this is happening? Thank you.
    0
  • lorio
    [quote="cPanelMichael, post: 1620931">Hello :) Synchronize - This method synchronizes records between the local server and the remote server.
    Which sounds clear, but when we add the descriptions from the WHM: [QUOTE] Synchronize Changes: All changes made on this server will propagate to any server in the cluster that is linked to this server. Synchronization is one-way: changes made on another server will not propagate to this server unless Synchronize changes is selected on the other server as well.
    If Synchronize is not choosen on the other server, I would expect the behaviour to be the same as Write-only. I encourage the developers or documentation writer to do a graphical explanation with e.g. three servers (1 WHM and 2 DNSOnly). There are lot scenarios where the behaviour might be contra-intuitive to the wording of the settings. [QUOTE]To clarify, the issue you are experiencing is that the remote access hash for the local machine is installed onto the remote system? Have you verified this is happening?
    No, where is the default location for saving the remote keys? It might be a gui problem. Some time ago it was possible to create entries without username. Under 11.42 I am forced to enter root as a username. When unchecking "Setup Reverse Trust Relationship" and saving the entry the checkbox will be checked when opening the entry again. Thanks for your time.
    0
  • cPanelMichael
    [quote="lorio, post: 1621411">No, where is the default location for saving the remote keys?
    The access hash for the remote server is stored under the following directory: /var/cpanel/cluster/root/config/
    Thus, you should not see the source server's access hash on the destination server from the cluster unless you have selected and saved "Setup Reverse Trust Relationship". Thank you.
    0
  • lorio
    /var/cpanel/cluster/root/config/
    Thus, you should not see the source server's access hash on the destination server from the cluster unless you have selected and saved "Setup Reverse Trust Relationship".
    Thanks for the path. After regenerating keys, I only could find old cache files with the access hash keys. So it at least with the current 11.40/11.42 it is a gui issue only. Or I just get the wrong impression that when reopening the cluster entries the checkbox is always checked even though I always unchecked it before creating the entry in the first place.
    0
  • cPanelMichael
    Please open a bug report for the flaw with the UI so we can reproduce the issue and file an internal case: Submit A Bug Report Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post