homepage Welcome to WebmasterWorld Guest from 54.197.183.230
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Domain Names
Forum Library, Charter, Moderators: buckworks & webwork

Domain Names Forum

    
Request for members to post up tutorials on DNS set up & other issues
Please help build an overview thread of mini-tutorials on DNS issues
Webwork

WebmasterWorld Administrator webwork us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3311 posted 9:27 pm on Nov 30, 2005 (gmt 0)

Have you ever set up or do you admin a domain name server? Linux/Apache or Windows or other?

I'd appreciate your contribution to a general "how to" description of DNS set-up, what the issues are in running a DNS, what safety measures should be taken, general installation advice, planning advice, suggestions of where to get further specific info on DNS, good books, etc.

Wide ranging. All contributions welcome. Reference level URL drops welcome.

Thanks.

 

Leosghost



 
Msg#: 3311 posted 9:59 pm on Nov 30, 2005 (gmt 0)

" Reference level URL drops welcome."
you sure ..?
Zone edit just about wrote the book ( albiet basic )for newbies in their site ..which will make for a very short thread ..if anyone posts a link ;)

(I actually composed this in sticky and then thought why not ..it deserves a wider discussion.. like J says ..)

I love their zone edit style .."read the instructions" ..if we think you didn't.. we wont talk to ya ..maybe ..attitude ..

Was gonna sticky this to webwork ..decided to post ..

so what does anyone think about DNS..?

( apart from "Don't No Squat" )

yes I do know the acronym is lousy ..but it does sum up most peoples attitude to this ....

****
frightens the **** out of everyone ..fastest way to kill a site ..apart from "500 suicides" in your htaccess ..

isnt that scary ..but .. ~;)

jmccormac

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



 
Msg#: 3311 posted 11:09 pm on Nov 30, 2005 (gmt 0)

A handy diagnostic site:

[dnsreport.com...]

It can tell you if your domain zone record is set up properly.

The majority of sites are on shared hosting and domain configuration is done through a a web interface. Therefore the user never really gets to see the programs and configuration files. Setting up a DNS from scratch is a bit more complex but there is a lot of literature on the web about how to do it.

One of the main nameserver programs is BIND. The software (source code that has to be compiled for the Operating System. Though a Windows binary is available) is available from:

[isc.org...]

The documentation and FAQs are also on this site. There are smaller DNS programs as well. But I really don't think that people should run their own DNSes unless they know how to set up a secure server and configure and compile software.

Regards...jmcc

Robert Charlton

WebmasterWorld Administrator robert_charlton us a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



 
Msg#: 3311 posted 9:07 am on Dec 1, 2005 (gmt 0)

Webwork - A noble project. I'd like to see someone nail all the nuances, because there are a lot of them. Here's an oldie but goodie...

Between Registrar and Host who does what?
[webmasterworld.com...]

On the temporary Search Engine World forum that Brett had going when WebmasterWorld was down, there was an excellent thread developing about backup DNS, which belongs here too, if you can retrieve it from whatever limbo it's now in.

Webwork

WebmasterWorld Administrator webwork us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3311 posted 5:11 pm on Dec 1, 2005 (gmt 0)

Nice thread Name Servers Best Practices [searchengineworld.com] kindly brought to my attention by rogerd.

Thanks.

jamesa

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3311 posted 9:23 am on Dec 3, 2005 (gmt 0)

Basics

DNS = Domain Name System (or Domain Name Service)

System by which we map domain names to physical machines on the internet. Machines find each other by IP addresses... much like how the Postal service can send you a letter knowing your physical street address. If you know the IP address of webmasterworld (currently 72.3.232.139) you can go to [72.3.232.139...] to get here. But on the net we like vanity names, for example webmasterworld.com. We'd rather type [webmasterworld.com...] ... easier to remember, and we don't need to keep track of IP address changes in case Brett moves the server. Analogy is how an 800 number can follow you even if your physical address changes.

When you enter [webmasterworld.com...] in your browser a couple things happen behind the scenes. First and foremost for this discussion is the browser needs to find out where in the world webmasterworld.com is... in other words, what's the IP address? Only after it gets the IP address can it send it's message: "hello WebmasterWorld, please fetch me your homepage." DNS - the domain name system - is the mechanism that does this - keeps track of domains and their IP addresses. Simple as that. webmasterworld->72.3.232.139, bbc.co.uk->212.58.224.131, slashdot.org->66.35.250.150, etc.

