UNIX for Dummies Questions & Answers

Hi guys,

I had Cpanel VPS hosting and switched to non managed VPS hosting.
My nameservers are configured as follows
ns1.mobz.ca 69.175.76.110
ns2.mobz.ca 69.175.76.111
Before switching my domain worked perfectly. Like webprofessionalsconnect.com with those settings worked. With new server and fresh CentOS installation I need to do manually everything.

I don't have any idea from where to start and what to search. Can you please advise me what to do and give some directions?

Thanks

Are you saying that you have a new VPS and DNS isn't working on it? If so, the first thing to do is to check that you can connect to the DNS servers you wish to use:

Code:

dig www.google.com @69.175.76.110
dig www.google.com @69.175.76.111

(If you don't have dig, install the bind-utils package and try again)

If that works, but ping Google fails to resolve the hostname, check the following two files:
/etc/resolv.conf
Make sure it contains:

Code:

nameserver 69.175.76.110
nameserver 69.175.76.111

/etc/nsswitch.conf
Make sure it contains:

Code:

hosts:      files dns

Thanks,

My problem is that my site mydomain.com is not accessible. I don't know from where to start and how to solve that. I want to do it myself and understand how that stuff works.

Thanks again

---------- Post updated 07-28-14 at 10:17 AM ---------- Previous update was 07-27-14 at 08:52 PM ----------

Can you also recommend some Unix book to read which is purposed for web developers? I want to be able to do basic things like dns configuration, etc.

Thanks

OK, a little introduction to DNS and name resolving is in order. Here is


The Most Incomplete Introduction To Name Resolution


(A) The /etc/hosts file
It is easy to see that a name is easier to remember than a number. Most (i dare say: all) people think "Johnson" and look the telephone number up for "Mr. Johnson, Eric" instead of remembering "555-1234" and looking that up to find some "Mr. Johnson". IP names work the same way: they attach a name to a certain IP-address so that it is easier to deal with - for the humans!

Code:

192.168.1.1       myfirstserver
192.168.1.2       mysecondserver
192.168.1.100     myclient1
192.168.1.101     myclient2
192.168.1.102     myclient3

Notice that in fact - as long as there is a "name resolution" in place - there is absolutely no difference between the name and the IP-address it points to: if an IP address is expected (by a program, a system call, ...) and a name is given then a translation routine kicks in, delivering the IP-address for the name or vice versa. This translation routine (in fact it is a system function, "gethostbyname()") does what is called name resolution and there is a forward name resolution - getting the address from the name - and a backwards name resolution - getting a name from the address.

Above you see a simple table with numbers and according names. This file is stored in /etc/hosts on every UNIX/Linux system and it provides the most basic form of name resolution. Historically, a very big file like this with all the hosts of the - back-then - "internet" (called ARPANET at this time) was distributed daily among all these hosts.


(B) The DNS system
It is easy to see that maintaining such a file and distributing it gets tedious as the number of hosts grows. Estimate, how many hosts there are in the internet today and it is not a difficult conclusion that distributing this list among all the hosts consistently is not feasible at all. This is why another system was created: a distributed database, called DNS ("Domain Name Service").

DNS works basically like this: hosts are organized in "domains", which are hierarchical, like a file system. Every domain can contain hosts ("files") and subdomains ("subdirectories"), which themselves consist of more hosts and maybe more subdomains. For every domain (and, until defined otherwise, all of its subdomains) there is a domain master ("Primary DNS Server") and optionally one or more deputies ("Secondary DNS Servers"). Subdomain names are separated from each other with a dot ("."), which works like a forward slash in directory structures:

Code:

hostname.subsubdomain[. ...].subdomain.domain

For example: the host "www.google.com" is named "www" and part of the domain "google.com", which itself is part of the domain "com".

The authority over every domain can be delegated by the domain authority "above". There are several "root domains" (".com", ".net", ".edu", ..., but also one for each nation, like ".at" for Austria, ".fr" for France, ".ch" for Suisse, etc.) which were initially registered by the root authority of the DNS system, the ICANN ("Internet Corporation for Assigned Names and Numbers") and the "InterNIC" respectively. Within these domains one can register some sub-domain, which these authorities will grant.

For example: you want to register "foobar" in ".edu". You approach the authority for ".edu" and get the domain "foobar.edu" granted. Now you appoint a name server for this domain (say: "ns1.foobar.edu") and on this nameserver you can create hostnames and subdomains. You could create "myserver.foobar.edu" and "myclient.foobar.edu", but also the domain "subdomain.foobar.edu" and the host "anotherhost.subdomain.foobar.edu", etc..

(C) The name resolution process
Now, how is name resolution done with this system? Suppose we are on the host "foo.bar.com" and want to know the IP address of "host.domain.net". Now, our host "foo" is part of the domain "bar.com" and this domain has a name server knowing its own local hostnames, "foo.bar.com" among them. It is natural to ask it.

Alas, it won't know the answer. But it has a friend: its buddy, the name server of ".com", knows a lot more than itself, so it asks this knowledgeable machine. What a pity, this one doesn't know it either, but as it searches in its database it finds that for all issues ".net" there is a buddy of it appointed. It asks this system, the name server of ".net", which doesn't know the information itself either, but it knows who to ask: the name server of "domain.net", which it knows from many most enjoyable network connections. Finally, the request hits information eldorado: the name server of "domain.net" in fact knows who "host.domain.net" is and passes this to its buddy ".net"-NS, which passes it to ".com"-NS, which passes it "bar.com"-NS, which finally answers the request.

(D) Further Naming
I won't spare you the gory details: there are even more naming services than these two, host files and DNS, even though these are by far the most common ones. There is NIS (Network Information System) also know as "YP" (Yellow Pages, after the telephone directory) and there is its successor "NISPlus" and probably some other, more obscure, services. They all have in common that they translate IP addresses into names and vice versa. Many of them have additional capabilities, but these are rarely (if ever) used.

(E) Name Resolution for the client
I have described above how complicated the name resolution process is. It must be awfully complicated therefore to configure one (or even several) on your system, yes?

In fact: no. The process is complicated, but it is relatively easy to configure the client part: in fact all the software only uses the system calls i mentioned above, gethostbyaddr() and gethostbyname() and there is a systemwide configuration as to where from these functions get their information. The file is called /etc/netsvc.conf (in some UNIXes), /etc/nsswitch.conf (in most other UNIXes, including Linux) or /etc/netconfig (in NCR Unix, if i remember correctly).

Basically it just states which source (hostfiles, DNS, NIS, ...) to ask first and which information should take precendence. If you have a /etc/hosts file, would you like to override its entries the DNS information or do you want it the other way round? This is what such a file could look like:

Code:

# example /etc/netsvc.conf file
hosts = local, bind4

This is from an AIX system and means: ask the local /etc/hosts file first and only if you do not find it there ask the DNS server for IPv4-addresses. (IPv6-Addresses will only be resolved with local files.)

(Btw: you will run across the name "BIND" for DNS sometimes: it means "Berkeley Internet Name Domain" and is the de facto standard name server software.)

After having stated by which means names should be resolved and in which order these means should be perused the DNS also has to be configured somehow. This is donw in the filr /etc/resolv.conf. A typical file would look like this:

Code:

# example /etc/resolv.conf file from an AIX system
options attempts:1
options timeout:2
options rotate

nameserver      10.1.1.1
nameserver      10.2.2.2
domain  my.domain.net

The "options"-lines say every name server list should be asked only once (if it doesn't respond switch over to the next immediately) and the timeout is 2 seconds. Also, for each request the other server should be used so that the load is levelled. The "nameserver"-lines are self-explanatory and the "domain"-line tells the system which domain it is in itself.

Notice that these options are good for a local network, not the internet. In the internet you would want longer timeouts because servers might not answer immediately.

So far my (very short and incomplete) introduction to name resolution. I hope this helps.

bakunin

Thanks bakunin. Yesterday I manage to configure name servers.

screenprintr, I took a VPS hosting and had to switch to non-cpanel version which is completely on me. I need to install phalconphp which is not possible with cpanel. I think 39$ a month for unmanaged hosting feels like a little bit expensive.