IP addresses in NS records seem to be breaking hostname resolutio n

[Chris Davis]

Hello,

I am experiencing a name resolution failure that appears to be due to a zone
containing NS records that have IP addresses rather than hostnames.  I am
seeking help as to how I may avoid having these NS records cause name
resolution failures on my resolver.



Problem Description:

A domain to which my systems must send frequent e-mail seems to have NS
records in their zone file that have IP address entries rather than
hostnames, as such:

@	IN	NS	209.44.8.1
@	IN	NS	216.90.116.7
@	IN	NS	209.44.8.6


I have deduced the above configuration only from the following
investigation. I have not viewed the zone file..
host -t ns pacetech-inc.com 209.44.8.1
Using domain server 209.44.8.1:

pacetech-inc.com name server 209.44.8.1
pacetech-inc.com name server 216.90.116.7
pacetech-inc.com name server 209.44.8.6

The same results can be obtained from name servers 216.90.116.7 and
209.44.8.6 as well.

Whenever these NS records are absent from my resolver's cache, meaning
resolution of hostnames in their domain starts with the GTLD servers,
hostname resolution for hosts within the domain works just fine.  The
problem arises only after a first hostname resolution because their server
passes their NS records to me as additional records during the first
resolution.  Subsequent resolutions fail until these NS records expire or
are cleared from my resolver's cache.


Examples:

Here is an example of my problem with the NS records that contain IP
addresses already in my cache:
host -t mx pacetech-inc.com
Host not found, try again.

Here is an example of resolving the same hostname with an explicit name
server to use:
host -t mx pacetech-inc.com 209.44.8.1
Using domain server 209.44.8.1:

pacetech-inc.com mail is handled (pri=20) by pcweb.dpliv.com
pacetech-inc.com mail is handled (pri=10) by mail.pacetech-inc.com

Action Taken:
I have taken the preferred course of action and asked the administrator (and
everyone else related whom I can contact) to repair the NS records, to no
avail.  No luck there.


Note:

I can't just "bogus" their entire name servers because I do need the MX and
A records from them.


My questions to bind users:

Can I configure my bind 8.3.3-REL which is a caching only resolver to reject
these NS records (that are provided by the name servers 209.44.8.1,
209.44.8.6 and 216.90.116.7 as additional records when I query for type MX
or A or whatever) without configuring my bind to perform a blanket rejection
of all additional records from all domains?  If I can do this, how is it
done?

If I cannot prevent the "additional" NS records being added to my cache, can
I configure bind to dump them after they do not work?  (It seems like this
would be a bind feature, but apparently it is not.)

If not, any other suggestions, or am I way off target?


Thanks much,
Christopher Davis
Site Engineer
ComputerJobs.com