Zone type forward not caching?

[Jim Reid]

>>>>> "Monte" == mtoren  <mtoren at hotmail.com> writes:

    Monte> I have run into a situation where it appears that bind is
    Monte> not caching answers it is getting from a ‘forward’
    Monte> type zone.  Is this a bug?  Is there a workaround?

If such a situation existed it would be a bug, but where's the
evidence? Have you got an examples where the name server gets an
answer and immediately discards it? Unless the reply packet is badly
mangled or has a zero TTL or something silly like that. Even then, if
it discarded the answer, it should lookup the name again the next time
it was asked for that name.

    Monte> I have recently set up 3 Sun servers (Solaris 2.7), with
    Monte> Bind 8.2.2 P5.  These are mail relay boxes, and need to see
    Monte> the ‘internal’ view of our DNS.  I cannot simply make
    Monte> these servers secondary to our internal zone, as the master
    Monte> is an NT 4.0 server that has allowed many ‘illegal’
    Monte> entries over time.

So fix that. Incorrect data is wrong and should be corrected. And you
should have >1 name server for that internal zone so there's no single
point of failure. Extra name servers also help when there are lots of
queries. Put simply, there are more servers to handle the load.

    Monte> So what I did was to make the internal zones type forward
    Monte> and pointed them to our NT master.  The problem is that
    Monte> these are very high volume mail servers (solicited
    Monte> newsletters to our subscribers), and they overload the NT
    Monte> DNS server.  This shows up as many ‘Relaying denied’
    Monte> errors that pop up when DNS can’t keep up with the mail
    Monte> load (the mail server no longer recognizes the sending host
    Monte> as local).  The errors come at different times of day for
    Monte> the three mail servers, so I know that the NT DNS is up,
    Monte> but just can’t keep up.

I'm not sure that you get these error messages from the mail system
because "the name server can't keep up". Are you sure that the mail
system is configured correctly and the mail headers are correct?
Where's the proof that DNS lookups are failing? Where does your mail
system send its lookups, to a local name server or directly to this NT
box? Do the stats and logs on the name server(s) show significant
numbers of dropped or duplicate queries? Are the mail servers
reporting DNS lookup problems? Maybe you're getting the "relaying
denied" errors because reverse lookups for some of the sending hosts
don't work (or never worked)? Have you set up /etc/nsswitch.conf to
only use DNS for lookups or is all that Solaris NIS+ and nscd cruft in
the way?

    Monte> Any ideas?  I don’t want to use a local hosts table or
    Monte> list my networks in the Sendmail allow file on the mail
    Monte> relays, as this defeats the point of DNS.  I was thinking I
    Monte> either need a way to get the NT zone to load on the Unix
    Monte> boxes (I remember 4.9 has a option to disable name checking
    Monte> for things like underscores – is there something in
    Monte> 8.2.2 for it to ignore problems like CNAME’s with other
    Monte> data?), or is there a way for me to get client side caching
    Monte> to work the way I have it set up now?  Does client side
    Monte> caching work, and I have some other problem?

The check-names option in named.conf can be used to bypass the name
server's checks for illegal hostnames. There's no option to bypass the
"CNAME and other data" checking AFAIK. So you should do the Right
Thing and fix the zone file(s) that are broken because they have names
that exist as CNAMEs and some other resource record types. I suspect
that you may well have other problems that are causing the "Relaying
denied" reports. It's unlikely that your mail servers are processing
messages at a higher rate than your name servers are handling queries
for them. Mail delivery is far more resource hungry than DNS lookups.