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.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • While digging into the added options for the DIG command as you suggested and noticed that in the ** ;; ADDITONAL SECTION:** it looks like the A record information for our name servers ns3.myebiz.com and ns4.myebiz.com is pointing to our previous location, but their records have been updated to point to the new PDNS server. Thank you for your help. – jander924 Feb 23 '15 at 18:47
  • Is there a way to update the **ADDITIONAL SECTION:** information? I am assuming it is cached since the IP's for NS3 & NS4.myebiz.com have not been pointing to the IP's that are being returned for some time. – jander924 Feb 23 '15 at 19:20
  • @jander924 Are you talking about the glue records in the parent zone (those are returned in the ADDITIONAL section)? If so, you will have to update these through the registrar for the domain which these glue records belong to. – Håkan Lindqvist Feb 23 '15 at 19:23
  • It is the part of the dig response that shows who the authority is for the NS record of commissionconverter.com. which in this case indicates that ns3.myebiz.com and ns4.myebiz.com, but in the additional section where it indicates the IP's for ns3 and ns4 it is using old IP's that have been changed for around 6 months. If I dig on ns3.myebiz.com and ns4.myebiz.com I am getting the new IP's. I apologize again for my ignorance, but is the glue record different than just updating the A records for ns3/ns4.myebiz.com? Thank you for all your help. – jander924 Feb 23 '15 at 20:39
  • @jander924 The difference is that glue records are not in the `myebiz.com` zone itself in your example, but in the parent zone to complement the `NS` records referring to these names (to avoid what would otherwise be a circular dependency). In the case of `myebiz.com` there are currently no `NS` records referring to `ns3.myebiz.com` or `ns4.myebiz.com` so it's probably a mistake that these records even exist (I would imagine that such records did exist at some point, though). – Håkan Lindqvist Feb 23 '15 at 20:56
  • You were exactly right about the glue records. Thank you for your assistance. I was able to change those glue records at the registrar level. while researching glue records based on what you mentioned I also came across another question on Servfault that helped as well: [what-is-a-glue-record](http://serverfault.com/questions/309622/what-is-a-glue-record) – jander924 Feb 25 '15 at 18:46