I have registered and delegated a domain name thetabox.ru with the domain name registrar, which allows me to edit a zone file for my domain. I have also set up a VPS with a hosting company, which allowed me to manage DNS records for my server zone.

Originally zone records matched each other. Since then I changed the hosting company and changed some DNS records with the domain name registrar. However, even after SOA TTL expired, DNS queries to public DNS servers are getting records from the VPS hosting company's zone file, which I am not using (for example, https://www.nic.ru/whois/?domain=thetabox.ru returns my hosting company ns1.ihc.ru as a nameserver, not ns1.r01.ru as it should be according to the domain name registrar records).

What determines zone delegation, if both zones claim being the SOA for the domain? Is TTL greater than I expected?

3 Answers 3


You have to understand that DNS is a hierarchic system. This means that whatever DNS-servers the .ru-registry (a-f.dns.ripn.net) means are authoritative for your domain will also be the DNS-servers that will be asked when people try to resolve the domain.

Until the .ru-registry has updated the information regarding the domain to use your new name servers, your old name servers will be used.

  • I thought I understand this. I even checked O'Reilly's "DNS and Bind" book. What I don't understand is what forces (or should force, but does not) ru-registry to select the DNS zone from my domain name registrar in favor of DNS zone of my hosting provider, while both have equally valid SOA records. Nov 7, 2012 at 9:23
  • You have to tell the Russian registry what name servers to use. They have no way of "finding it out" in some magical way. Whoever registered the domain can tell the Russian registry through EPP or maybe through some web-interface which name servers that should be used.
    – miono
    Nov 7, 2012 at 9:33
  • Obviously. The registry records have a different name servers (ns1.r01.ru) than what I get from the public DNS (ns1.ihc.ru). The question still remains how come VPS provider SOA and NS records have preference over domain registrar zone records? dig thetabox.ru SOA gives me back this ANSWER SECTION: thetabox.ru. 42595 IN SOA ns1.ihc.ru. info.ihc.ru. 2011081101 10800 3600 604800 3600 and yet, ihc.ru is not a registrar. Nov 7, 2012 at 9:42
  • 1
    It's not about preference. It's about setting the correct name servers at the .ru-registry. ( These guys: cctld.ru/en ). The registrar of the domain can assist you with this.
    – miono
    Nov 7, 2012 at 9:48
  • It turned out domain registrar had two different menus for a) editing a zone and b) setting nameservers. It is solved now. Nov 7, 2012 at 10:08

The domain registrar sets the authoritative name servers for the domain. The VPS will only become authoritative if you properly assign hostnames (such as ns1.MYDOMAIN.com & ns2.MYDOMAIN.com) and tell your registrar to use those as your authoritative name servers.

  • The problem is that dig thetabox.ru SOA gives me back the VPS provider records, while the registrar's records indicate (dig @ns1.r01.ru thetabox.ru SOA) a different and correct SOA. Should I wait another 48 hours? Nov 7, 2012 at 8:04
  • I think the problem is that your own server thinks it's authoritative and the 'dig' command is asking your own server. If you can, I'd try removing thetabox.ru from the VPS DNS configuration. Nov 7, 2012 at 20:36

Changing a hosting provider means you need to re-register any new name servers with the domain registrar. You can check the authoritative name servers with nslookup.

  • 1
    nslookup returns the records from the VPS hosting provider, which is a) non-authoritative and b) incorrect. The original question is what indicates the authoritativeness of zone delegation other than an SOA record? Nov 7, 2012 at 8:10
  • 1
    This is very TLD-specific. .COM works the way you describe, not .FR (no idea for .RU).
    – bortzmeyer
    Nov 7, 2012 at 20:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .