"sysquery" error

Jim Reid jim at rfc1035.com
Thu Dec 14 01:25:13 UTC 2000


>>>>> "Larry" == Larry Sheldon <lsheldon at creighton.edu> writes:

    >> Providing 15 NS records for your zone is way over the
    >> top. There are just 13 NS records for the internet root zone,
    >> which is much, much more in demand than your zone ever will
    >> be. It probably doesn't do you a lot of good to list so many
    >> name servers.

    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. 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. 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. 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.

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.

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?

    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. 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.

    >> [By all means have 15 or more local name servers for your
    >> zone(s) if you like, but you don't have to supply NS records
    >> for every single one of them.] What's worse is that all of the
    >> advertised name servers for creighton.edu are on the same net,
    >> an obvious single point of failure. Please read RFC2182:
    >> Selection and Operation of Secondary DNS Servers.

    Larry> If I understand this stuff at all--that isn't quite
    Larry> right--depending on what you mean by "advertized".

I mean the NS records you've put the creighton.edu zone file. They are
the definitive list of servers for your zone.

    Larry> not looked for a couple of weeks, but I think the
    Larry> registration at NSI shows the four I mentioned above which
    Larry> puts one here, one in Denver, one somewhere else in Omaha
    Larry> (dunno where, actually.  

Fine, but that's not the point. All four of those servers
*definitively* tell every other name server in the world that the ONLY
servers for your zone are those 15 birdname servers living on the same
LAN on your campus. Well they told that before you "helpfully" added
another 4 or 5 NS records to your zone file. Sigh.

    Larry> I'd look it up in one of several books at my disposal.
    Larry> None of them mention "sysquery".

Find a better book.

    >> The error message is saying your name server was told that
    >> bluebird1.creighton.edu was a name server for some zone. ie an
    >> NS record exists for it somewhere. But when your server tried
    >> to lookup that name to get its address, an NXDOMAIN - no such
    >> host/domain - error was returned.

    Larry> That matches what I found serendipitously.  Does "sysquery"
    Larry> or "findns error" always mean that?

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.



More information about the bind-users mailing list