• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

How to Enable AXFR Transfers to BuddyDNS

SiddeswaraK

New Pleskian
I am planning to use BuddyDNS to server as a Secondary DNS to my Plesk Panel 11.5 powered Server. BuddyDNS provides instructions to enable the AXFR Transfers. But, since it is more linux oriented, I am unable to understand it. Would anyone be kind enough to explain how I can set this up? BuddyDNS instructions involve editing the named.conf file at ain configuration file /etc/bind/named.conf. But, I do not find this file in that path. Does Plesk put this file in a different location? Can I just enable AXFR transfers to a secondary DNS service (such as BuddyDNS) from within the Plesk Panel? Any help is highly appreciated. Thanks in advance.
 
You don't need to edit any files. In fact, as a rule of thumb, manual edits for anything to do with DNS are best avoided, as Plesk is designed to do everything for you.

All you need to do is go to Tools & Settings, click on DNS Zone Template and take a look for the Transfer Restriction Template. Add the IP for your "ns2" (basically your buddydns secondary IP) and you should be good to go.

Note that named.conf is in /etc/named.conf (actually it is a symlink to /var/named/chroot/etc/named.conf). After you have made the change in Plesk, take a look at the file and see if what the buddydns instructions said are now automatically in place.

If not, editing the top bit (I.e. the non-domain-specific) part of named.conf is usually OK, but like I say, Plesk takes care of things normally, and if you make a change to a section where Plesk makes adjustments, any changes you make manually may be lost at a later point.

EDIT: The path I gave for named.conf is for Centos 6. It may be different in other flavours of Linux. Use the command "locate named.conf" at the command line to find it if need be.
 
Thank you, Faris.. I was able to get it to work with your first suggestion from the Transfer Restriction Template. Thanks a lot! :)
 
Thank you very much for the info. Just a question, is it possible to test if the transfer is working ok?

I've checked with several web tools (whatsmydns.net, centralops.net, ...) and they only shows the primary DNS server, I guess because it is not listed in a NS record

Besides I'm not clear why dig command answers "Transfer failed"

Thanks in advance


$ whois mysite.com
...
Name Server: NS.MYSITE.COM
Name Server: SLV2.1AND1.ES

named.conf
...
acl common-allow-transfer {
212.227.123.29;
};


$ dig axfr mysite.com @slv2.1and1.es

; <<>> DiG 9.8.2rc1 <<>> axfr mysite.com @slv2.1and1.es
;; global options: +cmd
; Transfer failed.
 
Unless I'm misunderstanding, both nameservers *should* be listed in an NS record for your domains.

It is actually the NS records that tell bind where to send notifications when a record is updated. (Indeed there's an annoying bug that makes bind send notifications to itself in some cases).

With no NS record for for secondary namserver, bind won't know where to send notifications to.

Of course the secondary will still pick up changes when the expire time runs out.

Regarding the test you did, I'm not sure it would work anyway. The acl will only allow a transfer from the 212 IP so the dig test won't work I don't think. The way to check is to look at /var/log/messages to see what error was produced by names when you ran that command. In addition, you can do an update to a DNS record, or you can restart named, and see what details appear in the log. Failures are usually quite clearly shown in the log, but ideally you need to look at the logs on both sides, which isn't possible in this case.
 
Not sure, maybe I didn't saved changes in the DNS zone because the NS record for the secondary server was missing. I added it and checked at /var/log/messages and it seems is working right:

Apr 26 18:26:46 s62591307 named[4731]: received SIGHUP signal to reload zones
Apr 26 18:26:46 s62591307 named[4731]: loading configuration from '/etc/named.conf'
Apr 26 18:26:46 s62591307 named[4731]: using default UDP/IPv4 port range: [1024, 65535]
Apr 26 18:26:46 s62591307 named[4731]: using default UDP/IPv6 port range: [1024, 65535]
Apr 26 18:26:46 s62591307 named[4731]: sizing zone task pool based on 5 zones
Apr 26 18:26:46 s62591307 named[4731]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
Apr 26 18:26:46 s62591307 named[4731]: reloading configuration succeeded
Apr 26 18:26:46 s62591307 named[4731]: reloading zones succeeded
Apr 26 18:26:46 s62591307 named[4731]: zone 214.106.87.in-addr.arpa/IN: loaded serial 1398529606
Apr 26 18:26:46 s62591307 named[4731]: zone mysite.com/IN: loaded serial 2014042602
Apr 26 18:26:46 s62591307 named[4731]: zone mysite.com/IN: sending notifies (serial 2014042602)
Apr 26 18:26:46 s62591307 named[4731]: client 212.227.123.29#55840: transfer of 'mysite.com/IN': AXFR started
Apr 26 18:26:46 s62591307 named[4731]: client 212.227.123.29#55840: transfer of 'mysite.com/IN': AXFR ended

Thanks for your help
 
Back
Top