Undertsanding this is 90% of it. The rest is just syntax.

Nameservers

Who/what keeps track of this information? Nameservers. I'll leave out SOA (Start of Authority) and that type of stuff for bevities sake. SOA is just the mechanism of knowing which name servers to query to find that info. The executive summary is that to find an IP address, your web client usually needs to "hunt" for this info. It asks one name server "hey, what's the IP of video.search.yahoo.com?" The nameserver says "I dunno, but check here ___ they know about all the dot coms." Then it asks that name server "hey I'm looking for video.search.yahoo.com, can you help?" Response: "no, but I do know where to find yahoo.com, check their nameservers here ___". Etc.

Caching

Once your client (web browser, email program, etc) finds an IP it then knows where to send it's communications to. Now chances are you are going to need that IP again withing a relatively short period of time... to view the second page of the site, download images, visit again a few minutes later, etc. Rather than hunt for the IP time and time again, it saves the IP for future use. Once it discovers the IP, it doesn't need to discover it again a few seconds later, so it saves it. Saving the IP is called caching. For future requests the client (browser) simply checks its own cache rather than going out hunting again. Efficient, right?

Problem is IPs can change. So those caches need to be updated from time to time. Webmasterworld.com in fact had an IP change last month. If our caches were never updated, we'd still be hitting a server that doesn't exist anymore. So the caches need to be refreshed from time to time.

Time To Live (TTL)

Someone had a brilliant idea many, many moons ago: why not let the nameservers themselves detremine how long to cache the info for? So now clients not only request IP addresses from nameservers, but also ask "hey, how long should we cache this for?" Or in DNS lingo: "What's you TTL (time to live)?" Name server responds: "wait 24 hours before checking again, please, we're trying to conserve bandwidth" or "we're planning a server move real soon, so please check every 5 minutes."

Some Syntax

Here's what a typical zone file might look like. A zone file is where your nameserver stores your DNS settings.

somedomain.com. IN SOA ns1.somenameserver.net. dnsmaster.somedomain.com. (
1088331911 ;Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
21600 ) ; Minimum TTL

somedomain.com. IN MX 10 mail.somedomain.com.
somedomain.com. IN NS ns2.somenameserver.net.
somedomain.com. IN NS ns1.somenameserver.net.
somedomain.com. IN A 10.2.3.4
www.somedomain.com. IN A 10.2.3.4
mail.somedomain.com. IN A 10.2.3.5

The first entry, which wraps several lines for readability, has some basic high level info. Note that "dnsmaster.somedomain.com" is an email address, translates to dnsmaster@somedomain.com.

Serial is a number that increments anytime there is a change to the record.

Refresh, Retry and Expire contains info for "slave" nameservers. If you run multiple nameservers, instead of configuring each one manually, you can configure the "master" and the slaves will just copy it. These setting tell the slaves how often in seconds to refresh the data among other things.

Minimum TTL was described above. The value is in seconds. Clients use the value of this entry to determine how long to keep their caches.

somedomain.com. IN MX 10 mail.somedomain.com.

"IN" just means "in", like "inside". IOW needs to be there but has no meaning. "MX" means "Mail Exchange". This line says "any email for somedomain.com should be sent to our mail server at mail.somedomain.com server" (which could be a separate server at a different IP address). The "10" is a relative priority. You can have multiple MX records... meaning you can have more than one mail server set up. If one is unreachable, the second will be tried, etc. The order it tries them is based on priority. Note no IP addresses mentioned yet... just sends one domain to another. This is a convenience: you can email sales@somedomain.com instead of having to know the mail server and using sales@mail.somedomain.com.

somedomain.com. IN NS ns2.somenameserver.net.
somedomain.com. IN NS ns1.somenameserver.net.

These are NS records. Lists the nameservers for the domain. Again no IPs. That's next...

somedomain.com. IN A 10.2.3.4
www.somedomain.com. IN A 10.2.3.4
mail.somedomain.com. IN A 10.2.3.5

These are A records. Give you the IP addresses for every domain and subdomain you want to define. somedomain.com and www.somedomain.com point to 10.2.3.4. mail.somedomain.com points to 10.2.3.5.

