DRAFT - DNS Admin Guide

Daniel Lang dl at leo.org
Wed Jun 25 01:10:23 PDT 2003


Hi,

Ken Smith wrote on Wed, Jun 25, 2003 at 03:17:05AM -0400:
[..]
> The proposal's suggestion for that was to "internalize" it inside of
> dnsadm@ and they decide strictly based on the *DNS* mechanics of
> things.  Are the DNS servers overloaded?  Are there so many requests
> for <country> that it would be convenient to have another set of hands
> doing the edits for that?  Would we like to have another DNS server
> in <country> but perhaps it is sufficient to make it a pure slave
> server and still keep <country> master info on the main master site
> (thus nameservice queries in <country> may flow better but updates
> still happen centrally).  Creation of the country code based subdomains
> happen automatically and with no "special" authorization as a side-effect
> of the Mirror Coordinator (or whatever, that's the question Jun raised)
> saying there is a new mirror site in that country.

Hmmm... good question. It would certainly simplify some things
in some areas and I guess the load to administer the primary
may be not that high (though probably it's hard to guess).

The bigger problem could be, that it is done by delegation
right now.

> I think this is one of those things that need to be evaluated on
> a cost/benefit basis.  What is the benefit to allowing this sort
> of delegation to begin with?  I'm not completely sure what the answer
> is to that - I'm sure I only have a partial picture of it.  I have
> seen the cost though - it seems to confuse a lot of people and they're
> not sure where to ask for stuff.

> The current layout seems to be that a "Region" as much as possible is
> left to decide issues like how many FTP mirror sites to have, etc. on
> their own.  That's a really good thing as long as the Regions are well
> defined, those Regions have a strong leadership within themselves, etc.
I think the "region" _is_ well defined. The region a server is in,
is the ccTLD assigned to the country, the server is located in.
Fullstop. (This definition is probably what we want, it makes
no assumption about the TLD (cc or not) the official hostname
of the server contains. Thus for example, making ftp.leo.org
a server in the "de" region, regardless of the .org TLD).

The well definition of a region is important, since the region
is used by users to select a mirror, that is "close" to the
client system. IIRC this works reasonably well.

Strong leadership is a different issue...

> But I'm not sure it's working.  Working with an example at hand, we
> have a site in Croatia that has been given access to ftp-master and
> is ready to join in as ftp.il.freebsd.org.  But il.freebsd.org doesn't
> exist.  It needs to be handled centrally but who is that?  The folks

Hmm strange, I thought Croatia has '.hr' and '.il' is Israel?
Is it really the case, that the croatian server wants to join 
the "il" region? This seems to be a very strange edge case...

Assuming .hr is the croatian ccTLD and the croatian server wants
to be in the hr.freebsd.org domain, but it does not exist, yet,
I would assume the mirror admin, who actually happens to be
the first to establish an official mirror in croatia could
get approval from the Mirror-Coordinator, which can act as
enough authorization for dnsadm@ to delegate the domain to him/her.
Provided he/she can administer the zone. If the subdomain does
not exist, but the mirror admin in Croatia can not administer
the zone, I would say, it's bad luck.

> doing us.freebsd.org by default?  Someone needs to realize that they
> are the coordinator for anything that doesn't have its own strong
> Regional leadership.  Things fall through cracks.  And, as the delegation

IMHO a good solution, to have such a fallback.


> changes, all of that becomes a moving target for the people who are
> trying to administer the WWW sites for example (now suddenly a new
> Region popped up so person X doesn't need to worry about requests
> from that region any more, it's person Y).  And as you say, what happens

Such changes will not happen very frequent, I guess.


> if there is a LOT of interest in Croatia for FTP mirror service and
> they want to administer that locally but they have zero interest in
> CVSup?
Then, there will be no cvsup.hr.freebsd.org.
If there is actually a cvsup mirror in Croatia but maintained
by other people, those who have taken responsibilty for their
zone, will have to add an entry for this server, if it is requested.
If no one has it, it goes to the fallback maintainers, as before.
I don't see the issue here.

hostmaster at hr.freebsd.org is a different role than admin
at ftp.hr.freebsd.org. It can be assumed by the same people,
but the matters need to be handled differently.
For certain it would not be acceptable to delegate the
hr.freebsd.org subdomain to people, who are not willing to
make "cvsup" entries into the zone, just because they run
an ftp server and are not interested in cvsup.

> All of this is something you need to live with in a truly large
> organization.  But is the DNS administration such a heavy load that
> it can't be handled by a relatively small number of people?  I can't
> answer that, it's an open question.  If it isn't a very heavy load
> "end-user frustration" can be avoided by a one-stop-shopping low overhead
> setup as I proposed.  If it is a heavy load then what I proposed is
> inadequate. :-)

Don't forget the obstacles you have to cope with, if you want to
change the running system. I can imagine people feel stepped on
their toes, if you want to take away the responsibility they
currenty have. Of course this should not be an issue, if there
are good reasons to change, but it should be considered.

Best regards,
 Daniel
-- 
IRCnet: Mr-Spock        - "Do you love yourself ?" - "Yes!" (Isar 12) -  
 Daniel Lang * dl at leo.org * +49 89 289 18532 * http://www.leo.org/~dl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6020 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hubs/attachments/20030625/6c77f1ca/smime.bin


More information about the freebsd-hubs mailing list