I have seen this one a few times and it’s always entertaining to watch and hard to fix.
Lets say you have a domain name of company.com.xx and you host it yourself. The primary is stored on your DNS server in your DMZ and the secondary with your ISP.
Now someone in your country will be hosting the .com.xx records. They will have a DNS server with a listing of delegations, that is who is responsible for sub-domains under .com.xx like your company.com.xx
This is where it gets interesting. Delegation is done by hostname, not by IP address. In this case it will be delegated to something like NS1.company.com.xx and NS2.YourISP.com.xx
Now for a remote DNS server trying to resolve a host on your domain – eg www.company.com.xx it can query for your ISP’s records just fine. Yours however are a circular reference. You are saying that to find records for your domain you have to ask your DNS server, but to ask your DNS server you have to know it’s IP address which is stored in your domain. To get around this little problem the entity hosting .com.xx will have created a “glue record” when your domain was registered and delegated. This is buried in their server and will be an A record something like ns1.company.com.xx 2.3.4.5. Now you have a record that is supposed to be inside your domain zone, hosted outside your zone. This has the potential for confusion.
Now, if you ever decide to change the IP address of your DNS server, and you look in your DNS records, you’ll find some NS records and some A records. Changing these WILL NOT change the glue record at with your DNS registrar. Worse, no query you can do with NSLookup will show where the problem is once it’s changed. If you check with your registrar, they will show NS1.company.com.xx and NS2.YourISP.com.xx. NSLookup will show both of these to be correct. You can’t edit your own glue records, and most registrars don’t give you access to that area.
The only two ways I have found of proving the problem are to use NSLookup to directly query the registrars DNS servers for the glue record name and have them come back with an IP that is different to your NS records, or to start digging through your internal DNS servers DNS cache. It will have the incorrect record stored in there as that is where it is directed when it does a query about your domain.
Then ring your registrar and get it fixed.
I have seen this stuffed up generally in countries where the domain management is “less than ideal”, but also in Australia. It can be confusing for a first time exercise as the problem looks setup correctly, the broken record is one there you can’t see.
If you have a delegation problem, this is where I start.
‘dig’ can easily help you to find what are your glue hosts:
dig @yourccnic.com.xx company.com.xx
It will give you both your nameserver hostnames _and_ the glue records for the domain in the “additional section”.
wow quite complicated! i have exactly that problem by now! so i have to ask my provider… hmm^^ thx!