-3

before I begin kindly note that I am a newbie and still learning.

Yesterday 10 hours from now, I had to move all my hosted websites to a new server(to be more specific - from one droplet to a new droplet). So, since the websites were moved to a new server, meant that their ip addresses would change too. So, I updated the dns configuration for all the websites to point to the new ip address now. But I was unaware that the previous dns configuration had set the ttl to 86400(1 day). I learned about this concept after searching on google why my websites would still resolve to the old server.

So, that basically meant that the old dns config is cached for 1 day and I have to wait that long to see the change in the domain name resolution to reflect the websites from the new server.

So, i tried to perform nslookup and dig commands on the domains to just check the remaining ttl. But, this is where I am upset right now.

The nslookup command with -debug parameter gave the following result:

Please Note:- I have replaced my website's domain name with (mywebsite.com) and my new server's ip address with (new.server.ip.address) from the actual nslookup result 

nslookup -debug mywebsite.com new.server.ip.address


------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        address.ip.server.new.in-addr.arpa, type = PTR, class = IN

------------
Server:  UnKnown
Address:  new.server.ip.address

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 2,  additional = 2

    QUESTIONS:
        mywebsite.com, type = A, class = IN
    ANSWERS:
    ->  mywebsite.com
        internet address = new.server.ip.address
        ttl = 14400 (4 hours)
    AUTHORITY RECORDS:
    ->  mywebsite.com
        nameserver = ns2.centos-webpanel.com
        ttl = 86400 (1 day)
    ->  mywebsite.com
        nameserver = ns1.centos-webpanel.com
        ttl = 86400 (1 day)
    ADDITIONAL RECORDS:
    ->  ns1.centos-webpanel.com
        internet address = 127.0.0.1
        ttl = 14400 (4 hours)
    ->  ns2.centos-webpanel.com
        internet address = 127.0.0.1
        ttl = 14400 (4 hours)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        mywebsite.com, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  mywebsite.com
        ttl = 86400 (1 day)
        primary name server = ns1.centos-webpanel.com
        responsible mail addr = myemail@gmail.com
        serial  = 2013071601
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 86400 (1 day)

------------
Name:    mywebsite.com
Address:  new.server.ip.address

Now, here's what upset me. As in the above result, the ttl (even after 10 hours since changing the dns configuration) shows 86400. I was expecting it to show the remaining ttl but the ttl is constant at 86400. Does that mean that the dns will never update for my websites?? The ttl just does not decrease.

So, to verify even further I tried using linux's dig command and here's the result I got.

Please Note:- I have replaced my website's domain name with (mywebsite.com) and my old server's ip address with (old.server.ip.address) from the actual dig result

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> mywebsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15423
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mywebsite.com.         IN  A

;; ANSWER SECTION:
mywebsite.com.      83221   IN  A   old.server.ip.address

;; Query time: 0 msec
;; SERVER: 67.207.67.2#53(67.207.67.2)
;; WHEN: Mon Feb  5 01:55:05 2018
;; MSG SIZE  rcvd: 44

Now here, the dig command resolves the domain to my old server's ip address and it shows the ttl as 83221 !!! Like I said, its more than 10 hours that I updated the dns configuration to point to my new server's ip address. But, even after 10 hours passing, the ttl says 83221 !!!!

Running the dig command again does reflect a reduction in the ttl here though, unlike the nslookup command.

So, what do you guys think is the problem that has been going on here?? Or I am misunderstanding something?? If so, please correct me. Any kind of help will seriously assist a lot. It would really help me if someone can explain what is going on here and also what's wrong or if something is wrong with my new server.

And just if it helps, I have kept the websites' files on both - the old server as well as the new server.

Thanks.

Edit:- (Solved)

So here's what fixed all the issues I was facing. I use centos web panel on my server which comes bundled with freedns manager. So, a bug in freedns kept my nameservers and domains' dns from updating. So, I went for cloudflare dns and that fixed all the issues.

dhruvparekh12
  • 92
  • 1
  • 13

1 Answers1

1

Your domain is not correctly configured, please use online diagnostics tools such as dnsviz.net, see the report: http://dnsviz.net/d/mkinfra.in/dnssec/

You are in a lame delegation situation.

If we query .IN authoritative nameservers for your domain, they reply:

mkinfra.in.     86400   IN  NS  ns1.centos-webpanel.com.
mkinfra.in.     86400   IN  NS  ns2.centos-webpanel.com.
mkinfra.in.     86400   IN  NS  ns3.centos-webpanel.com.
mkinfra.in.     86400   IN  NS  ns4.centos-webpanel.com.
mkinfra.in.     86400   IN  NS  ns5.centos-webpanel.com.

If we query any of these 5 nameservers for your domain, they reply:

mkinfra.in.     86400   IN  NS  ns1.centos-webpanel.com.
mkinfra.in.     86400   IN  NS  ns2.centos-webpanel.com.

Which is not the same set of records. You will first need to resolve this discrepancy.

For your website they all reply the same:

www.mkinfra.in.     86400   IN  CNAME   mkinfra.in.
mkinfra.in.         86400   IN  A   139.59.63.210

So they all reply will your old IP and not the new one. Your problem has nothing to do with TTLs: the authoritative nameservers for your domain are still not delivering the new IP address you wish, so you have to configure them properly. If you do it yourself, please remember to update the serial of the zone for any change.

The serial is in fact 2018012401 which follows the pattern YYYYMMDDXX so we can infer that the zone was changed on January 24th but not since then (or was changed but serial not updated so the new content is not taken into account at all).

And to reply to your other question: if you query an authoritative nameserver you will always get the same TTL, which is per design. It is only if you query a resolving and caching nameserver that you will see the TTL decreasing from one query to another, because the case is slowly forgetting about the data it resolved in the past. Never use nslookup but always dig but always specify the command you use when you ask for people to check what you are doing (it is very important to specify the nameserver you query with the @ parameter of dig since the results will be vastly different from an authoritative or a recursive nameserver).

Patrick Mevzek
  • 10,995
  • 16
  • 38
  • 54
  • Your authoritative nameservers still serve the old IP. The serial is still the same. Did you correctly update the zone, including increasing the serial and reloading the server? – Patrick Mevzek Feb 05 '18 at 13:00
  • Thanks for helping me out. The dnsviz.net utility seems strange though as it still resolves to the old nameservers. I used mxtoolbox, leafdns and gsuite toolbox dig utility for all diagnosis and they seemed to be more relevant for my naiveness. So here's what fixed all the issues I was facing. I use centos web panel on my server which comes bundled with freedns manager. So, a bug in freedns kept my nameservers and domains' dns from updating. So, I went for cloudflare dns and that fixed all the issues. I genuinely appreciate your help. Thanks again. – dhruvparekh12 Feb 06 '18 at 14:47
  • `dnsviz` does the normal resolution path starting from the root, and similar to what I have done in my answer. If it does not see the nameserver you want it means the nameservers did not get changed at the registry level, or not yet published. I would still recommend to use `dnsviz` or `zonemaster` as they are the more detailed ones. Happy that you found a solution. – Patrick Mevzek Feb 06 '18 at 14:50
  • I really appreciate your help and need one last favour. Please don't mind, just wanted that you remove my server's actual data from the answer. Please replace that with dummy data, dummy domain names, nameservers and ip addresses. Thanks. – dhruvparekh12 Feb 07 '18 at 16:04
  • @parekhdhruv04 I don't see anything private here at all - the IP addresses are what you've told the DNS hierarchy around the world to advertise to anyone who cares to ask. – Flexo Mar 28 '18 at 08:02