"sysquery" error

[Larry Sheldon]

In the conversation with Jim Reid, through the smoky veil of email I get
the feeling that Mr. Reid is arguing with me or that I am coming across
as argumentative.  If that is all wrong, forget it--if not, I apologize.

I am not nearly knowlegeable enough to be argumentative.  But I have managed
to muddle through managing (more or less) the name service in this domain.

Five or six years ago I tried very hard to understand more than I do--I
have copies of all (I think) of the Liu books, and I wore out a lot of bits
on this list or one like it, and did a lot of experimenting.

>     Larry> I've been both ways about that and don't really know what
>     Larry> the "right" answer is, and I always welcome comments.
> 
>     Larry> My most recent "think" about it is that by listing them all
>     Larry> I at worst do no harm and might in fact spread the work
>     Larry> around--but I may not know enough about the innards of
>     Larry> these critters to even be wrong.
> 
> Actually what you're doing now is wrong. The first mistake is having
> so many NS records, far more than you or the world's name servers
> reasonably need.

I understood that on the last round.

> This means there's less space in an answer packet for
> additional information like the addresses of your servers. [Take a
> look at the answer from dig when you ask for the creighton.edu name
> servers. Compare the numbers of RRs in the answer and additional
> section with the those in the answer returned when you ask for the
> root zone's servers.] That means other name servers will need to make
> extra lookups to resolve the IP addresses of the servers that don't
> have A records in the Additional Section of the reply. That means more
> work and more DNS traffic and more elapsed time looking up your names.
> If there were fewer NS records for your zone, there would be more space
> in the answer for the additional section data. All the names and
> addresses could then be returned in one answer. I told you that the
> far busier and more important root zone gets by on 13 NS records, yet
> your zone had 15. I see this has now been increased to 20! Sigh.

This is the first time (as far as I can remember--certainly the first
time I have understood) the harm that might be done.  As I said, I've
tried listing them all, listing only the registered ones, and most
of the numerically possible combinations in between.

> The 4
> NS records given for your zone in .edu should be enough. There's no
> need to provide NS records for *every* local server you have. I've
> said this already.

I'm persuaded.

> In fact it's doubtful if you need 15 local name
> servers for your zone(s). You could add NS records for just 2 or 3
> local servers on top of the 4 listed in the .edu zone to give you a
> warm feeling. More than that is at best pointless and at worst harmful
> for the reasons I've explained.

I'm not sure what the "In fact . . . " sentence is saying.  I am of the
opinion that every machine that will support a name server along with
what ever it does for a living is a happier machine and its neighbors
on the network will be happier about it as well (especially for the
machines whose work is mostly intra-domain).  Am I wrong there
too?  And I'll need some help understanding that as well.

> The next problem is having so many servers in the same place. It looks
> like they're all on the same physical cable on the same Class B net
> connected to one ISP. These are too many single points of failure, all
> of them easily avoided. Read RFC2182. I said that already too.

Yup--you did--and I forgot to mention that I have read (a number of times)
all of the RFC's that look like they are close.  Didn't understand many of
them, but I read Supreme Court decisions and books about Quantum Theory
too.

And the sequence to understand here is that for reasons that make sense
to my management, if nobody else, all (or nearly all) of the University's
"mission critical" machines are in the same machine room (eggs-in-basket
offset by UPS-airconditioning-24X7-operators-moderate-site-hardening)
hence on the same network.

After they all got there, I decided they should all run their own nameserver
if they know how--see above.

I think the site dispersion requirements are met with three off-site
(mostly out-of-state) servers, plus one of the ones currently in the list
is in a really hard site under a parking lot a quarter of a mile away.

If we lose all of those, I doubt that anybody will care.
  
> Another issue is that the rest of the world's name servers will be
> obliged to keep track of the round trip time to each of the name
> servers for another zone. Since you've got so many servers, this just
> makes yet more needless work and traffic for everyone else's name
> servers. Now this wouldn't be so bad if all these servers were spread
> across the world, but they're not. So why are you forcing my name
> server - and any other that looks up creighton.edu names - to maintain
> the RTTs for each of the 15-16 servers that live on the same LAN on
> your campus?

I think that is (if I understand any of this) a valid extension (or maybe
a different view) of what you said above--and I am still persuaded.

>     Larry> As far as the "public" list is concerned, I think I only
>     Larry> have four listed, the primary here, two secondaries at
>     Larry> Qwest-was-USWest (used to be our ISP and still has a lot of
>     Larry> Creighton folk among their dial-up accounts (and they
>     Larry> wanted to have two--and keep them) and one at GreatPlains
>     Larry> who is upstream of us a ways and is sort of one of several
>     Larry> ISP's (that's complicated and not relevant here, I think.
> 
> That's all very well, but these servers don't help in the way you seem
> to expect. The mega-list of NS records in your zone means the off-site
> servers advertised in the .edu zone will barely get used. Only one of
> them might get queried the first time another name server is asked to
> lookup some name in the creighton.edu zone. The information in the
> creighton.edu zone file overrides whatever is in the .edu zone for
> creighton.edu. That's the way DNS works. So the name servers at
> nic-ks.greatplains.net, ns1.uswest.net and ns2.dnvr.uswest.net will
> tell other name servers that the 15 birdname.creighton.edu servers
> should be used to lookup creighton.edu, just as your local servers do.
> That information obliterates whatever the .edu servers had previously
> told other servers about the creighton.edu zone. That's because those
> off-site servers advertise the NS records you provide in the
> creighton.edu zone file, not what's in the .edu zone file. So any
> server looking up names in your zone will end up only knowing they
> have to query those birdname servers. In reality, they'll cache that
> fact.

The good news here is that it appears that I _did_ come close to understanding
how it worked--although I am startled to learn that ehe off-site servers
will evaporate--I thought there were some tranist-time measurements that
would make those servers look a lot closer than any of the on-campus machines.

And until September of this year, our connection to the worls was so
congested that thw wonder is that anybody ever knew we were here.

> So if the local router between your servers and the internet
> fails, the creighton.edu zone essentially vanishes from the DNS. The
> world's name servers end up trying to reach those now unreachable
> birdname servers. You don't want that to happen even if your local
> mail and web servers are temporarily unreachable. It's not so bad now
> that you're advertising those off-site servers for your zone. But it's
> still bad. If your network link dies, another name server could wait a
> very long time for queries to every one of the 15 birdname servers to
> time out before eventually coming across one of the off-site servers
> that happens to be reachable and answering for creighton.edu.

I think that will make sense when it soaks for a bit.

> LAN on your campus. Well they told that before you "helpfully" added
> another 4 or 5 NS records to your zone file. Sigh.

A couple of times here you seem to indicate that you think I just added
the off-site servers--with the exception of a couple of annoying W2K
machines that nobody can make up there minds about, I have not tinkered
with the NS collection in a couple of years.  I am going to go prune
a bunch of them out after I get through listening to Bush speak.

> Find a better book.

That was one of the earlier implicit, if not explicit questions.  What book?

I've got (and have read) all three editions of "DNS and BIND", "DNS on
Windows NT", bits and pieces of "BOG" [list truncated because it is
probably annoying, and I am too lazy to get up and move the front row
of books to see what is behind them.]


> sysquery is shorthand for "system query", which is something the name
> server does when it has to look something up for itself. Like finding
> the names and addresses of name servers for some zone. findns is the
> name of the routine in the BIND8 named that tries to locate a name
> server. You could have taken a quick look at the source code to find
> this out for yourself.

Dint think of that either--we must have it around here somewhere.  It isn't
clear that that would have helped--I don't speak "C" (I can read a little)
and the students I know who can are all taking finals.

Thanks for the help.
--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
.                                                                       .
- L. F. (Larry) Sheldon, Jr.                                            -
. Unix Systems and Network Administration                               .
- Creighton University Computer Center-Old Gym                          -
. 2500 California Plaza                                                 .
- Omaha, Nebraska, U.S.A.  68178       Two identifying characteristics  -
. lsheldon at creighton.edu                  of System Administrators:     .
- 402 280-2254 (work)                Infallibility, and the ability to  -
. 402 681-4726 (cellular)               learn from their mistakes.      .
- 402 332-4622 (residence)                                              -
. http://www.creighton.edu/~lsheldon    Adapted from Stephen Pinker     .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-