Re: [cobalt-users] Primary, secondary, auto-update, still confused

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Patrick wrote:

> Here is my dilemma: I registered a nameserver. I want to run it as my
> "Primary," i.e., I would like to run dns on my server. I have a site
> registered with a FQDN

FQDN is an acronym.  Many of us here continue to ask for real examples
so we can test.  I no longer agree to help with DNS issues if I cannot
test; it's just not worth my time <frown>.

> on the IP I was issued and I am running a PTR record
> for the single IP number.

Why?  Did someone tell you to?

Or was it becase you could?  (Please see paragraph above before you
answer, since I won't unless I have something testable to work with.)

> My ISP is running secondary DNS. The domain
> resolves with Primary authority residing with me, and secondary nameserver
> services resolving to my ISP. This seems correct (though the primary
> upstream PTR record was not resolving to my hostname... it now is...)

What's a primary upstream PTR record?  I think you've invented a new
term <smile>.

> The issue is - if I add a sub-domain, i.e., another virtual site (with it's
> own domain name) under the same IP

To start with, that's NOT a subdomain.

> - do I need to inform my ISP of the
> change to my DNS records, or will the secondary automatically update itself
> to reflect the new sub-domain?

It's a domain.  It's NOT a subdomain.  Your ISP will automatically pick
up all subdomains of all domains he's already secondarying.  How he and
you synchronize new domains is something for you to ask your ISP, not
us.

> If I have to inform them - then I have to
> inform them every time I add a sub-domain (and pay, and hassle accordingly?)

Maybe.  I haven't seen your contract, don't know your ISP, and have no
idea of the hassle or pay level involved.

> Surely if I'm not running (a) PTR record I'm not doing Primary?

Surely??? are you asking?  If so, then the answer is one has nothing to
do with the other.

> And if I am
> - then I am Primary i.e., I do reverse mapping on my hosted domain names(s)

Your domains are your domains.  Your reverse DNS is part of the
in-addr.arpa domain.  It's not your domain.  It's got nothing to do with
your domain.  You only reverse your domains in in-addr.arpa if part of
in-addr.arpa has been delegated to you.

There, now you've done it, you've made me get more complicated <frown>.

> - i.e., the upstream servers may or may not be running DNS records
> reflecting my DNS?

What upstream servers?  Is my server (is that what you mean by an
upstream server?) holding your DNS records?  Yes, if I've asked it to,
by looking at your website or sending you email.

> The fact that my FQDN is listed as primary nameserver on
> the top level country DNS means it finally resolves to me (through other
> upstream primaries, whether or not their DNS, PTR reflect mine?)

Either you're making this more complex than it is, or your use of
entirely new vocabulary just makes it seem so.

> Surely my ISP's secondary is part of this upstream process

What's an upstream process?

> - If I am not
> running (a) PTR record then surely no names will resolve for a requested IP

Again, what does a PTR record have to do with resolving names?  Nothing
I can see.

> - unless I have informed my ISP of all changes - in which case why am I
> running 'Primary' dns?

Since PTR records have nothing to do with resolving names, or for
whatever you mean by upstream for that matter (at least I don't think
so), the "then" clause makes no sense.

> Suppose I would still be creating A records and MX
> records for each site even if I wasn't running a nameserver?

If you're not running a nameserver you can host all the A and MX records
you want but no one but you will ever see them.

> My ISP would
> run the PTR record for my primary domain - and everything else would
> resolve through A records on my machine? Or what?

Aha... a light at the end of the tunnel.  You have no idea what a PTR
record is.

Frankly if your DNS works at all, it's by some accident.  If you want
your sites to resolve you need help in DNS beyond the scope of this
list.  It's a BAD idea to just do DNS by example; every domain has
different DNS needs.

I strongly suggest you hire a DNS person to set up DNS on your RaQ or to
host DNS for you.  We host DNS for a lot of people who could do it more
cheaply themselves; they realize it's important for them that their
sites always be available, and they know how important a part DNS is of
that process.

A PTR record is used to "point" <smile> an IP# to a domain name.  It's
part of the in-addr.arpa domain.  It's got nothing to do with how your
ISP (or anyone else) knows you've got a domain at your site.  That's
done with domain "registration"

I'd strongly suggest the book "Linux DNS Server Administration"; it's
published by Sybex and should be available at Amazon.

> Perhaps all of the above has nothing to do with whether the secondary
> updates or not? i.e., it has to do with the way zone transfers are setup?
> i.e., masters verse slaves? Is there something I need to do on my machine?
> (I really don't want to be in a postition where I have to inform my ISP
> every time I create a sub-domain... if this is the case i would rather have
> somebody else do secondary... )

No matter who does secondary you'll have to let them know when you add a
domain.  We accept simple emails (to an address we give you) with the
name of the domain; that's it.  Some ISPs put code into your machine to
grab it automatically.  We've done it that way as well.

> I don't have an A record for my ISP's secondary - should I? (though I do
> have the secondary reflected in the SOA records)?

I'm not even sure what you mean.  Is your ISP's secondary in YOUR
domain?  You only want A records for domains you host.

Thought the Sun/Cobalt gui makes it hard to understand this, all the
records for a given domain are lumped together into one "zone" file. 
And you only wnat zone files for domains you host.

> >Yep, you are correct, you have to go into dns on the slave (secondary) tell it
> >to serve as secondary for the domain.  (each domain)
> >Then edit the SOA for the master (primary) adding the slave (secondary)
> 
> Each primary domain (with its own ip number) - or each 'virtual domain'?

Each domain.  Lots of domains can share the same IP#.  DNS doesn't
care.  In fact DNS doesn't even know.  A domain is a domain.

> Okay - so I am confused - if I change primary zone files (i.e., add a
> sub-domain?)

www.domain.com is a domain; it's also a subdomain of domain.com, which
is a subdomain of com.  (Which, believe it or not, is actually a
subdomain of "." but we don't have to go there <smile>.)

joe.domain.com is also a subdomain of domain.com.

smith.com is NOT a subdomain of domain.com.

So to you, what's a subdomain?

> - the secondary zone files will update?

The subdomains will.  Because they're in the same zone.

As I've said before www.new.domain is NOT a subdomain of
www.old.domain.  So you're creating a new zone-file.

Each time you create a new zone-file you have to let the slave server
now it's a slave for it.  (Now I'm getting even more complicated
<frown>.)

> Any clue would be appreciated.

I hope you can wide through my frustration and sarcasm and find
something of help.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
Linux and Cobalt/Sun/RaQ Consulting
nobaloney.net
P. O. Box 52672, Riverside, CA  92517
voice: (909) 778-9980  *  fax: (702) 548-9484