HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials - Setting up DNS server to resolve itself with root servers, registrars etc

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)

- General (http://www.howtoforge.com/forums/forumdisplay.php?f=21)

- - Setting up DNS server to resolve itself with root servers, registrars etc (http://www.howtoforge.com/forums/showthread.php?t=12697)

Setting up DNS server to resolve itself with root servers, registrars etc

I get this report from dnsreport when run against a domain setup in a mydns server.

Quote:

WARNING: Your nameservers do not include any corresponding A records when asked for your NS records. They probably are not returning the A records when asked, which can prevent some other DNS servers from contacting your DNS servers. They should do this if they are authoritative for those A records (in BIND, you should not use 'minimal-responses yes;'). The problem record(s) are:

Nameserver x.x.x.x did not provide any IPs
Nameserver y.y.y.y did not provide any IPs

From what I can see it appears that dnsreport expects the nameserver to return an A record for itself, although the domain name used by the nameserver itself is hosted at dreamhost.

Does that mean that I have to delegate the subdomains ns1.domain.com and ns2.domain.com from dreamhost to my own name servers and have them answer for themselves?

I had a problem before when I tried to change the name server for a domain to the domain itself i.e at the registrar set ns1.domain.com and ns2.domain.com as the DNS servers for domain.com. I don't know whether it was the result of some old fashioned DNS setup as it was some years ago.

The other alternative I can think of is to setup the servers, enter all the values currently stored at dreamhost and switch over the DNS at the registrar. I am not quite sure how that will work as it appears to be some kind of recursive chicken and egg situation. A lot of registrars seem to prefer domain names rather than IP addresses when setting up name servers.

I have a feeling it requires some unusual request at the registrar but I am not quite sure what it entails.

It appears to share some similarity with this thread - http://www.howtoforge.com/forums/showthread.php?t=7508

On the other hand it could just be simply a matter of making the right entries in mydnsconfig. Has anyone experienced this before?

Quote:

Originally Posted by voipfc

Does that mean that I have to delegate the subdomains ns1.domain.com and ns2.domain.com from dreamhost to my own name servers and have them answer for themselves?

Only if you want to host domain.com on ns1.domain.com and ns2.domain.com. But then you also need a glue record: http://en.wikipedia.org/wiki/Dns#Cir...d_glue_records

Quote:

Originally Posted by voipfc

I had a problem before when I tried to change the name server for a domain to the domain itself i.e at the registrar set ns1.domain.com and ns2.domain.com as the DNS servers for domain.com. I don't know whether it was the result of some old fashioned DNS setup as it was some years ago.

That's the glue record problem again.

Quote:

Originally Posted by voipfc

A lot of registrars seem to prefer domain names rather than IP addresses when setting up name servers.

You must use hostnames, except for glue records where you need an IP address.

After considering the message carefully it appears that glue records are not the problem. I am not using ns.domain.com as the dns server for domain.com

It appears that when dnsreport queries the dns server it expects A records as well when it queries. I am using mydns with mydnsconfig and I wonder what entries I have to make. Does the preference/priority column have something to do with that?

Quote:

Yes, you must create A records for your ns entries as well. The priority column is for MX records only, not for A records.

I wonder why it says

Quote:

Nameserver x.x.x.x did not provide any IPs
Nameserver y.y.y.y did not provide any IPs

x.x.x.x and y.y.y.y should be hostnames, not IP addresses.