OT?: Emailing from within filepro

[Fairlight]

When asked his whereabouts on Sat, May 29, 2004 at 12:00:59PM -0500,
Tom Aldridge took the fifth, drank it, and then slurred:
> Jay R. Ashworth wrote:
> > On Thu, May 27, 2004 at 11:57:43AM -0400, Fairlight wrote:
> >> In the relative spacial/temporal region of
> >> Thu, May 27, 2004 at 11:04:42AM -0400, Kenneth Brody achieved the
> >> spontaneous generation of the following:
> >>> 
> >>>> Recursive queries supported by this server
> >>>>  Query for aldridgeinc.com type=255 class=1
> >>>>   aldridgeinc.com MX (Mail Exchanger) Priority: 1
> >>>>   gate.aldridgeinc.com aldridgeinc.com SOA (Zone of Authority)
> >>>>         Primary NS: gate.aldridgeinc.com
> >>>>         Responsible person: sid at aldridgeinc@com
> >>>>         serial:200381703
> >>>>         refresh:20s
> >>>>         retry:20s
> >>>>         expire:20s
> >>>>         minimum-ttl:20s
> >> 
> >> Dear God in heaven.  WHO on earth sets those times to 20s?!  I had to
> >> reread that five times to make sure I actually saw that right, and I
> >> -still- couldn't believe my eyes.  Unfortunately, I just looked up
> >> the SOA myself and it's actually -true-.  Good gravy.
> > 
> > Well-trained adminstrators who are about to move a service from one
> > server to another.
> > 
> > :-P
> 
> Moving from one server to another was the reason. Forgot to change it back.

But 20s?!  I used to update my zone pretty frequently, so I have a 1hr min
ttl, and even that's considered short, but at least it's not as extreme as
20s.  With that, you effectively defeat caching.

And not all of those needed to be set to 20s.  Sounds more like someone
never looked up what they actually do, and they just set them all to one
value because they don't know the difference.  Particularly, setting both
expire and refresh to 20s means that if your secondary can't contact the
master within 20s, it will immediately drop the entire zone on the ground
and your secondary no longer knows a thing about the zone until the primary
is reachable--in effect negating the point of having a secondary.  This
combination of settings is patently unsound.

Actually, you have more problems than that.  Your whois record with NSI
shows the right IP# for your primary DNS server, but an incorrect hostname.
The hostname for the domain name (aldridgeinc.com) has no A record, so a
lookup fails based on the whois information.  Granted, the IP# points to
gate.aldridgeinc.com, but this is still incorrectly configured.  

I won't get into putting a primary nameserver on DSL.  Well, yes I will,
since DSL has absolutely zero guarantee of service under FCC regulations.
Doesn't matter what your contract with the telco says--under regs, they
don't have to fix it, you don't have any recourse if they don't.  This
means that if you want one on your side of the demarcation point, it
should be the secondary, not the primary, as that way at least the primary
would always be active and you'd have less delay.  As it happens, this
wouldn't normally cause much of a problem, as the system is designed to
have secondaries for a reason.

But given your 20s times that were present, if your DSL lost sync for a few
minutes (or even -one- minute) and the secondary tried to fetch from the
primary over an unroutable link (because it was -down-), then you'd get a
nameservice lookup error--exactly what someone hit when they tried mailing
you directly.  It's no small wonder it was acting oddly--it was entirely
misconfigured.

I -still- would never put the primary on the private side of the demarc on
DSL.  Actually, I would never run a business purely on DSL, purely because
of the regulations.  It's simply a bad idea for anything mission critical.
I know a lot of people that dropped T1's and fractionals for DSL due to
the cost.  You'll make up for that when your telco costs you a few grand
more than you save during an outage they don't get around to fixing soon
enough.  It's a foolhardy move at best.  There are business "plans", but
that's still only a contract with the carrier.  The FCC won't intervene
because there's no mandate for restoration of service built into the DSL
tarriffs.  With a T1, you at least have some leverage.

Anyway...

I'd second Jay's suggestion for Sid.  Heck, it doesn't even take a whole
book to learn enough to keep yourself out of this much trouble:

     man named
     man named.conf

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html