🚀 go-pugleaf

JS> == John Stanley <stanley@skyking.OCE.ORST.EDU>

Y'know, it'd be nice if your news software maintained References:...

 ckd> But if they *do* want to look like part of the Internet, they should
 ckd> do so, instead of whining about how Internet sites "must" support
 ckd> pathalias and the .UUCP hack.

 JS> I have seen nobody "whining" about how Internet sites "must" do anything.

Willard, for one, appears to be insisting that Internet sites keep
up-to-date pathalias maps around so they can route to .UUCP sites.  And his
posts have sounded a bit whiny to me.

 JS> Neither of these puts me in charge of my little section of the DNS.
 JS> They put me in contact with someone else, who is in charge of my
 JS> little section. Not the same thing.

Then my boss isn't really in charge of the machines at my site, because he
has to go through one of the sysadmins to make a configuration change?

 ckd> Or even having an account on your DNS server's machine so you can
 ckd> make the updates yourself.

 JS> Oh boy, an account where I can access system files and make changes.

Have you looked at the BIND configuration setup lately?  Normally each zone
is stored in a separate file.  It is trivial to set up the configuration so
that, say, the zone file for "johnstanley.com" is /home/stanley/js.com.zone.

 JS> Internet admins who give priveleged accounts to their UUCP connections
 JS> are asking for trouble.

See above.  Having the ability to edit a specific file doth not a
privileged account make (unless the specific file really *is* a system
file, which BIND zone files most definitely are not).

Admittedly, this means that the change is less than instant, unless a
setuid program is provided to send a HUP signal to the named.  (Obviously a
crontab entry to HUP the named nightly would be another solution.)  Of
course, such programs are easily written, made group-executable, and
installed, in order to give the proper "feeling of control" to people like
you.

 JS> And the first place they will see it is in their DNS records when
 JS> UUCP-user forgets to update the serial number or puts a goofy date in
 JS> the file.

For the UUCP user's zone.  Either they control it (meaning they have the
power to screw it up), or they don't (where they can ask for changes, and
hope the other guy doesn't screw it up :).

Sure, if the Internet admin gave the UUCP-user access to all the zone
files, then he's either trusting or stupid (or both).  But that's not
necessary, except perhaps in building strawman arguments.

 JS> Or when two UUCP-users try to update the same file at the same time.

If they share a domain, they should figure out which one of them keeps the
file up to date.  If they can't figure that out, they shouldn't share a
domain, then...

 ckd> And pretty soon you notice that EVERYONE is failing to get you mail, 

 JS> Pretty soon? This implies that I know that someone else sent me mail,
 JS> and I am not quite sure how I am supposed to know that unless the mail
 JS> gets through to tell me that.

If no mail arrives at this site for an hour, something's wrong.  Your site
may vary.  If *nobody* sends you mail, don't you wonder why?

 ckd> someone called your Zone Contact and told them to fix the zone.  

 JS> If you really think that Joe Internet User even knows there is a Zone
 JS> Contact, much less would call him when his mail doesn't get through,
 JS> you are wrong.

No, Joe Internet User (at least *my* users) will ask me "why did this
bounce?"  I'll also see the headers of the bounce, so I can note that the
address looks right (wasn't "skyking.ece.orst.edy" or the like) and check
it out with nslookup or DiG.  If necessary, *I* call the ZC.

 JS> And if 100% of the Internet can't get me mail, I may never notice.  Or
 JS> it will take a while, perhaps.

I'm sorry that you get so little mail.  I tend to believe that the
wider-ranging the outage, the more likely it is to be noticed.

 JS> Sigh. You must keep something that tells you who a root nameserver is.
 JS> That is, indeed, keeping some information about someone.

Yes.  And how often do they change?  Not very (and even when they do, most
of them stay the same; I'm sure many folks still have SRI-NIC.ARPA in their
root cache files, but terp is still there, for example...).

The best part, of course, is that you can query any of them for an
up-to-date list; I usually just type something on the order of 
"dig . ns +aa @some.root.server > /var/domain/root.cache"
every few months or so (in case I miss the multiple postings that have
marked every recent change).

 JS> And sites can do routing without keeping the entire UUCP maps on their
 JS> local disk, or even local net.

That's not doing routing.  That's doing punting.

 JS> Yes, I have heard of wildcards. I have one. Change the "one" to "an",
 JS> if you wish.  It is still not a reasonable expectation for every UUCP
 JS> site to have an MX record, whether it is its own or part of a
 JS> wildcard.

However, it is a reasonable expectation for a site that wishes to be
reachable by Internet sites to use the Internet-standard method for
registering a mail gateway.  The fact that many sites support the .BITNET
and .UUCP hacks is merely a courtesy to those sites that, for whatever
reason, are not in the DNS.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>