[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnudip2-general
Subject:    Re: [GnuDIP] Glue Record / SOA Record, Master and Slave Servers
From:       Creighton MacDonnell <creighton () macdonnell ! ca>
Date:       2002-05-31 19:21:55
[Download RAW message or body]

Christian Brandt wrote:
> 
> I had GnuDIP up running without big trouble and everybody around likes it. GnuDIP \
> is serving below dyn.psi5.com for friends and just for fun, so no promises and no \
> regrets. 
> Meanwhile I got hold of dyn.cx, which is unquestionable a very sexy address. But \
> IŽm stuck at some basic missunderstanding of DNS-architecure, I guess. 
> The zone psi5.com is delegating dyn.psi5.com like this and it works nice:
> dyn             IN      NS      ns.psi5.com.
> 
> That way subdomains like vv.dyn.psi5.com and silva.dyn.psi5.com are available.
> 
> My assumptions, please correct me if I am wrong:
> 
> dyn.psi5.com must be running on exactly one nameserver, because otherwise zones \
> could become out of sync while beeing updated with something like "nsupdate ns1.foo \
> && nsupdate ns2.bar" and two nameservers do not make any sense for a GnuDIP-zone. 
> But how can I gather all DNS-queries at one Nameserver when I do not have full \
> control over the higher-level-domain, like dyn.cx, where .cx would be the \
> higher-level-domain? I canŽt do someting like this in the .cx-Toplevel-Domain:

All zones have an SOA record. This record identifies the "master" server
for the zone. The "nsupdate" command sends updates there.

Note that this master server does not need to be one of the servers
identified in the NS records, although it can be.

The nameservers listed in NS records ("slave" servers) will look to the
master server for the zone for zone updates. Zones have a "serial"
number. If the zone is manually maintained, you are supposed to bump
this up by hand. For dynamic zones this gets bumped up with each update.

BIND (and the DNS standard) provide a number of mechanisms for slave
servers to keep their version of the zone up to date, ranging from
checking the serial number in the master server's SOA at intervals, and
downloading the whole zone if it is not the same as the one the slave
has, to "dynamic update forwarding" (which is probably what you want). I
am afraid this can get complicated. Please read the BIND documentation,
and maybe ask the gurus on the BIND mailing lists.

> 
> dyn             IN      NS      ns.psi5.com.
> 
> .cx forces/allows me to use at least two nameserver at the TLD like:
> 
> dyn             IN      NS      ns.psi5.com.
> IN      NS      ns.csg-germering.de.
> 
> or like this
> 
> dyn             IN      NS      ns.psi5.com.
> IN      NS      ns.psi5.com.
> 
> If the second way is acceptable by the holy grail of DNS-gurus, I will use it and \
> you can stop reading. Just give me your blessings ;-) 
> Otherwise I am out of wit... a kingdom for a sword...
> 
> --
> Christian Brandt
> 
> life is short and in most cases it ends with death
> but my tombstone will carry the hiscore
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> --
> GnuDIP Mailing List
> http://gnudip2.sourceforge.net/gnudip-www/#mailinglist

-- 
Creighton MacDonnell
http://macdonnell.ca/

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

--
GnuDIP Mailing List
http://gnudip2.sourceforge.net/gnudip-www/#mailinglist


[prev in list] [next in list] [prev in thread] [next in thread]