|
Where to upload your files:
Configuring your FTP clients:
Understanding the web site file system:
CGI Based Programs:
The ins and outs of DNS and how it effects your domain:
Setting up and managing Sub-Domains:
Setting up Domain Email:
Where to upload your files:
The Home
Directory:
Your html files, and or the files you want to make
accessible to the World Wide Web must be uploaded to your
account. When you first FTP into your account, you'll be
taken to your "Home" directory. Don't confuse this with
your "web directory." The home directory is "not"
accessible to the World Wide Web; it's a private directory
where critical system files reside. DO NOT delete files
that have been created by the system, otherwise your web
site may disappear into cyber oblivion!
The
public_html
and
www
directory - (Where web accessible files are placed)
These are the two directories, where
files you want accessed from the web must be placed. Open
the folder "public_html" , which is your "web accessible
directory." The folder named "www" is actually a shortcut
to public_html, (both of them take you to your web
directory). Upload the files you want accessible to your
visitors and feel free to make the appropriate
sub-directories you'll require.
Configuring FTP Clients:
Configuring
Cute FTP
Based on version 4.2
Please note that there are a number
of older and current versions of Cute FTP floating around.
As a result, some of the instructions provided here cannot
possibly reflect all the versions, which have been
released in the past 5 years. The only small difference
you may encounter is where some of the options can be
found (depending on the client version you're using). In
any event, everything is pretty well much the same. Let's
get started:
1. Open Cute FTP
2. Select "File"
3. Select "Site Manager"
4. Select "New"
Options you'll see:
- Label for site: Enter a name for
this account. For example, "My Root
Account."
- FTP Host Address: www.mydomain.com
- FTP Site Username: Your main
system login name
- FTP Site Password: Your main
system password
- FTP Site Connection: Port: 21
- Login Type: Normal
Notes
About Cute FTP:
There are a few advanced features you may want to be aware
of. These features may need to be enabled if you're having
problems accessing your site via an FTP client. The
following will explain:
Trouble accessing your site via FTP:
This can sometimes occur if your accessing the Internet
from behind a firewall, personal router, or using an
Internet connection sharing system such as NAT (Network
Address Translation). This is often a class case scenario
in a home or small office where several computers are
being shared by one Internet connection. Symptoms
include, difficulty logging in via FTP, and or maintaining
a reliable upload or download session.
Use Passive Mode instead:
From your FTP main interface, select:
1.
Edit
(from the main dropdown
menus)
2. Settings
A dialog box called "Settings" now appears. Select:
3. Connections
4. Firewall
This opens the Connection/Firewall dialog box:
5. Check the box that says "PASV
mode."
6. Click OK
Don't touch any of the other settings
Ignore all other settings
you see here except for the "PASV_mode" setting!
Give it a try and see how it works. If you're still having
problems, you should contact your ISP to see if they can
make the necessary changes required for you to access your
site via FTP. There are a vast number of network
configurations ISP's sometimes use, and some of which that
can cause problems for users wanting to access the web
beyond that of a browser.
How to view all files in
your account (For Advanced Users).
Advanced users may want ability to view "all hidden" files
in their directories. While most of these are critical
system files, there are a few, which can be manually
edited by "Advanced Users." This is done by inserting an
entry into the "File Masking" feature in the client.
Unmasking Hidden Files:
1. Open Cute FTP
2. Go to the site manager
3. Select your account
4. Select "Edit"
A dialog box opens called "Site
Properties":
1. Check the "Enable Filter" box
2. Click the "Filter" button
3. Check the " Enable Remote Filters
(Server Applied Filer) " box
4. In the "Remote Filter" window, type this command
-a
5. Click ok
That's it!
The -a command
will unmask "all" files in your web account.
Final
Note:
NEVER REMOVE OR ALTER FILES, WHICH HAVE BEEN CREATED BY
THE SERVER or C-Panel!! Unless you're an advanced user,
please leave all files that have been created by the
system alone! Doing otherwise could cause serious problems
with your account, and in some cases take it offline
completely. When in doubt "ASK", do not
Delete!
Setting Up WSFTP
Please note that there are a number
of older and current versions of WSFTP floating around. As
a result, some of the instructions provided here cannot
possibly reflect all the versions, which have been
released in the past 5 years. The only small difference
you may encounter is where some of the options can be
found (depending on the client version you're using). In
any event, everything is pretty well much the same.
Setting up WSFTP:
1. Open your WSFTP client
2. The dialog box "WS_FTP" Sites should display. If not,
click the "Connect" button.
3. Select "New"
You should see this dialog box:
You'll be
taken through these options:
1.
New Site/Folder: Choose a name for
this account
2.
Host Name or IP address:
www.yourdomain.com
3.
User ID: Main system login
4.
User Password: Main System Password
5.
Select
"Save Password."
6.
Select
"Finish."
Done! Your can now FTP into your site
Notes About
WSFTP:
Main Username and Password:
The main Username and Password was sent to you in your
welcoming email, and are also the same ones used to access
C-Panel. If you've changed your "main"
Username and Password before setting this
up, then use you must use them instead.
Trouble accessing your site
via FTP:
This can sometimes occur if your accessing the Internet
from behind a firewall, personal router, or using an
Internet connection sharing system such as NAT (Network
Address Translation). This is often a class case scenario
in a home or small office where several computers are
being shared by one Internet connection. Symptoms
include, difficulty logging in via FTP, and or maintaining
a reliable upload or download session. If this is the
case, try "Passive Mode."
Setting
Passive Mode:
1.
Open the WSFTP account manager
2.
Highlight your account
3.
Select "Properties"
4.
Select
the "Advanced" tab
5. Check the box called
"Passive Transfers."
6. Click "OK"
Select passive mode, click
"OK", and try it again.
How to
view all files in your account (For Advanced Users).
Advanced users may want ability to
view "all hidden" files in their directory. While most of
these are critical system files, there are a few, which
can be manually edited by "Advanced Users." This is done
by inserting an entry into the "File Masking" feature in
the client.
Unmasking Hidden Files:
1. Open the WSFTP account manager
2. Highlight your account
3. Select "Properties"
4. Select the "Startup" tab
5. In the "Remote File Mask"
window, enter -a
The -a command
will unmask all files in your web account.
Final Note:
NEVER REMOVE OR ALTER FILES, WHICH HAVE BEEN CREATED BY
THE SERVER or C-Panel!! Unless you're an advanced user,
please leave all files that have been created by the
system alone! Doing otherwise could cause serious problems
with your account, and in some cases take it offline
completely. When in doubt "ASK", do not
Delete!
Understanding the web site file system:
index.html
and why you should use it:
This again is where a number of
newer webmasters become stumped. They upload all of their
files and directories, and then want to access them with
their browser, but forgetting to create their welcoming
page as index.html, so here's what happens: They access
their site as
http://www.mydomain.com/ or using the associated IP
number, for example,
http://test.html/, and what they see is their entire
file directory structure! Yikes!… It looks just like
exploring the C drive on your computer! You don't want
visitors seeing that, do you?
When you access your site by calling it as
http://www.mydomain.com
or
the assigned IP (for example),
http:// 217.74.132.26/, the web server looks for
the "index.html" file as the (default file) to be sent to
visitors, and thus this is why
http://www.mydomain.com/ by itself will
automatically display the home or welcoming page. It's
because the server automatically looks for index.html
whenever a domain or directory is called without a
filename appended to it such as this,
http://www.mydomain.com/file.html
If it can't find index.html, it will simply list "your
entire web directory" to everyone that access's it, which
is a MAJOR security risk! ALWAYS, use an "index.html" file
in any directory you create, including your "root" web
directory. In general, it's always a good idea to use "index.html"
as your main page in "all sub-directories" of your
account. Forgetting to place an index.html in your root
web, or any subdirectory of your web for that matter will
effectively leave all of its contents viewable to the
world.
Understanding case sensitivity:
Another small detail, which can
throw many newer users into a tailspin. Unlike your local
PC, the Unix file system is very particular about
"uppercase" and "lowercase" file names. Therefore, if you
were to install a script, (let's say the wwwboard
discussion forum) for example), the name of this script
would be wwwboard.pl. If you name a file picture file
called me.jpg, then this is what you must call it as.
Naming it me.JPG for example, (observe the uppercase)
tells a Unix web server to treat it as a totally different
file name.
Unix file servers are exceptionally fussy on this issue,
so make sure you pay close attention to "case' when
uploading files, or installing and configuring cgi based
scripts. The same rule applies for all files including
your .html pages. Again, the server treats .html and .HTML
as two entirely different files. Want to keep in simple?
Try to stick with lowercase letters in all file names and
extensions.
Uploading your files in the
correct mode (ASCII or Binary)?
Uploading in the wrong format for images or binaries will
result in a strange mess appearing in place of the file.
For CGI scripts, this mistake has to be the most common
cause of that annoying error known as the (Server 500
Error - Malformed Headers), or something to that lovely
extent. While this can be the result of many various
programming errors, the most popular amongst new users are
uploading their scripts in the "WRONG" format. Your cgi
scripts "MUST" always be uploaded in ASCII mode.
Alternatively, if you upload an image or .exe file, it
must be done in "BINARY" mode.
The difference between ASCII
and BINARY?
In short, html or text based files are supposed to be
transferred in ASCII mode. Uploading them in Binary mode
will append ^M's to the end of every line. In most cases,
this is OK, with html files because your browser will
ignore them. BUT, with other text files such as cgi
scripts, uploading them in binary will damage them, thus
causing a (server 500 error). This is because binary mode
has added ^M's to the end of every line, which are not
supposed to be in the program. This of course, is what
causes the additional message of (Malformed Headers),
which often displays at the bottom of the "Server 500"
message when a CGI script has crashed.
Once again, BINARY mode is used for transferring
executable programs, compressed files and all
image/picture files. If you try to upload an image in
ASCII mode, you observer a strange mess appearing on the
page where the image is suppose to appear. ASCII mode in
this case, has corrupted the binary coding in the jpeg or
gif image. If this happens, just re-upload it in the
Binary format
Setting your FTP client to automatically detect ASCII and
Binary file transfers:
Most FTP programs have "AUTO" mode, which will tell the
FTP client to automatically detect the file type you're
transferring and will select the appropriate mode. By
default, most FTP programs will attempt to transfer
everything in binary mode, but when "Automatic" is
selected, the FTP client will check a list of known ASCII
extensions, (for example, .pl, .cgi, .txt). If it detects
one of these extensions, it automatically switches to
ASCII mode.
By Default, most of the well-known files to be uploaded in
ASCII are already entered, however you can manually add
additional extensions that you would like to transfer in
ASCII mode by selecting the feature called "Extensions."
Here, you can any additional extensions that will cause
the FTP client to toggle to ASCII mode automatically upon
detecting an extension entered in its list. Remember, you
must set your transfer mode to "Automatic" for this to
work.
File
types and what they represent:
Various file types can effect both the behavior of your
files, as well as how the server treats them. While there
are numerous file extensions, which represent a host of
various file types, we'll stick to the basic ones in this
quick overview:
The .html file:
This is one is the most commonly used and the most one of
you are already familiar with. Html stands for (hypertext
Markup Language). Essentially, it tells the server, as
well as the clients browser to process and display the
.html coding in a way, which is meaningful to the end user
through a browser.
The .htm file:
Many of you have probably noticed this newer extension
appearing in place of the traditional .html one. In short,
.htm is most often created, and or generated from the
Microsoft FrontPage web editor. The two are essentially
the same and provide the same basic purpose. Unless you're
using FrontPage, you will probably use the .html extension
at the end of your web pages.
The .gif and .jpg file:
Most commonly used because of its good compression in web
page images. Generally, .gif files are the fastest
loading, as they remove a lot of information, which is not
required to maintain image integrity, but to a point
however. .jpg will allow more flexibility in compression
and quality settings, however can also result in larger
files.
The .CGI and the .pl file:
.cgi and .pl are most often used for perl scripts. Perl
scripts are small text based programs, which are executed
on the server end, and will perform a host of interactive
functions for a web site. In short, when a .pl or .cgi
file is called, it tells the server to process it using
the "Perl Interpreter." The Perl Interpreter understands
the programming within the script, and will perform the
set of sub routines, which will yield your desired effect.
This desired effect could be anything from a simple web
page counter, to more complex programs such as discussion
forums, e-commerce platforms, to online auctions. In many
cases, you can download these "ready to go" scripts for
free, and in others you may have to purchase them.
FrontPage
and FTP:
If you're planning on using
Microsoft FrontPage to manage your web site, there are a
couple of issues things you may want to keep in mind:
There are two worlds. The General Unix hosting world, and
the Microsoft world. While this is not necessarily a bad
thing, Microsoft had indeed decided to play by its own
rules. As a result, FrontPage does not always conform to
the rules of Unix, so you should be extremely careful when
accessing a FrontPage web via FTP. It's easy to damage
the FrontPage web, as well as it's associated server
extensions, and if it happens, you may loose the ability
to administrate it from your FrontPage Explorer. To avoid
problems like this:
-
Do not
alter, or delete files that are part of a FrontPage web
-
Do delete,
move, or alter directories ending in _vtf. These are the
FrontPage extensions
The ultimate solution:
If possible, try to create your FrontPage webs in
sub-directories of your root. For example,
http://www.yourdomain.com/home. This way, you can
safely FTP into your root account to perform other tasks,
while avoiding the FrontPage webs, which are safely out of
the way in their own separate homes. Remember! DO NOT
delete any folders, which end in _vtf! This will kill your
FrontPage web, and we'll have to reinstall the extensions
for you. For additional information on FrontPage,
please see our dedicated tutorial on it.
Using
CGI programming:
Where to place your CGI
scripts:
Although there is nothing dangerous about placing cgi
scripts in random directories throughout your site, it's
best if you keep them in their own little home known as
the cgi-bin. This minimizes security risks and allows you
to maintain your cgi programs from one directory.
The path to Perl:
One of the first things you must do when configuring a
script, is set the correct path to the Perl interpreter,
which is the engine responsible for processing the script.
The path to Perl on our servers is: #!/usr/bin/perl
The path to Sendmail:
Some programs such as the ones, which send email will need
to know where the Sendmail program resides on the server.
The script will typically have a setting like this: $mailprog
= '/usr/sbin/sendmail'; and will want you to set it
appropriately. Sendmail on our servers can be found here:
/usr/sbin/sendmail or /usr/lib/sendmail.
Setting directories within
your cgi scripts:
When you configure a cgi script for "any" server, it may
ask you to set variables such as the base, relative, and
CGI directory/url settings. Here's an "example" using Matt
Wright's wwwboard.pl script. Obviously, each script may
vary, but this should provide you with some basic idea:
$basedir = "/home/yourlogin/public_html/wwwboard";
$baseurl = "http://www.YouSiteHere.com/wwwboard";
$cgi_url = "http://www.YouSiteHere.com/cgi-bin/wwwboard.pl";
Most scripts come with documentation on how to set these
directories. Please make sure you read and understand it
before configuring the script. New to cgi? Here is a page
with questions and answers to numerous questions evolving
around the inns and outs of using cgi within your scripts:
http://www.w3.org/Security//www-security-.html
Another excellent site, which provides step by step
chapters is:
http://www.cgi101.com/class/
Understanding File
Permissions:
There are a number of file permissions, which can be used
for a variety of different purposes, however we'll limit
this tutorial to the ones most commonly used. To begin
with, it's important you understand the three categories
of permissions, which are:
Owner Permissions:
The owner is you. In most cases, this is not so much of a
concern, as you can only obtain owner permissions in one
of two ways. 1. FTP into your account using your Username
and Password. 2. Login via Telnet with the same
information.
Group Permissions:
The represents a group of users who have access to a
particular directory. For example, a password protected
directory, whereas only members can access it upon
providing the correct Username and Password. In this case,
any permissions you assign to "Group" would be applicable
to users with access to that particular directory.
Public Permissions:
This is the most important one of all. Public permissions
determine what your world wide visitors can and cannot do
with your files. ALWAYS make sure you understand what a
particular permission does before assigning it to a file.
If not, you may wakeup to find your website demolished by
some clown who was snooping about and gained access to
your files.
Setting File Permissions:
To set file permissions:
1.
Login with your FTP client
2.
Open the
directory where the file you wish to set permissions on
resides
3.
Right
click on the file and select CHMOD
A box similar to the one above will appear
Observe how you can "select" the
individual permissions you want, or simply enter the 3
digit number if you know what it is. Most instructions
included with downloaded scripts will tell indicate this
to you.
By default, all files uploaded to
the server automatically have permissions set to 644. The
setting 644 is relatively safe, as it provides "Read" and
"Write" access to the owner, while limiting the rest of
the public to "Read Only" access.
When setting permissions for cgi scripts, the most common
permissions setting is 755. 755 allows the owner "Read
and Write" access, while allowing the Group and Public
"Read and Execute" permissions. So what are we actually
saying? In short, when users access your cgi script, the
server has been instructed to grant them permissions to
"Read and Execute" it. Sound scary? It's not actually…
Remember that a script is a program that must be processed
by the server. As long as the script is written properly,
you can safely allow users to execute it, and thus
providing the desired results. For example, if they wanted
to post a message to your wwwboard discussion forum, then
they would need these permissions to execute wwwboard.pl,
which would write their new message to an html file, which
is displayed on the main forum. The new message would
reside in a directory on your site so other users could
view it. Most cgi, perl and other scripts you'll be
installing come complete with instructions telling you
which permissions you'll need to set them to.
WARNING!
Setting permissions on files is a relatively simple task,
however MAKE SURE you fully understand what it is you're
allowing the public to do with your files. For example,
some less experienced users often make the fatal mistake
of simply setting ALL of their files to 777. While 777
will automatically allow executing privileges, it also
allows full "READ, WRITE, and EXECUTION ability to the
entire world!!!!
This is how web sites get hacked! While most visitors have
good intentions, all it takes is one person whom snoops
about your files seeking an "Open Back Door." This could
result is them gaining full access to your directories,
which means they can do anything from deleting your entire
site, to defacing it with obscenities.
New to cgi? Here is a page with questions and answers to
numerous questions evolving around the inns and outs of
using cgi within your scripts:
http://www.w3.org/Security//www-security-.html
Using Server Side Includes -
SSI
SSI works in conjunction with a web page usually with the
.shtml extension. The .shtml extension tells the server
to do something different with the web page. When you
append the .html or .htm extension, this tells the server
to "read" the page only. The .shtml extension tells the
server to "Execute" the page, in addition to just reading
it.
So, why would you want to execute the page? There are
various commands you can program into a web page, which
the server will look for and parse when the file is called
as .shtml. In many cases, this mode is used in conjunction
with Server Side Include (SSI) tags, to call a CGI script.
For example, you have a visitor counter script, and we'll
call it count.cgi. Every time someone visits your website,
you want the script to be called, so that it logs the
visitor into a file.
To do this, you would place an SSI tag into your web page.
The tag in this case, would look something like:
<!--#exec cgi="/cgi-bin/count.cgi" -->
This small tag, which is hidden in the html coding of your
page is telling the server to:
1. Go to the cgi-bin
2. Execute count.cgi
That's it! The information has been captured and processed
by the count.cgi script. Of course, that's the short
version of what happens. The long version would no doubt,
would take us far beyond the scope of this document.
PLEASE do not use the .shtml extension on "all" of your
web pages unless it's absolutely necessary. With a busy
web site, this means that every page must be executed, as
opposed to just read. This as you can appreciate, can add
considerable memory and CPU load to the system. As always,
read the instructions that came with your script
carefully. They should provide specific instructions on
how to configure the script, as well as the SSI tag.
The
ins and outs of DNS and how it effects your domain:
Understanding
DNS and Name Servers:
This is an area, which causes a
great deal of confusion amongst both webmasters and end
user clients. Before we go any further, let's look at this
quick analogy: DNS can be considered something similar to
that of a phone book. When you move from one location to
another, your last name stays the same, but your phone
number may change. In order to point your name to the new
phone number, you must contact the telephone service
provider, which will assign you the new phone number. In
addition, they update all directory information data basis
to reflect you as pointing to this new phone number.
What
is DNS?
DNS stands for "Domain Name Server." The domain name
server acts like a large telephone directory in that it's
the master database, which associates a domain name such
as (http://www.mydomain.com) with the appropriate IP
number. Consider the IP number something similar to a
phone number: When someone calls
HTTP://WWW.YouSiteHere.com/, your ISP looks at the DNS
server, and asks "how do I contact YouSiteHere.com?" The
DNS server responds, it can be found at: 157.238.96.231.
As the Internet understands it, this can be considered the
phone number for the server, which houses the HTTP://WWW.YouSiteHere.com
web site.
Where are all of the DNS
records kept?
This is slightly more complicated, but for the purpose of
this overview, we'll try to keep it as general as
possible. There are 2 basic places DNS records reside:
International Root name servers (13 exist throughout the
world)
Your domain register, where your current DNS settings
reside.
When you register/purchase your domain name on a
particular "registers name server", your DNS settings are
kept on their server, and in most cases point your domain
to the Name Server of your hosting provider. This Name
Server is where the IP number (currently associated with
your domain name) resides.
The entire hierarchy is somewhat involved, but in short,
the world Root Name Servers can be considered the master
listing of all DNS records, and there are currently 13 of
them in the world. These name servers are where all the
master DNS records are kept. The DNS server of your ISP
will typically query the Root Name Servers once every
24-hours. This is how they update all of their DNS tables,
which in turn, resolve www requests to the IP number of
the server they reside on.
Changing your Name Server settings, so your domain points
to your YouSiteHere.com
account:
Your "Name Server Settings" must be updated to point to
your account on YouSiteHere.com. You originally purchased your
domain name from a register, and this register is where
your current DNS settings reside. That is, unless you
transferred your domain name to an alternate register, in
which case, you would control your DNS settings from
there.
The "Register" your domain resides on, communicates your
'current' DNS settings with the International Root name
servers, which is turn share this information with ISP's,
routers, and cache engines around the world. In essence,
it's like a worldwide directory that other computers can
refer to when they want to match a domain name with its
associate IP number. This IP number is how the particular
server your website resides on is located.
Accessing your domain
manager:
Simply go to your domain registers web site, and look
around for links, which point to something like, domain
manager, manage domain, or something of that
administrative nature. In your welcoming email, you were
sent DNS settings, which look similar to this example:
NS1.YouSiteHere.com 69.57.152.164
NS2.YouSiteHere.com 69.57.152.165
Most of the newer registers such as the (OPEN SRS) based
entities have turned this into a 5-minute process. You
simply login to the register, select 'manage domain' and
you'll be presented with an option to update your new DNS
numbers. Contrary to popular belief, Network Solutions
'now' also provides an online interface to change these
settings, so this process with them is no longer as
complicated as it use to be, however it's still not as
simple as the OPEN SRS based systems. If your particular
register 'does not' provide a domain manager of some type,
then you'll need to send them a message requesting a
change of DNS. This is an unlikely scenario, as most every
register now allows you to manage your own domain settings
from a web based interface.
Once you've accessed the "management interface" of your
domain name, look for a setting, which says "change or
manage DNS settings." In most cases, you can simply cut
and paste the DNS settings we've sent you directly into
the spaces, which correspond to your DNS management
settings. Remember, the DNS settings we're displaying here
are an "example."
The 3 to 4 day propagation
period - Understanding what happens during this time
frame:
In short, patience is a virtue. Remember what we talked
about earlier in this chapter regarding the shear size and
scope of the worlds DNS system? In short, when you change
your DNS settings, these new settings must propagate
throughout the worlds DNS servers. It also means that
every ISP (Internet Service Provider), must update their
DNS records to reflect these new changes, which in most
cases, is done automatically every 24 hours, but not
always however...
Where
do the Root Name Servers receive their information from?
The Root Name Servers will query "domain registers"
several times a day. Domain Registers, being entities such
as Network Solutions, and the newer OPEN SRS based
systems. The Root Name Servers will gather this
information from the many registers now in existence, and
update their master records accordingly. Now your ISP must
access the Root Name Servers, and update their DNS
records, which reside on their 'local' DNS server. This
process is fully automated and most ISP's will check the
Root Name Servers for updates every 24-hours. Beware
however, that some lame ISP's will delay this process for
as much as 2 to 4 days in some cases. If that happens, it
will no doubt cause additional confusion, as everyone else
will be reaching your new account on our servers except
you. This is because your ISP has not updated their DNS
records, and or have not cleared their DNS cache, which
means they'll still be pointing your domain name to your
old server. If it's a new domain name you've registered,
then you'll receive a blank "Site Not Found Page."
DNS Cache and your ISP:
There is also the issue of DNS cache, which is something
we won't go into great detail about here, but here's the
short version. Every time you access a site from your ISP,
they cache the URL, as well as its associated IP number.
If their network is properly setup, these DNS cache
records should "Expire" at least every 24-hours. If they
did not (which is often the case), you'll experience this:
You enter your
http://www.mydomain.com/ URL, and it keeps taking you
back to your old server account.
In a large number of cases, it's the result of an ISP who
"Did Not" configure their servers to "Expire" the DNS
cache records at the appropriate intervals. Unfortunately,
this adds additional confusion to their clients, and
especially the ones whom are trying to point their domain
name to a new server. Yes, it will make you want to scream
sometimes, however if you understand whom is actually at
fault, then you'll know who to scream at :)
The DNS propagation process
is not limited to ISP's!
HA.. Just when you thought you had it all figured out!
Unfortunately, there's more folks. The Internet itself
must update/clear its DNS cache as well. When we say the
Internet, we mean the numerous intermediate "points of
access" you're routed through before reaching your final
destination. For the most part, these intermediate points
of access consist of "Internet Routers" and "Internet
Caching Engines." These too, maintain their own DNS cache,
which assists them in routing traffic/resolving URL's to
the correct destination IP's. Don't worry though, as
Internet routers are usually faster at clearing their DNS
cache than ISP's are.
What to expect during this 2
to 4 day propagation period:
In most cases, the propagation process will take at least
48 hours to complete. The first thing that happens is the
"World Root Name Servers" will check all of the various
"Domain Registers for updates. Ok, so now the Root Name
Servers have done their job. The rest of it is up to the
many ISP providers who "should be" updating their DNS
records (at least every 24 hours), but a number of them
will not.
Side effects that can be
expected during the propagation time frame:
It's perfectly normal for strange things to happen within
the 48-hour propagation period, but sometimes longer.
While we could provide a full list of all the anomalies
that can occur during the DNS propagation period, we'll
stick to some of the most common scenarios that most
people experience:
HELP! My friends can reach my
new site, but I'm still being directed to the OLD ONE!
This is a class case of your friends ISP (who did update
their DNS records), but yours unfortunately did not. As a
result, your ISP is still pointing your domain name to the
old DNS record, which is your old hosting account. Wait a
couple of more days, and if it appears that everyone but
you can access your new account, then contact your ISP and
tell them to expire their old DNS cache records.
WOW! http://www.mydomain.com was
taking me to my new YouSiteHere.com account just a minute ago,
but when I try it now, I'm being taken back to my old
hosting account - what's up with this?
In all likelihood, your ISP may be in the process of
clearing their DNS cache, and or updating their local DNS
server records. During this small interval, it's normal to
fluctuate between the new and old web site, as the old DNS
records may not have completely expired from their cache
yet. Give it another several hours and it should be fine.
HEY! My
new site comes up for me, but my friends are being
directed to my old one!
Break out the coffee and donuts, and consider yourself
lucky. Your ISP is on the ball and updates DNS records/
clears DNS cache in short regular intervals. Your friends
may be using an ISP, which is not as fast, and or
efficient at doing so. The only remedy for this is time.
Eventually, the other ISP's DNS cache will expire and be
replaced with the updated DNS records.
What's going on with my email?
When I try to access it, I receive a "host does not exist"
or a "cannot authenticate" error message.
This can happen for a number of reasons, but in most
cases, it's because your new DNS records have not fully
completed the propagation process yet. Consequently, you
may be trying to access your old email account on your
"old server", which you may have already cancelled, or
it's in a state of DNS flux, which means it points to the
new server one moment, and the next, points back to the
old server.
Give it some more time and it will eventually settle down.
In the meantime, consider accessing email from your
account using the WebMail based reader. If your domain has
not propagated as of yet, you can access your email
account via WebMail with your IP number. Example:
http://12.23.36.78:2082/neomail/neomail.pl This will
allow you to access your default mailbox on your account.
Replace the IP number with the one we sent you, and do not
remove the :2032 port number in the URL.
Microsoft FrontPage will not
accept a Username and Password, or displays the error
message (FrontPage Extensions Are Not Installed).
While you should be able to access FrontPage with your
associated IP number (until your domain is resolving to
our servers), this is not always the case. FrontPage can
behave in a number of different ways depending on which
direction the wind is blowing. In some cases, it will
allow you to initiate an upload session, but upon asking
for your Username and Password, will not recognize them.
If this happens, the best thing to do is wait until your
domain name is answering to our servers. One thing we know
for sure, is FrontPage will work without much of a problem
if you're using the full www.mydomain.com URL to manage
your site with. Feel free to try it with your IP, but we
cannot guarantee it will work.
It's been over a week. Everybody
else can access my new site except me!
Was your domain originally hosted by your ISP? If so, they
may not have deleted this entry in their DNS files. This
results in you, and or anyone else accessing the net from
this "particular ISP" being directed to your old web site
on their servers. A number of ISP's forget this small
detail, which can result in weeks of utter confusion and
frustration. If this is happening to you, contact your ISP
and make sure they've made the necessary changes to their
DNS records.
Checking your DNS update
status (outside of your ISP):
In the event you're becoming impatient, and or are
wondering if the rest of the world outside of your ISP can
access your new site, you can proxy yourself to another
network and test it there. In many cases, you'll be
surprised to see your site responding perfectly, yet when
you attempt it directly from your ISP's servers, it does
not exist.
There are several services, which allow anonymous surfing
across the net. While this is not the intent here, they
can be used for trouble shooting domain resolution
problems. How? Because they proxy you through their
network, which means your URL requests are controlled by
"their" DNS cache records. These services update/expire
their DNS cache far more often than ISP's, which makes
them well suited for testing your domain name through a
network, which operates with the latest DNS updates across
the web.
To run this check, you can try accessing your site through
one of these two services:
https://www.safeweb.com/o/_s:top.php3
http://www.anonymizer.com/
Both of them allow you to enter a
URL, and proxy your request through their servers. If your
site is accessible from these servers, then chances are,
your ISP has yet to expire their old DNS cache records.
Working on your account during the DNS propagation period:
You can still work on your new account until your domain
name finds it way to our servers using your "IP Number",
which was included in your welcoming email. Your IP number
is how your new domain will be identified on our servers.
Using it at this point will provide a means for you to
access your account, as well as test your new site by
using something like http://
211.94.122.26/ (obviously you'd replace it with
the IP number we sent you).
One easy way to check and see if your domain is answering
to our servers yet, is to create a file called "test.html"
and place it in your web directory. Keep checking
the URL
http://www.yourdomain.com/test.html and see if it
works. When it does, you'll know your domain name is
answering to your account on "our servers", and has been
officially transferred.
The
personal DNS (for advanced webmasters).
Personalized Name Servers are generally used by webmasters
who will be reselling web hosting accounts, and want to
add a professional look to their DNS. Why? If you're
reselling accounts under your own entity, you could use
our name servers, which would be sent to your customers in
the form of:
NS1.YouSiteHere.com 69.57.152.164
NS2.YouSiteHere.com 69.57.152.165
Not bad, but what if you want your DNS settings to appear
as a part of your company? Let's say your company was
www.yourwebhost.com. If you desire, you could setup your
own custom branded DNS, which could display as:
NS1.YOURWEBHOST.COM 69.57.152.164
NS2.YOURWEBHOST.COM 69.57.152.165
This provides a somewhat more professional look to your
customers when sending out your DNS settings in a
welcoming email. In addition, if someone does a WHOIS
lookup on your domain name, it appears as your personal
DNS, as opposed to the company you're reselling for. Not
really a big deal, but some webmasters do not want to
advertise the host they're reselling for, as they feel it
does not portray a professional and independent look.
Personal name servers are offered to clients whom are a
part of our (reseller program). If you're not a reseller,
please use the standard DNS settings we provided you.
There is no superior advantage to having your own name
server unless you're a reseller, and or a web designer who
is also planning on hosting the websites they build.
Setting Up Sub Domains
What is a Sub-Domain?
A sub domain is one,
which resides under your top-level domain name, but in
many ways behaves as a "totally in |
