Ignoring additional records works pretty well for me.
This is harder than it looks. Sometimes the glue A RRs are the only ones you can get -- you need them in order to ask questions in the domain they are in, so without them you have infinite regress.
This might be naive but: AFAIK the only time you *need* glue A RRs rather than normal A RRs is when you are looking for a namserver whose name is within the zone, i.e. within .com foo NS ns.foo.com ns.foo.com A 1.2.3.4 foo NS ns2.foo.com ns2.foo.com A 2.3.4.5 foo NS ns.bar.net the top two are correct glues, and the bottom one doesn't need one. The danger is that the A record is incorrect, or that someone has stuck it in unnecessarilly, like (in .com) foo NS ns.bar.net ns.bar.net A 5.6.7.8 So, why not tag such glue records when the go in the cache as suspect. Then when you first refer to them, query them for their own A record. IE in the top example above, when the A RR for ns.foo.com is just about to be pulled out the cache, it is has some marking as "suspect", so a direct query for an A RR for ns.foo.com is made. This first tries 1.2.3.4 (which we think is ns.foo.com). We do this with norecurse set. If the glue record is right, it returns 1.2.3.4 and it goes into the cache OK. If the glue record is wrong, the query fails and we try the secondaries. This one might be wrong too, in which case we continue until we get a correct one (here ns.bar.net). I spent a few (fruitless) hours trying to work out why 1/2 the internet had incorrect A records for ns.uu.net and in the end concluded (as I say, perhaps niavely) that something like the above would solve the problem. Alex Bligh Xara Networks