Examples:
- if you send an email to sales@somedomain.com: Your email client first looks for the MX record to find the mail server mail.somedomain.com. Then it looks for the A record for mail.somedomain.com to get the IP of 10.2.3.5.

- if you request a webpage from somedomain.com: Your browser looks for the A record for somedomain.com and gets the IP 10.2.3.4.

- if you request a webpage from www.somedomain.com (including the www this time): Your browser looks for the A record for www.somedomain.com and also gets the IP 10.2.3.4.

- if you request a webpage from secure.somedomain.com: Will fail since there is no entry for secure.somedomain.com. To make it work you can add an A record like so (and even point it to a different server):

secure.somedomain.com. IN A 10.2.3.7

That's the zone file in a nutshell. Any GUI you use to edit your DNS is ultimately editing this zone file.

Final note on HTTP/1.0 vs HTTP/1.1

This is a digression, but some people may be scratching their heads WRT shared IPs. This whole discussion is about finding IPs... you need an IP to find the server a site is hosted on. Well what if there are many sites sharing an IP on that server?

The original HTTP protocol, version 1.0, could only deal with IPs. Each domain needed a unique IP, period. The protocol evolved to version 1.1 that allowed for shared IPs. Examples:

Version 1.0 (now long gone):
1. Browser finds IP for somedomain.com
2. Browser connects to IP and says " please send me index.html" assuming somedomain.com is the only site hosted there.
3. Server sends index.html

Version 1.1:
1. Browser finds IP for somedomain.com
2. Browser connects to IP and says " please send me index.html for somedomain.com" making no assumptions.
3. Server sends index.html for somedomain.com

jamesa

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3311 posted 10:07 am on Dec 3, 2005 (gmt 0)

One more and I'll stop hogging the thread... :)

Moving Servers

You're moving from one host to another. Want a smoother transition?

Caching Pt.2:
If you read the above you know that nameserver information gets cached. It's not just your computer that caches information, but other nameservers as well. Your ISP (DSL/Cable/Dialup provider), for example, will keep their own caches. If your neighbor visited somedomain.com a few minutes ago, you need to look no farther than your ISPs cache to get somedomain.com's IP, making your hunt much shorter and faster. Also lightens the load on somedomains.com's nameserver (and other nameservers) by spreading that load throughout the net.

So when you move your site, there's quite a lot of caches throughout the net that need to be updated. Example:

Say your time to live is 24 hours:
- Person one visits your site at 1pm today. Nameserver info is cached until 1pm tomorrow.
- Person two visits your site at 2pm today. Their cache lasts until 2pm tomorrow (24 hours later for them).

If you make an IP change to your site now, person one won't see it until 1pm tomorrow, person two won't see it on 2pm tomorrow, etc.

This waiting game is called propagation and it's evil. During the propagation period some people will hit the old IP while others will see the new one. Knowing this, a smart thing to do is too keep your old server alive during this propagation period so that regardless of which IP they hit, they will still see your site.

The reason why I say it's evil is because of emails, logs and databases. During the propagation period, some email gets delivered to the old server, some to the new. Log files are split between the servers. And database writes are split (big problem for many sites, especially forums, etc. Live databases are a bit more complex, I'll save that for another time.).

So the smarter thing to do is to "pre-propagate" your domain (my own term, not an official name so don't expect people to know what you're saying if you use it ;). Here's what you do assuming your TTL is 24 hours:

1. 24 hours prior to your move change your TTL to something small, like 5 minutes or 60 seconds. Let's say 60 seconds.

2. After 24 hours all the caches will have rechecked your nameserver and discovered the lower TTL. From this point forward all the caches are rechecking every 60 seconds.

3. Point your domain to the new IP (new server). Now your propagation period is only 60 seconds. 60 seconds later eveyone is seeing the new server.

4. Change the TTL back to something larger.

Why not leave the TTL low? Setting TTL is a balance between flexibility and cost. Keeping the TTL low so you can move quickly keeps you flexible. But a low TTL will mean more hits to your nameserver thus consuming more resources.

py9jmas

10+ Year Member



 
Msg#: 3311 posted 10:22 am on Dec 3, 2005 (gmt 0)

