[vox-tech] zones and DNS

[ME]

p@dirac.org said:
> On Tue 02 Sep 03,  7:40 AM, ME <dugan@passwall.com> said:
>> p@dirac.org said:
>> > hi all,
>> >
>> > can someone tell me the difference between a zone and domain?
>> >
>> > i've written very basic A, MX and CNAME records a long time
>> > ago, so i'm still probably a newbie on the subject of DNS.
>> A Zone is a system for organizating information about a domain and the
services of a domain. A Zone record includes information about how a
domain should be updated, what copy of the zone record is most
>> up-to-date,
>> and specifics on services for a domain (NS, MX, CNAME, A(-name)) and in
special cases, specify priority for services (MX) when multiple servers
exist.
>> I look at it like this:
>> Zone records contain Domain Name information.
>> Domain Name information does not contain Zone records.
>> Zone records need not contain Domain Name information.
>> (localhost, root servers hints file, inaddr-arpa, etc.)
>> Depending upon how you view a domain, the entire information of a
domain
>> may actually exist across more than one zone record. (Consider the
cases
>> for rDNS and the inaddr-arpa.) Of course, some people do not view this
information as part of the domain, and some others don't even provide
reverse lookup services for their domains.
>> A really good example of how a Zone File may not be considered part of
a
>> Domain, is when ISP provide Reverse Delegation for rDNS, or provide all
DNS (forward and reverse) for a "classed" network. They may have
several
>> zone files for each domain, but may only have 1 zone file for rDNS.
Another example that is better, is the case with the "hints" file that
contains the list of "root" servers.
>> Of course, if you are talking NT Domains, then that is another story. ;-)
>> -ME
>
> let me see if i understand you correctly by rephrasing what you said.
>
> for the case of a home user who runs a domain out of his living room
that only offers basic services like www, smtp and ftp, a zone record is
an ecapsulation of all the information needed for the outside world to
access his computer sitting in the living room.  namely, the A, MX and
CNAME records.   here domain and zone records coincide.

No. You still should have (not everyone does it) a separate zone for
"rDNS" (reverse DNS lookups). This separate zone is often referred to as
the "in-addr-arpa" version/file/zone. This allows remote DNS/clients to
lookup the owner of a "class" and then consult with the class's owner what
names are set per the IP address being reverse-looked-up.

Often, this is done by the ISP, and you must arrange for them to either:
1) Serve your desired rDNS named per each IP that you own
2) follow the RFC that deals with "reverse delegation" and you perform the
work prequired to have your DNS work with the data they provide to clients
who wish to rDNS and find it passed off to you.

ISP will frequently not do step "2" unless you have a block of 8 or more
IPs (where you actually only have 5 IP that you can use as B-Cast, Net-ID,
and their router take up 3 of those 8.)

Some ISP do some clever work with giving out 4-IP blocks without a true
subnet per IP-block-owner, but multiple users effectively share a larger
(Class-C sized) subnet and subnet mask.

If you are listed (advertised) as the true owner of a block of IP, then
you will be listed as the person authoritative for reverse lookup, but
this is usually something for bigger businesses, or unis.

> but for the more general case, a domain like ibm.com may be broken down
into different zones.  perhaps software.ibm.com and hardware.ibm.com. a
zone record points to the different domain records, and it's these
domain records that contain the A, MX and CNAME records.

Take the simplest case. Technically, a "dot-com" domain is a domain of the
".com" domain (a TLD.)

Yes, ibm.com could be one zone and research.ibm.com could be another zone,
but then the specifics of ibm.com in its zone would need to account for
the subdomain. This subdomain could itself have other NS and MX records
for other servers and even have different timeouts for caching of data
handed out.

> is this more or less accurate?

For the most part, you are on the right track, but do not forget about the
other zones. Considering BIND:
1 domain = 1 Zone file for your domain
+          1 Zone file for inaddr-arpa and rDNS (or zero if your ISP will
add an entry for your IP in their DNS.)
+          1 Zone for localhost
+          1 Zone for rDNS of 127.0.0.1 (inaddr-arpa for localhost)
+          1 Zone if you are going to resolve full lookups for other
domains you may want to have your DNS resolve
--------------------
           5 Zones

By breaking things into zones, you have a more modular config.
"Zone Transfers" are also much easier between you and your backup DNS.

(I have 2 backup DNS in addition to mine. One in San Diego, and one in
Denmark.)

It is a good idea to have your backup MX and backup DNS be someone not
using your ISP. Utilizing substantially different geographic locations
also helps to insulate you against disasters.

(Why? If you ISP goes down, and mail is delayed, if your backup MX is on
your ISP, you might start to lose mail if/when your domains can't be
resolved (no available DNS) and no avlable MX can accept deliver for later
relay.)


-ME