IP addresses in NS records seem to be breaking hostname resol ution

Wed Jul 17 14:00:28 UTC 2002

David,

Your nameserver 216.154.198.178 responded to your single dig query with
correct nameserver entries provided by the GTLD servers.  This first bit of
resolution works for me as well if I don't have any NS records for
pacetech-inc.com in my resolver's cache.  

The problem I'm experiencing is that once I make contact with the
nameservers at hj.dpliv.com or pcweb.dpliv.com to resolve an MX or A record,
they pass additional records to me containing broken NS records.  After
that, resolution fails.

When you did "dig mx pacetech-inc.com", you got back the same bad NS records
I got back:  IP addresses.  Look closely at the NS records in the AUTHORITY
section of what you sent me under "dig mx pacetech-inc.com".

Your first dig got NS records from GTLD servers.  Your second dig shows the
bad NS records from pacetech-inc.com's servers.

Your subsequent resolutions of pacetech-inc.com hostnames should now fail if
you're using a caching resolver.

Chris Davis

-----Original Message-----
From: David Botham [mailto:dns at botham.net]
Sent: Wednesday, July 17, 2002 9:31 AM
To: bind-users at isc.org
Subject: RE: IP addresses in NS records seem to be breaking hostname
resolution

> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Chris Davis
> Sent: Wednesday, July 17, 2002 8:52 AM
> To: 'bind-users at isc.org'
> Subject: IP addresses in NS records seem to be breaking hostname
> resolution
> 
> 
> 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

Do NOT do this.  NS RR should have a domain name on the right side, not
an IP address.

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

However, I do not see what you are seeing:

dig ns pacetech-inc.com

; <<>> DiG 9.2.1 <<>> ns pacetech-inc.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58921
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;pacetech-inc.com.              IN      NS

;; ANSWER SECTION:
pacetech-inc.com.       172800  IN      NS      JH.DPLIV.com.
pacetech-inc.com.       172800  IN      NS      PCWEB.DPLIV.com.

;; ADDITIONAL SECTION:
JH.DPLIV.com.           172800  IN      A       216.90.116.7
PCWEB.DPLIV.com.        172800  IN      A       209.44.8.1

;; Query time: 56 msec
;; SERVER: 216.154.198.178#53(216.154.198.178)
;; WHEN: Wed Jul 17 09:03:36 2002
;; MSG SIZE  rcvd: 109

There NS RR's look to be in order.

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

Works fine from here:
dig mx pacetech-inc.com

; <<>> DiG 9.2.1 <<>> mx pacetech-inc.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48463
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;pacetech-inc.com.              IN      MX

;; ANSWER SECTION:
pacetech-inc.com.       1798    IN      MX      20 pcweb.dpliv.com.
pacetech-inc.com.       1798    IN      MX      10
mail.pacetech-inc.com.

;; AUTHORITY SECTION:
pacetech-inc.com.       1798    IN      NS      209.44.8.1.
pacetech-inc.com.       1798    IN      NS      216.90.116.7.
pacetech-inc.com.       1798    IN      NS      209.44.8.6.

;; ADDITIONAL SECTION:
pcweb.dpliv.com.        172656  IN      A       209.44.8.1
mail.pacetech-inc.com.  1798    IN      A       209.144.64.15

;; Query time: 1 msec
;; SERVER: 216.154.198.178#53(216.154.198.178)
;; WHEN: Wed Jul 17 09:06:00 2002
;; MSG SIZE  rcvd: 189

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

Seeing the output from my dig above, do you still think there NS RR's
are wrong?  Could there be some other problem on your end?

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

Given that your original assumption regarding their NS records is
probably wrong, I would look locally for some other problem...

> 
> 
> Thanks much,
> Christopher Davis
> Site Engineer
> ComputerJobs.com