Tag Info

Hot answers tagged

15

No you don't because DNS records don't propagate. What you do need to allow for is for any cached records to expire, based on the TTL of the record in question. If this is a new record, no caching can have occurred so the new record should be available and should resolve immediately. Additionally, the root servers (first level; .) don't host DNS zones or ...


9

Ahead of the time that I want to change the addresses on the records I will usually set the TTL on the records down to maybe 5 minutes. If the existing TTL's are, say, 48 hours then do the TTL change farther out than 48 hours before you want to change the addresses. This will give these records with a 48 hour TTL time to expire out of server / resolver ...


6

Whois lists your name servers as amy.ns.cloudflare.com and cody.ns.cloudflare.com, but the parent servers (the gTLD servers) list ns1.netregistry.net, ns2.netregistry.net and ns3.netregistry.net as well as amy.ns.cloudflare.com and cody.ns.cloudflare.com as the name servers for your domain. You need to fix this at your domain registrar as they're the party ...


5

This is normal - they should have warned you though - and you should expect interruptions for at least the next day (if you're lucky; and the next month if you're unlucky). Older versions of SSL require their own IP. SNI is a "modern" technology that lets multiple sites share an IP, in the same way that standard HTTP can share via Virtual Hosts. SNI has ...


5

You are correct that your TTL should cause all sites to upgrade within 2 hours. However, having worked at an ISP for years I can attest that many large and important sites ignore TTL, and cache for 24-48 hours regardless. So most sites will change within your TTL... but an annoying few will take days. I once saw a DNS that took 7 days before it read a new ...


5

It takes exactly 0 seconds for the MX records to propagate... because DNS records don't propagate. What you need to think about is how long the TTL for the MX record and corresponding A record are. That will determine how long a DNS client which has already resolved the MX and A record will hold that information in its DNS cache (which would be on the DNS ...


5

Propagation delay focuses on speed of signal travel through a medium: fiber, copper, air, etc. Transmission delay is overall delay, including delays through equipment as well as media.


5

If you're running 100+ servers, you really should look into a configuration management system, such as cfengine, puppet, bcfg2, etc. A well-configured system would be able to push out routine package upgrades very easily, with little or no additional scripting.


5

The problem is that websitewelcome.com effectively delegated the domain to 1and1: $ dig NS uptowngreenville.com @ns1144.websitewelcome.com ... ;; ANSWER SECTION: uptowngreenville.com. 86400 IN NS ns58.1and1.com. uptowngreenville.com. 86400 IN NS ns57.1and1.com. Also weird, when you trace the resolution, the upstream resolver gives ...


4

Your whois record shows only the two (correct) nameservers: Nameserver: amy.ns.cloudflare.com Nameserver: cody.ns.cloudflare.com So I speculate that something went wrong with the domain transfer, and you need to contact your registrar to have it fixed.


4

A change of the DNS servers by your registrar will generally take up to 48 hours to propagate, regardless of the TTL you set on the NS records in your zone. dig +trace www.ihearthawaii.com shows that for me the updates have propagated correctly and your domain resolves as you expect. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 ...


4

Behavior is what I would expect if you had a mix of old and new nameservers specified at your registrar. Nameservers usually rotate on each request. Try checking what the root servers respond with. On Linux, host -a yourdomain.com. j.gltd-servers.net. will show the data for yourdomain.com. The number in the response lines is the time (in seconds) the ...


4

Problem solved. Finally. Apparently Register.com did not update the glue records for ns1 and ns2.faithhiway.com despite our initial request for them to do so (and their confirmation that it had been done). The tests that I posted above in my update showed that despite their confirmation of the update, the glue records were not propagating correctly. I ...


4

OK, the whois confirms that the listed nameserver for thejarbar.org is 88.89.190.171, as you had said, but there doesn't appear to be any nameserver running on that host, or at least there isn't one that's prepared to accept queries for your domain: [madhatta@risby ~]$ dig thejarbar.org @88.89.190.171 ; <<>> DiG 9.8.4-RedHat-9.8.4-2.fc16 ...


3

You need to port forward UDP/TCP port 53 to your name server in order for it to recieve and answer DNS queries for your domain.


