Re: [cobalt-users] DNS - Basic Concepts and Instructions

["Zeffie" <cobalt-proj@xxxxxxxx>]

> There are so many questions on DNS--and so many of them are due to basic
> ignorance--that I've decided to create a basic set of definitions and
> instructions that will be useful to anyone (and, of course, users of
Cobalt
> products too).
>
> Please read, and comment on any ways you see to improve this. Also, for
the
> sake of my own education, if someone knows how to put this into a HOWTO
> format I'd appreciate hearing about it. Most of my afternoon has now gone
> into this, so please at least help me make it good, OK? Feedback from
> beginners who actually apply this and from experts who correct my errors
> are especially welcome.
>
> DNS - Beginner HOWTO
> ====================
>
> 1. Table of Contents
>
>     1. Table of Contents
>     2. Intro
>        2.1 Copyright and Disclaimer
>        2.2 Assumptions
>     3. Concepts and Definitions
>        3.1 Server vs. Zone
>        3.2 Master/Slave vs. Primary/Secondary
>        3.3 Other Types of Zones
>        3.4 Registered Nameservers
>        3.5 FQDN - Fully-Qualified Domain Name
>        3.6 Individual Records
>           3.6.1 NS Records
>           3.6.2 A Records
>           3.6.3 MX Records
>           3.6.4 CNAME Records
>           3.6.5 Other Record Types
>     4. Setting It Up
>        4.1 Assumptions
>        4.2 Scenarios
>           4.2.1 You're A Large Network
>           4.2.2 Two Independent, Fault-Tolerant Upstreams
>           4.2.3 Swapping Slave DNS
>           4.2.4 Two Machines
>           4.2.5 One Machine
>        4.3 My Typical Zone Records
>        4.4 The Rest Of The Zone File
>     5. Security
>     6. Conclusion
>
> 2. Intro
>
> 2.1 Copyright and Disclaimer
>
> This text is (c) copyright Rodolfo J. Paiz 2001. You may redistribute it
in
> any form, written or electronic, and make any alterations you desire so
> long as: (1) such alterations are noted and delineated in the text to
> clearly communicate to the reader who wrote what text; (2) this copyright
> notice is included without alteration and the entire text you redistribute
> complies with the limitations and use restrictions of this copyright; and
> (3) you do not collect money or charge for this text in any way.
>
> Of course, this text represents concepts which are correct, to the best of
> my knowledge. However, any use made of the concepts contained in this text
> by any person is their own responsibility as are the consequences of their
> actions. This text is offered "as is," without any warranty of any sort,
> anywhere on Earth or for any reason, without even any implied warranties
of
> suitability for any purpose or merchantability.
>
> You're on your own... if you muck it up, don't blame me.
>
> 2.2 Assumptions
>
> I believe that the concepts contained herein are applicable to any DNS
> (Domain Name Service) server running on the Internet today, regardless of
> the particular software, server, or interface you use to implement them.
> However, it should be clear that I only have experience using BIND
> software, version 8, and that there may be variances of which I am not
> aware. Just one more reason to be cautious.


maybe just change this to say bind version 8.2.3 on cobalt linux....

>
> 3. Concepts and Definitions
>
> 3.1 Server vs. Zone

-10
just a bad title/section heading i think.... and you need to define "zone"


