0

In my current role as Devops I have been assigned a few tasks that are new to me including setting up a PDNS server with MySQL backend. After initial setup of the server I tested responses from the new PDNS server with DIG and NSLOOKUP while specifying the ip of my server. All responses came back positively as I was hoping they would.

After initial setup I waited for some time to allow the records time to be updated on other non-authoritative name servers. Unfortunately the records do not appear to be noticed by other name servers out there. Every attempt to do a normal NSLOOKUP or DIG on any of my domains resulted in a SERVFAIL from non-authoritative name servers.

I apologize for my ignorance of the DNS system. I have been doing some research and have tried multiple times to change some settings to get things to work properly, but unfortunately all changes I have made have been unsuccessful.

I am hoping that someone can help me understand a little more about how a non-authoritative name server gets record information from an authoritative name server. I think I understand properly how a domain name is found from the TLD down to the individual server, but I am not sure why my name servers are not being found. They appear to be responding properly when queried directly.

I am running:

CentOS pdns 3.3.1 pdns-backend-mysql

I have my SOA record set to point to my primary name server:

SOA Record Example

commissionconverter.com origin = ns3.myebiz.com mail addr = hostmaster.myebiz.com serial = 2014030401 refresh = 28800 retry = 7200 expire = 604800 minimum = 86400

thank you for your help.

jander924
  • 1
  • 1
  • 1

1 Answers1

1

The delegation seems to be in place and your nameservers appear to be responding.

However, your nameservers would appear to deny the existance of any NS records for the zone, something which is definitely not a good thing. (Whether or not it fully explains the problem is unclear to me as the problem description itself is somewhat vague.)

I would suggest dig +trace +all commissionconverter.com NS to see more or less the steps that a resolver server would go through to look up a name (start querying for the specified name at the root, follow delegations, repeating that process until done).

As you can see the result of the very last query, the one directed to oen of your servers, the server does not respond with the expected NS records.

It's possible that there are further problems to be found in your case but this at least covers some of the fundamentals and points out one problem.