IP addresses in NS records seem to be breaking hostname resolution

[Pete Ehlke]

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

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