mailing list archives
Re: DNS contamination
From: "Alex.Bligh" <amb () xara net>
Date: Fri, 24 Jan 1997 12:24:20 +0000
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 220.127.116.11
foo NS ns2.foo.com
ns2.foo.com A 18.104.22.168
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 22.214.171.124
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 126.96.36.199 (which we think
is ns.foo.com). We do this with norecurse set. If the glue
record is right, it returns 188.8.131.52 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.
- - - - - - - - - - - - - - - - -
Re: DNS contamination Dean Gaudet (Jan 23)
Re: DNS contamination Neil J. McRae (Jan 24)