IP addresses in NS records seem to be breaking hostname resolution

[David Botham]

Sorry for the long include:...
> -----Original Message-----
> From: Pete Ehlke [mailto:pde at ehlke.net]
> Sent: Wednesday, July 17, 2002 10:09 AM
> To: David Botham
> Cc: Chris Davis; bind-users at isc.org
> Subject: Re: IP addresses in NS records seem to be breaking hostname
> resolution
> 
> On Wed, Jul 17, 2002 at 09:30:59AM -0400, David Botham wrote:
> >
> > >
> > > 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.
> >
> I think you haevn't had your coffee yet, David ;)

Correct, I am not thinking straight this morning.  After the two follow
up posts I dug into it a little deeper and now see the problem.  Sorry. 


> 
> That's the delegation information from gtld-servers. pacetech-inc's
> servers do in fact have IP addresses in the NS records. That's what
> causes the symptoms the original poster is seeing- the first query
> retrieves properly formatted records from gtld-servers, but the
authority
> section returned from pacetech-inc, which has higer credibility,
> contains bogus NS records.
> 
> >
> > 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?
> 
> Yes, their NS records are wrong. They've also failed to dot-terminate
> the MNAME and RNAME fields in their SOA, they're running ancient and
> vulnerable versions of BIND, and heaven knows what else. It's a wonder
> the zone works at all.
> 
> > > 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...
> >
> His asumption is correct.
> 
> My approach to this, assuming that tacnuke LARTS to pacetech-inc have
> been deflected, would be (and I cringe when I say this; please someone
> tell me a better way...):
> 
> zone "pacetech-inc.com" in {
>         type forward;
>         forward only;
>         forwarders { 209.44.8.1; 216.90.116.7; 209.44.8.6; };
> };
> 
> -Pete