3

I have just set up (successfully I hope) a DNS server at with some name server records on Ubuntu 12.10 while I am waiting for it to propagate I would like to know for future reference if I can use more than 2 forwarders in my /etc/named.conf.options.Would this speed up propagation? The DNS Forwarders set on your authoritative servers and the ...


3

It sounds to me that you haven't registered the appropriate glue and NS records with your registrar. A quick dig on the zone seems to confirm this. As you can see, there are no DNS servers that are currently registered as authoritative for thejarbar.org. Did you even register your name server with them for delegation? You need to do both of these things if ...


3

Yes, it should be your TTL setting, IF all the dns servers are standard and honor that, which is not always the case. You can use a tool like http://www.digwebinterface.com/ to verify the propagation, however.


3

It can change depending on which nameservers are updated. Check your TTL -- if it's 24 hours, it means servers are allowed to cache at least that long. But, some cache longer anyway, and it can be staggered, which means it can easily be 3x the TTL to actually move. If you know you're going to be switching DNS, set your TTLs low so the switch can happen ...


3

[Edit - It appears I misread the question] There are two ways in which your zone data 'propagates'. And the root servers are not (directly) involved. They allow other computers to find your servers, and hence your zone data. But it's other systems that check the root and tld servers before they get down to yours. Here's how your data does propagate. ...


3

What I did was to create my own internal repo (which is painfully simple): Create a web accessible directory Put RPMs there Run "createrepo ./" Point your clients there by adding the following file into your /etc/yum.repos.d/ directory: name=My Repo baseurl=http://path/to/directory/above gpgcheck=0 You can now install RPMs from the directory that ...


3

You have 2 problems: The queries for ns1.faithhiway.com are returning incorrect results. The name servers listed for your domain are wrong. You're actually testing a little backward. You're testing for what ip address is being returned when querying for ns1.faithhiway.com but what you should be testing for first is what name servers are actually being ...


3

The first step is to lower the TTL on the MX record 24 hours prior to the move to a very low value, such as 5 minutes. Then when you actually perform the migration, only DNS requests made within the last 5 minutes will cache the old mailserver IP. After you've determined that everything moved correctly and you are not going to be undoing the migration, set ...


3

You simply can't fix admins that refuse to listen to the TTL setting. So forget that problem, because it's not one you can solve. Assuming that can't be solved, then if you've done all the other right steps then there is nothing you can do. You need to try very hard to synch the servers as best you can in a small window, but even with that there is a ...


3

The nameservers appear to be somewhat less than optimally set up. Looking at the output from DNSCheck for volumeone.org, there are a few things that stand out. The two name servers are both on the same AS. This means that if there is any problem reaching that AS, then neither of your nameservers will be accessible. It's generally recommended to have name ...


3

It's not uncommon for the name servers to exist somewhere other than the Registrar. Many web hosting companies tell customers to move their name servers to the web hosting company (some may even require it although there's no technical requirement for a web host to also host the DNS). Many "individual" web hosters also tell their customers to move their name ...


2

Confirm from your client about the configuration if you don't have the access to do them by yourself. IP address is required for A record entry and dns is also required for domain name resolving. Both of them should be pointing correctly.And also its depend upon TTL time (how much time it will take to propagate). Currently dig command shows this if its ...


2

DNS doesn't propagate. The only way that the slave server at your previous host can affect name resolution for your domain is if it's still listed as a name server for your domain. Check the WHOIS information for your domain and check your domain registrar to see what name servers are listed for your domain. If the old slave server is listed then you need to ...


2

Run run dig +trace NS your.domain.com then ask each of the name servers above you what is their opinion about name servers for your.domain.com. To give an example with att.com: $ dig NS +trace att.com ; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> NS +trace att.com ;; global options: +cmd . 395258 IN NS ...


2

You should set the TTL (time to live) as low as possible. How you do this will vary from DNS provider to DNS provider. Make sure to do this at-least as far in advance as your existing TTL is so that everyone with the old TTL has a chance to get the new one. http://www.zytrax.com/books/dns/apa/ttl.html Ultimately though if the app server's IP address is ...



Only top voted, non community-wiki answers of a minimum length are eligible