Got a domain name... issues?

[stevey500]

Okay, I'm helping my friend jeremy out with a server we are building out of his new mac mini running leopard. We have installed PHP 5, MySql, built in apache, etc...

He is running through a time machine and then to a Quest DSL modem. We have forwarded his ports to all the services we will be using.

We built a sample website... When we go to http://hisstaticIPaddresshere it works great... even from outside his network without any issues. We signed up at Godaddy for a domain name ... www.jeramii.com, we registered it to direct @ to his static IP address knowingly to be working....

WAS WORKING once before no problems at all for about an hour as we toyed with the site... but his static IP address changed, we have yet to switch his quest DSL account to a Fixed IP address, ... went to Godaddy to change the IP address the DNS directs to with no luck... it's been about 6 hours, do we have to wait?




ALSO.. if anyone has been using jinzora2 (media jukebox interface based on PHP and mysql) ... would you have any idea why it stops while importing mp3 files to the database? ...


thanks for any help..
it's quite appreciated

 

[belvdr]

FYI, static IP = fixed IP. It sounds like he has a dynamic IP right now, which can change over time.

If the Time-To-Live (TTL) of the DNS record is high, most DNS servers will cache the old IP for that time. Of course, one could configure their DNS server to not adhere to the authoritative TTL, but I have not seen that in general.

Give it a day or so, or update your TTL on the DNS server so it is only 10 - 15 minutes.

 

[angelwatt]

Updating the IP can take a little while to propagate, but 6 hours seems like more than enough time. When I use to go that route it would take less than 30 minutes. The ISP may not want anyone running a web server on basic service. They may "block" it from those not paying for a static IP. Something to look into anyway.

 

[SrWebDeveloper]

Respectfully to all, I need to interject some technical stuff and correct some statements posted here. DNS propagation actually can take upwards of 24-48 hours on average. The TTL is for the local DNS at your ISP and determines how long until a re-cache (updating of a local copy of master records) which can be set low, i.e. the world sees it very fast when querying your local ISP's DNS. The problem is, the same DNS is cached beyond your local ISP. These networks re-cache according to their own policies and often ignore the TTL since doing so is not enforceable. Re-caching occurs at numerous levels including DNS servers running on all the ISPs out there, networks with router and proxy cache, and the 13 well known root servers that distribute the master records for top level domains.

RFC2308 suggests TTL be set to 1-3 hours, and network admins usually set it to 5-10 minutes when moving stuff around or important changes, then change it back after local re-caching has completed. But "allow for" a day or two on average for full propagation around the globe due to varied upstream re-caching policies. If it happens faster, great, just -- never count on it.

-jim

 

[belvdr]

These networks re-cache according to their own policies and often ignore the TTL since doing so is not enforceable.

Not necessarily. I run my own machine at home via DynDNS and I haven't found many DNS servers out there not respecting the TTL. Of course, it could just be the region I'm in that I'm usually using the same few DNS servers.

Aside from that, I kept our TTL low for our organization and moved things about during some infrastructure work, and had no complaints from any of our members in the US.

 

[jampat]

During a domain hiccup a year ago, it took almost 48 hours for our updated DNS to propagate fully. For another project, I use dyn dns updated automatically via a router and it always seems to work. I wouldn't want to go this route if something was critical though.

 

[SrWebDeveloper]

Not necessarily. I run my own machine at home via DynDNS and I haven't found many DNS servers out there not respecting the TTL. Of course, it could just be the region I'm in that I'm usually using the same few DNS servers.

Aside from that, I kept our TTL low for our organization and moved things about during some infrastructure work, and had no complaints from any of our members in the US.

Regionally? Sure, due to ISP's sharing major backbone feeds and US backbone peering policies. But the time factors discussed so far by others didn't focus on regions, the talk was generic as if for "full" propagation which I hit upon. All I'm sayin' is 24-48hrs is a better liability statement to your clients, considering local re-caching policies supercede sometimes, plus distance between peers. It's great if it happens faster, but if you simply mention "6 hours or so" without explanation, one day you might get burned. That's all I really am gettin' at.

-jim

 

[belvdr]

Regionally? Sure, due to ISP's sharing major backbone feeds and US backbone peering policies. But the time factors discussed so far by others didn't focus on regions, the talk was generic as if for "full" propagation which I hit upon. All I'm sayin' is 24-48hrs is a better liability statement to your clients, considering local re-caching policies supercede sometimes, plus distance between peers. It's great if it happens faster, but if you simply mention "6 hours or so" without explanation, one day you might get burned. That's all I really am gettin' at.

-jim

Agreed, but for the record, I did say "day or so".

 

[mshepherd]

Alot of times I have noticed that if you are only checking from the same machine that visited the site prior to the change then it is the local dns cache causing it to look at the old ip. you can clear that by entering this in terminal:

dscacheutil -flushcache


DNS servers tend to propagate pretty fast nowadays.