chrpai
Contributor
www.scubaboard.com isn't resolving anymore. Fortunatly someone knew the IP and I put it in my hosts file.
Whats with DNS?
- Thread starter chrpai
- Start date
Please register or login
Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.
Benefits of registering include
- Ability to post and comment on topics and discussions.
- A Free photo gallery to share your dive photos with the world.
- You can make this box go away
blacknet
Contributor
Hello,
Looks like someone hosed the ns entry. Possibly from Last Updated on: 29-Jan-04 event.
Ed
Looks like someone hosed the ns entry. Possibly from Last Updated on: 29-Jan-04 event.
Ed
OP
chrpai
Contributor
Tech Admin-
Hitting Scubaboard using http://ip_address doesn't work because the logon fails ( cookies problems ) The only way I can connect AND logon is by putting an entry in my hosts file and then using the FQDN to access the site.
Hitting Scubaboard using http://ip_address doesn't work because the logon fails ( cookies problems ) The only way I can connect AND logon is by putting an entry in my hosts file and then using the FQDN to access the site.
In the process of moving over several club domains to a virtual hosting server the dns information for scubaboard.com was changed as well. This problem is not a bug nor a software or hardware error but rather a case of a human mistake. For those of you who don't know, DNS is what tells your computer what ip (numeric address) a name like scubaboard.com should point to. We have set the dns settings back to their proper location and are working with the ISP hosting the virtual server to setup a proper dns forwarding table. I have also removed the cookie domain so users should be able to access the site via the IP like I am doing right now.
As a follow up, if you notice the photo gallery is broken it is because the gallery functions off the domain and thus the ip forwarding does not work around it.
If you add the line :
69.93.91.170 www.scubaboard.com
to your hosts file, everything will be peachy
In Windows XP it's c:\windows\system32\drivers\etc\hosts - just open in Notepad and add the line. In Windows 98 I believe it's c:\windows\hosts and Win2k should be c:\winnt\system32\drivers\etc\hosts
69.93.91.170 www.scubaboard.com
to your hosts file, everything will be peachy
In Windows XP it's c:\windows\system32\drivers\etc\hosts - just open in Notepad and add the line. In Windows 98 I believe it's c:\windows\hosts and Win2k should be c:\winnt\system32\drivers\etc\hosts
blacknet
Contributor
Hello,
The real nasty/ugly/horrible thing about dns is many servers are setup to do the caching thing and it can take up to a year for the new updates to fully propagate. Dns is one of those things you avoid touching at all costs.
The best solution is a 20 min ttl and only sites that override with their own set ttl will be affected. Then again if your have no ownership of the dns your at their mercy as many default ttl values is listed as a week.
Ed
The real nasty/ugly/horrible thing about dns is many servers are setup to do the caching thing and it can take up to a year for the new updates to fully propagate. Dns is one of those things you avoid touching at all costs.
The best solution is a 20 min ttl and only sites that override with their own set ttl will be affected. Then again if your have no ownership of the dns your at their mercy as many default ttl values is listed as a week.
Ed
Caching is not something you "set up to do." It is inherently how DNS works - and its a good thing that it is.
If you intend to make changes to your DNS, the wise person lowers the TTL to a reasonable amount of time (20 minutes to an hour is usually good) a week or so before the change is to be made. This allows the new TTLs to propagate BEFORE the change is made.
Short TLLs should NOT be left around when your configuration is stable. One week is a good "default" for reasonably stable zones. Setting unreasonably short TLLs (and the load they generate) is WHY admins override them; if you do that, you're encouraging the bad behavior of override entries, and in the end all you do is screw yourself.
The other thing that gets people in trouble is not understanding the serial number rules and inadvertantly setting zones that do not refresh on secondaries as a consequence.
If you intend to make changes to your DNS, the wise person lowers the TTL to a reasonable amount of time (20 minutes to an hour is usually good) a week or so before the change is to be made. This allows the new TTLs to propagate BEFORE the change is made.
Short TLLs should NOT be left around when your configuration is stable. One week is a good "default" for reasonably stable zones. Setting unreasonably short TLLs (and the load they generate) is WHY admins override them; if you do that, you're encouraging the bad behavior of override entries, and in the end all you do is screw yourself.
The other thing that gets people in trouble is not understanding the serial number rules and inadvertantly setting zones that do not refresh on secondaries as a consequence.
Similar threads
