[Pdns-users] Difficulty changing nameservers on domain registar's site

[Kenneth Marshall]

On Thu, Jul 02, 2009 at 09:15:03AM -0400, SashaB wrote:
> Hello all,
> 
> This is a long post with a lot of info since I thought you should know as
> much as possible about these NS before (a) having to ask the obvious
> questions and (b) so you can offer suggestions.
> 
> Here's the situation. I have set up the NS for our domains (on four servers)
> and nearly all resolving properly to the domains to which they point. (For
> those few that are not, I have figured out and corrected the issue; now
> we're waiting for the changes to propogate.)
> 
> However, we I have a specific domain registered via a registrar in the EU
> for one of our mail/webmail servers and, each time I try to change the NS
> (domain 'owners' can modify their own DNS on the registrar's site similar to
> (but far simpler than) GoDaddy's "Total DNS"), I get the following errors:
> 
> ns1.maildomain.eu  --->"The given nameservers return different SOA entries."
> ns2.maildomain.eu --->"Connection to server failed."
> 
> Before providing your help, you should know the following:
> 
> 1) The nameservers are shared by other NS, all of which have domain names
> associated for their specific purposes. (For example: ns1.foodomain.net,
> dns1.thisdomain.com, ns1.maildomain.eu, etc.). I've pointed all "ns1"
> domains to one IP address on each server and "ns2" are pointed to a
> different IP address on each server but share the same IP address on that
> server, etc.
> 2) The NS for this domain are on different servers in the same region and
> located in entirely different datacenters.
> 2) While there is a master record for the ccTLD itself on its resident
> server, I've also set up a separate master record for the NS1 so I can see
> updating serial numbers for just the NS. Because I also set up, as a
> supermaster, the hostname for the servers on which each of their NS has its
> master record, without creating each NS as a slave on the master server for
> that record, they each show on the other server as a slave and their serial
> numbers (and my logs, which I've set up to view by secure webserver) show
> they have been updating regularly.
> 3) Websites and other applications, some with the same NS IP (but different
> domain name), are resolving correctly.
> 3) All NS point to IP addresses, not CNAMEs or redirects. In fact, I tend to
> use IP addresses over hostnames because they resolve better if we make DNS
> changes to hostnames.
> 4) I 'played around' with the NS to learn how pdns works and determine how
> best to set them up, especially for security and convenience. In that
> process, I found it was just easier to point the NS for all of our domains
> to the same IPs on each server and use other IPs for other purposes (like
> pointing a domain's webservers to). So, I changed the IP addresses for the
> NS, deleted and recreated NS records, updated SOA records, etc. That may
> affect the SOA entries.
> 5) The NS have been live for at least 24 hours each.
> 6) The NS point to different IPs from the domain's other records, like the
> MX and webmail server, which have their own IP addresses. I've configured my
> virtual hosts in apache accordinly (except I did not create any for the NS.)
> 7) The SOA record of NS record on each server points to the appropriate IP
> address and is configured, "ns1.maildomain.eu
> hostmaster.masterrecordserver.com". Since each is on different servers, the
> "hostmaster" domain name is for that server, not the master server (ns1) of
> the domain itself.
> 8) I've given the registrar's IP address access to my server (via
> hosts/csf.allow and the firewall) and added its network address to the
> 'axfr' setting in pdns.conf. The pdns-recursor is not active on one server
> (configuration issues) but is on the other. On the server with pdns-recursor
> running, each master record has a corresponding "in-address.arpa" entry. I'm
> still working on that for the other server. Neither server, however, is
> experiencing resolution issues with the domains not associated with these in
> question.
> 
> So, that all said, I have a few questions that might be a source of some
> issues:
> 
> 1) I've taken the extra step of creating an "A" record for each NS in the
> domain's DNS settings on the registrar's site as well as updating the other
> records for the domain in the registrar's DNS as well, thinking that may
> help. Will that affect the SOA records?
> 2) Do the changes I've made to the master records, i.e., changing the IP
> address of the NS several times before deciding on a final configuration,
> cause such problems? (The NS for my websites, which have totally different
> NS, in part, so we don't have these issues with them, have been 'cast in
> stone' for several weeks and haven't changed so they're resolving
> correctly.)
> 3) My understanding is that mysql acts as recursor when pdns-recursor. How
> can I tell if the records in mysql are correct? (I've looked at the records
> via Webmin but they don't contain full record entries or have IP numbers
> associated, so I can't tell how accurate they are.)
> 4) How does pdns-recursor and rDNS configuration affect resolution? Could
> that be part of the issue?
> 
> Finally, I've done searches online and found that others have this issue
> with EU-based registrars. Ostensibly, this is to prevent NS
> misconfiguration. But, I'm finding pdns is pretty good at that so I'm not
> understanding the problem. But, since I have three more domains with this
> registrar, I've got to so I can fix it. Please provide your
> solutions-oriented assistance in trying to ressolve this issue so we can use
> our own NS for our mail/webmail servers.
> 
> If you've read this far, thank you and I look forward to your help.
> 
> Sasha

Hi Sasha,

Thank you for the detailed description, but I think that the problem
is described correctly by the error message you received from your
domain registrar:

    your nameservers have different SOA records (paraphrasing)

All nameservers for a domain, by definition should have and serve
identical content. I think that once you fix this inconsistancy it
will all work.

Regards,
Ken