Date: Wed, 25 Jun 2003 10:10:18 +0200 From: Daniel Lang <dl@leo.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: freebsd-hubs@freebsd.org Subject: Re: DRAFT - DNS Admin Guide Message-ID: <20030625081018.GC3446@atrbg11.informatik.tu-muenchen.de> In-Reply-To: <20030625071704.GB1478@electra.cse.Buffalo.EDU> References: <20030624173337.GD11784@electra.cse.Buffalo.EDU> <7m7k7b564w.wl@black.imgsrc.co.jp> <20030625011941.GB26111@electra.cse.Buffalo.EDU> <20030625061059.GB3446@atrbg11.informatik.tu-muenchen.de> <20030625071704.GB1478@electra.cse.Buffalo.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@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@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ [-- Attachment #2 --] 0 *H q0m1 0 + 0 *H @00{0 *H 01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10URBG-Benutzer-CA10 *H ca@in.tum.de0 030520123142Z 040521000000Z01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10U Daniel Lang1$0" *H daniel.lang@in.tum.de00 *H 0 U]݅.7p)Wqz\cE:#h400_i6$}PIa 1^' dnDU;01'v<d{B[t1N 0{0 U 0 0 U rz oo oyݡ0U #05:0mǟKqH(cԡ01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10 URBG-CA10 *H ca@in.tum.de0U 0 U %0++0U 0langd@in.tum.dedaniel.lang@in.tum.de langd@informatik.tu-muenchen.de%daniel.lang@informatik.tu-muenchen.delangd@cs.tum.edudaniel.lang@cs.tum.edu dl@leo.org0 U 0 08U 10/0-+)'http://ca.in.tum.de/crls/userca_crl.crl0 `HB0 `HB Dieses Zertifikat wurde ausgestellt fuer Daniel Lang von der RBG-Benutzer-CA, Fakultaet fuer Informatik der Technischen Universitaet Muenchen.06 `HB)'http://ca.in.tum.de/cgi-bin/userca-rev?02 `HB%#http://ca.in.tum.de/cgi-bin/ca-rev?06 `HB)'http://ca.in.tum.de/policies/rbgca.html0 *H yC9zO zoѯӹ]0 5->l̆MmdW 0E $1]d%d1>qJ/NOV|#zvTư)%+# -KS2 25ܺ3O7q Oj2JgpL]ެ5EaSta[Fc7廞( B +ws Ubi;8'YQ eN nk$X®WM q& qlCT0(00 *H 01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10 URBG-CA10 *H ca@in.tum.de0 021009164103Z 040521000000Z01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10U RBG-Server-CA10 *H ca@in.tum.de0"0 *H 0 \l ~sv LV I`Ɩ|;iT_|zw( r_$h ? ajzMY gGlC9 X_/2&>H?]:NOB U^5]])P`L.!q`y6Z<o=l a<TeבîT6,/~ #(K=Uj9 pw"`%Ab wjc~0Ab^o'7 з h0d0U 00 U {EPT]C+@0U #0e~MA?*{}]01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10 URBG-CA10 *H ca@in.tum.de 0U 0U % 0 +04U -0+0)'%#http://ca.in.tum.de/crls/ca_crl.crl0 `HB0 `HB wuZertifikat fuer RBG-Server-CA ausgestellt von RBG-CA, Fakultaet fuer Informatik der Technischen Universitaet Muenchen02 `HB%#http://ca.in.tum.de/cgi-bin/ca-rev?0< `HB/-http://ca.in.tum.de/policies/servercapol.html0 *H ʝBof(HT:aB/)j-Í n ݟӗ5 @IŶҧ㭬 ? c ~ PYy#`|2X(&q~N:@uámgtA@*=<'fzvm{ғ0dXWsx)yC9,N s% %îd-$` ES1b:,{Mw^SKlANMf2d]%8)FQ>ֵ^ &^?_"Y{ & t2px#߲Vm &6D o t,1tmʫ_bKm$_W1dCj笞V63` Ő j>_p~/%9 % ʬ4Jo~kA^GX X.֙BdmX*Ye%}zI/נ'-k%0@0(0 *H 01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10 URBG-CA10 *H ca@in.tum.de0 021009170352Z 040521000000Z01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10URBG-Benutzer-CA10 *H ca@in.tum.de0"0 *H 0 arq:*弘)y Pv9ow/r#U2u*zоOKh aWf% ిƜ;~l|%A 0gڧQwg $xX.1e.zFdEZ7,Gq9{@ ]8laT#kQ""6p#:܅ `)ɌB(iӭzڱU[ .Wn{ABh]x} ~0z0U 00 U 5:0mǟKqH(c0U #0e~MA?*{}]01 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10 URBG-CA10 *H ca@in.tum.de 0U 0 U %0++04U -0+0)'%#http://ca.in.tum.de/crls/ca_crl.crl0 U 0 0 `HB0 `HB zxZertifikat fuer RBG-Benutzer-CA, ausgestellt von RBG-CA, Fakultaet fuer Informatik der Technischen Universitaet Muenchen02 `HB%#http://ca.in.tum.de/cgi-bin/ca-rev?0: `HB-+http://ca.in.tum.de/policies/usercapol.html0 *H MėN^[- z|*dt[BN,y ƑjP&(]/]I ]+Ab~gEⷃs?RW>:bu ˖ qA`K.3mWԯ ;kGrnX]j83Ǔ2e> Gզ^ gMi7-F=Eր熮;\qx7ǖ.rHٓ@A :c>A 0&/T,*@_z >;&VP tdaE;įjMS<4#ʜ"SþN|.U >]tݠ bq7:Hޫ,M P:Nև8V4( FD9 EmHy uVoX&#SQW`}ɱ<9uψu笔l G=>I"-B4a|x2y _k7?p Vw>j&@Y\710001 0 UDE10UMuenchen1)0'U Technische Universitaet Muenchen1"0 U Fakultaet fuer Informatik10URBG-Benutzer-CA10 *H ca@in.tum.de{0 + 0 *H 1 *H 0 *H 1 030625081018Z0# *H 1l7ZiW'2γπa0R *H 1E0C0 *H 0*H 0 *H @0+0 *H (0 *H 3$ύK:M: {>r|\Ľ+^u:syϩSÓRxR k\ˆ$5`3YM9EEA ̊Z# 'a7a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030625081018.GC3446>