You've come to this page because you've asked a question similar to the following:
What distinction does the DNS make between my "primary" and my "secondary" content DNS servers? Is my secondary server only queried when the primary server rejects a query?
This is the Frequently Given Answer to that question.
There is no actual notion of "primary" or "secondary" content servers in DNS proper. All content DNS servers for a given domain are in fact peers. As far as the DNS proper is concerned, they all serve up the same information about the domain, and querying one is as good as querying any other. There is no preference value assigned to any individual server (The DNS protocol simply doesn't have any mechanism to support this.), and in a perfect world the traffic load should be equal across all of the content DNS servers in any particular set.
There is no notion of a "secondary" server "redirecting" a query to the IP address of a "primary" server, either. Queries are responded to by the content DNS server that received them.
Furthermore: There is no notion of a "primary" server "rejecting" a query. If one content DNS server of the set of content DNS servers serving up a particular domain receives a query, the DNS protocol provides no means for it to actively reject the query so that the query resolver tries another server in the set.
It is the entity that is performing query resolution (usually a resolving proxy DNS server) that decides where to send the query and what to do in the event of a lost datagram or a timeout. A resolving proxy DNS server obtains the list of content servers for each domain, and chooses from that list which content server to contact in a manner that varies across different proxy DNS server software packages.
The ISC's BIND, for example, applies rules that measure the "round-trip time" for each content DNS server and choose to prefer contacting the server with the lowest RTT. There is evidence that these RTT rules, or BIND's implementation of them, is broken, leading to the first content DNS server listed being passed the majority of the traffic.
(My educated guess is that it is the rules themselves that are broken. The design has at least two flaws that I can see. I suspect that if the "." content servers didn't rotate the list of gTLD content servers "round-robin" we would probably see the effect far more clearly, with 192.5.6.30 receiving the lion's share of the gTLD traffic, and there would be greater incentive for the ISC to fix the design. Ironically, it seems that daft BIND content DNS server behaviour is obscuring a daft BIND proxy DNS server bug.)
Both dnsrcpd, the resolving proxy server in the Internet Utilities for OS/2, and dnscache in Dan Bernstein's djbdns simply pick a server from the set at random each time.
The notion of "primary" and "secondary" content servers is entirely to do with database replication, which is a private matter between coöperating content DNS servers that is unrelated to the DNS proper.
One mechanism for database replication is BIND's "zone transfer" scheme. This is designed around a "master", a.k.a. "primary", content DNS server that replicates, on demand, via "zone transfer", the portion of its database that deals with a particular "zone" to one or more "slave", or "secondary", content DNS servers. Changes to the database for that "zone" may only be made on the "master".
Given that database replication arrangements can differ for different "zones", the terminology only applies with respect to specific "zones", and not to the content DNS servers themselves in their entirety.
There exist content DNS server database replication schemes that do not involve a division into a "master" and its "slaves" at all.
For example: Microsoft's DNS server (when performing the rôle of content server) can be configured to use Active Directory for its database, for example. Active Directory has what Microsoft terms "multi-master replication". This means that changes may be made to the database on any server. Those changes are then replicated by Active Directory's own database replication mechanism to the databases of all of the other servers, using timestamps to resolve conflicts caused by two changes to the same record made on different servers.