Wrong glue records entered.

Barry Margolin barmar at alum.mit.edu
Tue Jan 18 00:40:14 UTC 2005


In article <cshi0g$274j$1 at sf1.isc.org>, Steven Job <list3 at wwwcrazy.com> 
wrote:

> Are glue records supposed to be returned with the MX records?

Glue records are the A records that are related to NS records.  So your 
question doesn't really make sense.  I think what you're asking is "Is 
the A record for the target of an MX supposed to be returned with an MX 
query?"  The answer to that is "yes" -- if the relevant A records are in 
the server's memory (either authoritative data or cache) they should be 
included in the Additional Records section of the response.  RFC 1035 
section 3.3.9 says: "MX records cause type A additional section 
processing for the host specified by EXCHANGE."

> 
> The problem that we are having is that someone will create the following MX
> records for their domain.
> @             10800   IN      MX      40 smtp.secureserver.net.
> 
> But then some one else will create the domain "secureserver.net" in our system
> and point the A record for "smtp" to another IP.
> Now "secureserver.net" is not pointing to our name servers (at the root name
> server level) so our servers should never be asked for it.  But they are by
> some resolvers and it is poisoning everything.
> 
> When I do a "dig" I do not get this problem at all (that the glue records are
> being returned since the server is not responsible for that zone).
> I have tested this with both bind (9.x) and dnscache and neither do this.
> But some name servers are asking for these records.
> 
> Is is possible (other than deleting the "secureserver.net" zone) to stop these
> resolving name servers from asking our name servers for domains that it has no
> business asking?

They're probably not asking your servers, they're just using the 
additional records that your servers are sending along with the MX 
response.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***



More information about the bind-users mailing list