> One of the most widespread misconceptions that gets people in trouble
comes
> directly from the terms "primary nameserver," "secondary nameserver,"
> master nameserver," and "slave nameserver." Please note that these terms
> are used for convenience, and actually should be replaced with the
> much-more-accurate but much-less-convenient phrases below:
>
> * Primary Nameserver: Nameserver acting in a primary role for this zone
> * Secondary Nameserver: Nameserver acting in a secondary role for this
zone
>
> * Master Nameserver: Nameserver allowed to answer with authority for this
> zone, in which all zone records have been entered
> * Slave Nameserver: Nameserver allowed to answer with authority for this
> zone, in which no zone records have been entered but which asks the master
> nameserver for information instead
>
> You can quickly see that the most important word in all phrases is the
> "zone". One nameserver can have many roles... mine currently plays a
master
> role for 35 domains and a slave role for another 50. Only one nameserver
> program should be running for each machine, generally speaking; and since
> this is a primer for beginners, any situations where this does not apply
> are automatically outside the scope of the text and can safely be ignored.
>
> 3.2 Master/Slave vs. Primary/Secondary
>
> Contrary to popular belief (as well as popular usage of the terms) a
master
> server is *not* the same as a primary server, just as a slave is *not* the
> same as a secondary. For Cobalt users, note that the Cobalt GUI in most
> cases does assume master=primary and slave=secondary, which is convenient
> but wrong. Here are my definitions:
>
> Master Zone: This is the zone where you enter all records (NS, A, MX,
etc.)
> individually. The server with the master zone will never ask anyone else
> for help; it will use only the information it contains to answer queries.
> When asked, it will answer authoritatively (big words for "I know this is

(big word)*

> the right answer so go ahead and use it with confidence.") Also, the
server
> with the master zone will share this zone information with slave servers
> through a transaction called a "zone transfer."
>
> Slave Zone: This zone is very easy to set up. Create a slave zone for a
> domain, tell it which nameserver holds the master zone, and you're done. A
> slave zone gets all its information from the master zone, and updates its
> information either: (1) if a certain period of time goes by; or (2) if it
> receives a NOTIFY message from the server with the master zone informing
it
> that the zone info has changed.
>
> Primary Server: In theory, the server which will receive all queries. In
> practice, not that important a designation. The primary nameserver really
> means the one that is listed first in the whois records for your domain
> (i.e. you registered it as the primary), and it's the one which *you hope*
> will receive and service all DNS queries. But a DNS client (called a
> "resolver") does not care which the primary is... if possible, it will ask
> the DNS server which provides the fastest response. So if my primary DNS
is
> in Australia, and my secondary DNS is being done by America Online in the
> United States, anyone inside the AOL network who wants to see my sites is
> going to ask the nameserver closest to them (on the network, not in
> geography) and thus they are going to ask the AOL server.
>
> Secondary Server: A server not listed first in the whois records. Also a
> server which you hope will not receive too many queries. But a server
which
> should work properly, since some people *will* ask it for information, and
> because it will need to be fully up-to-date if the others go down. In
> reality, just another nameserver that holds your zone.
>

this part is just way to wordy for me....   Remember you taking to
newbies....  Don't double there problem by adding in extra gunk.....
-0  balances with above kinda....


> 3.3 Other Types of Zones
>
> Master and slave zones are not the only types of zones. However, they are
> the most frequently used types of zones and they are the only ones I have
> ever used. So clearly, in order to have basic DNS functionality you do not
> need to know anything about them and no information will be included in
> this text about them until I (a) learn about them or (b) someone teaches
me
> about them.


or you could drop the whole section....
-5  chatter

>
> 3.4 Registered Nameservers
>
> When you register your domain, you give the registrar the names and IP
> addresses of TWO OR MORE nameservers which are authoritative for your
zone.
> (This means that you have configured one of them as the master and the
rest
> as slaves.) These--and only these--servers are those which the rest of the
> world will look for when trying to find your domain; this is why it is
> important to work with a good registrar (not just the cheapest one) and to
> make sure that this information is always accurate.
>
> 3.5 FQDN - Fully-Qualified Domain Names
>
> Domain names and host names are read "inside-out", which means that each
> component of the name is "inside" the next one. The components of a name
> are separated by dots, where usually the text to the left of the first dot
> is the hostname (name of the machine). The rest of the FQDN is the domain
> name (name of the network). An example of a FQDN:
>
> george . jetson . com .
>

welll yes and no....  this is more of a fully qualified hostname amd you
stated the section making me think I was going to find out what a FQDN is
and not about a portion of the entry into the zone file....
-5


> This means that:
>
> www is the hostname, which is inside
> jetson, which is a second-level domain name because it is inside
> com, which is a top-level domain name, which is inside
> . which represents the root-servers
>
> Please notice that dot at the end! It denotes the root servers... and as
> with trees, everything comes from the root. DNS resolvers (clients) who
> don't know anything about a particular domain follow this sequence to
> resolve a name:
>
> * Ask a root-server who answers for the "com" TLD (top-level domain).
> * Ask a COM nameserver who answers for the "jetson" domain.
> * Ask a JETSON.COM nameserver who the GEORGE host is.
>
> BIND (and probably other DNS programs) assumes that a name is a "local"
> name if it does not end without a dot, and it adds the entire domain name
> to it. It will only treat a name as "complete" or "fully-qualified" if it
> is (duh) a Fully-Qualified Domain Name meaning it has a dot at the end.
> Concretely, if you create a record for "george" in the "jetson.com"
domain,
> BIND will convert it to "george.jetson.com." If you should write
> "george.jetson.com." in the zonefile, BIND will see the final dot and
leave
> the thing alone. All well and good; your only problem will come if you
> write "george.jetson.com" (no dot), because BIND will then convert that to
> "george.jetson.com.jetson.com." (with dot). And that's almost certainly
not
> what you want.

wordy... again....  and quite more then a newbie needs to know



>
> 3.6 Individual Records
>
> A zone will contain several individual records. Remember, you will only
> directly add or edit individual records in a master zone.
>

if this isn't it should be redundant by now....
-1 (placement in doc)

> 3.6.1 NS Records
>
> NS records point to FQDN's. You should have one NS record for each
> registered nameserver.
>
> Example:
>
> jetson.com.   IN   NS   ns1.jetson.com.
> jetson.com.   IN   NS   ns2.jetson.com.
>
> 3.6.2 A Records
>
> A records point a name to an IP address. They cannot point to a directory
> or file; only an IP address. You can have as many A records pointing to
one
> IP address as you want. You can also use simple hostnames and have BIND
> convert them to FQDN's or you can use FQDN's in your zone.
>
> Example:
>
> george              IN   A   111.111.111.111
> www                 IN   A   111.111.111.111
> ftp                 IN   A   111.111.111.111
>
> astro.jetson.com.   IN   A   111.111.111.112
> mail.jetson.com.    IN   A   111.111.111.112
>
> Notice that the machine with the 111.111.111.112 will get traffic to both
> the "mail" hostname and the "astro" hostname, and that the "george"
machine
> is also the home of the website and FTP directories.
>

yes but this is getting a bit misleading....  your telling a newbie to have
an address record for ftp, mail, www and thats not really necessary....
-5 (Judy Jetson is lost)


> 3.6.3 MX Records
>
> MX records point to FQDN's. They do *not* point to IP addresses. They also
> have a priority field, which shows how much it "costs" to deliver mail to
> that host. Since it is a cost, the one with the lowest cost gets priority;
> and since it's your zone, the numbers can be anything you want. Usually
> multiples of 10 are chosen for simple convenience.
>
> Example:
>
> domain.com.   IN   MX   10   mail.jetson.com.
>
> 3.6.4 CNAME Records
>
> CNAME records are aliases, and point to A records. I'm sure there are some
> uses to them, but I also happen to know there are times when CNAMEs will
> bite you hard. In particular, MX records hate being pointed to CNAMEs;
they
> want A records only. So if you point your MX to a CNAME, your mail will
not
> work.
>
> In practice, since I can use however many A records I want, I simply use
> only A records and do not use any CNAMEs at all. Again, there may be some
> cases where they're great and wonderful, but this is a beginner document.
> Any who care are advised to buy a good book on DNS, but for now...


>
> Forget CNAMEs. They are evil.
>

Sorry but I disagree
-5 (cname problem not explained)


> 3.6.5 Other Record Types
>
> There are several other types of records, including TXT records and
others.
> They are used to provide more information, but since I live in fear of
> hackers I provide as little information as I can. A possible exception
> might be to provide an "abuse@xxxxxxxxxx" email address, but then again
> abuse, info, postmaster, and webmaster are addresses that should work for
> every domain anyway. So these other types of records are not necessary to
> the beginner. Read a book, then tell me about them.
>

-5
then skip this section and that text file is very important if you want to
maintain your system,,,,  I suggest you stick to a gui guide and stay away
from editing files.....


Well I'm going to stop here and just take off another 10 points....  The
subject was DNS- Basic Concepts and you have gotten much deeper....
I think elroy might be able to figure it out but I'm not sure someone at
cogswell cogs would be able too...


I'm going to leave it at that.... that's 46 off at this point....  but I am
grading on a curve now and that works out to 87%  a b+ :)

Zeffie