"IN" just means "in", like "inside". IOW needs to be there but has no meaning.

Actually, IN stands for Internet. RFC 1035 lists all of the allowed classes:
IN 1 the Internet
CS 2 the CSNET class (obsolete - used only for examples in some obsolete RFCs)
CH 3 the CHAOS class
HS 4 the Hesiod class

The CHAOS class sometimes comes up as it's used to get the version of a BIND nameserver:
host -c chaos -t txt version.bind ns.rackspace.com
Using domain server:
Name: ns.rackspace.com
Addresses: 69.20.95.4

VERSION.BIND CHAOS descriptive text "8.3.3-REL-NOESW"

Webwork

WebmasterWorld Administrator webwork us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3311 posted 3:12 pm on Dec 3, 2005 (gmt 0)

Brilliant! Everyone one of you! Thank-you x10.

I invite anyone else who has insight or experience to post up. This will make a very helpful library reference thread.

Lurkers - don't be shy. It all helps.

stever

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3311 posted 3:20 pm on Dec 3, 2005 (gmt 0)

As requested:

DNSSleuth (Good diagnostics):
[atrey.karlin.mff.cuni.cz...]

DNSStuff (Use this one the most):
[dnsstuff.com...]

RScott has good basics:
[rscott.org...]

Good glossary:
[menandmice.com...]

Ohio State
[cse.ohio-state.edu...]

If you are interested in this stuff, then this is an offline goodie (we used it on my network admin course a few years ago)
[oreilly.com...]

claus

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3311 posted 3:39 am on Dec 12, 2005 (gmt 0)

Just a comment on a minor -- yet important -- issue from jamesa's really good post above:

somedomain.com. IN A 10.2.3.4
www.somedomain.com. IN A 10.2.3.4
mail.somedomain.com. IN A 10.2.3.5

These are A records, [added, claus: meaning "Address" records]. Give you the IP addresses for every domain and subdomain you want to define. somedomain.com and www.somedomain.com point to 10.2.3.4. mail.somedomain.com points to 10.2.3.5.

Please look very carefully at the two first lines. Do you see anything special about them? Hint: Two different domains pointing at the same IP address.

This, ladies and gentlemen, is the root of all evil.

Don't get me wrong. In a DNS context it might be perfectly okay to do the above (I wouldn't do it, but honestly I don't know).

But, here we deal -- among other things -- with search engines.

Did you ever hear the term "The canonical"? In search engine lingo (specifically Google lingo, I believe), that's a fancy word for "the real host name" for your site. Search engines are really interested in knowing which host/domain is the real one for your web site, for numerous reasons - and making them confused about this can lead to all kinds of sideeffects. Undesirable ones, mainly.

Now, consider the case above again. You have two different domains pointing at one IP. That is, two A records. Ie. two domains that both should be considered canonical for the content on that IP!

See?

So, with that setup you effectively tell Google-bot, Yahoo-bot, MSN-bot, and all the other user-agents out there that you have two websites (domains) sharing the same content, and that both are valid.

Introducing C NAME records

Now, the DNS system has a construct called a "C NAME" record. Just like an "A" record it will tell whoever asks that one particular domain points at something else. However, this one is special.

A CNAME record might look something like this

www.example.com IN CNAME example.com.

Now, here's the funny part. Guess what "C NAME" means: "The Canonical Name (CNAME) resource record". Yes, that's it. Really.

What it does is to define an alias to your right (canonical) host name, so that you can have another host (domain) point at your web content, but still not confuse anyone as to which host/domain is the proper one.

In the case above, "www ... " is an alias to "example.com", the latter being the official host name. The former is just an alias - it points to the exact same content, and it will show in the address line of the browser, but it is not the official domain. You could also have, eg, a vanity domain as a C NAME record:

something-else.com IN CNAME example.com.

The rightmost part is your official host name, ie. your "A" record. There should be only one of those (IMHO, but I don't make the rules).

Oh, and even if you have the right implementation, you would probably still need a 301 redirect from www to non-www just for the search engines.

---
(And, if you insist on the misconception that the subdomain "www" should be your official host, then please use "www.example.com" as your single A record and use your topmost domain as a C NAME alias to this subordinate domain. It makes no sense to me, but people are different)

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Domain Names
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved