DNS contamination

Fri Jan 24 12:24:20 UTC 1997

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