non-improving referral

[Leo Baltus]

Op 28/10/2010 om 09:16:33 +0200, schreef Leo Baltus:
> Op 28/10/2010 om 13:38:13 +1100, schreef Mark Andrews:
> > In message <20101026161348.GJ2341 at omroep.nl>, Leo Baltus writes:
> > > We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2.
> > > 
> > > We have our authoritative servers migrated to bind-9.7.2-P2 and it all
> > > seems to work fine.
> > > 
> > > While testing our caching resolvers with bind-9.7.2-P2 however, we
> > > noticed some errors in our logfiles we have never seen before.
> > > 
> > > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 resolvi
> > > ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re
> > > ferral
> > > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolvi
> > > ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re
> > > ferral
> > > 
> > > Obviously I have obscured some data here :) As you may guess this is a
> > > query for a TXT record from a blocklist-daemon.
> > > 
> > > The nameservers on 1.5.3.4 and 1.5.2.2 are bind-9.7.2-P2.
> > > 
> > > The queried domains are hosted by us and the hopefully relevant part of
> > > the zone looks like this:
> > > 
> > > x.y.z.example.com.   IN NS   bl1a.example.com.
> > > x.y.z.example.com.   IN NS   bl1b.example.com.
> > > 
> > > A dump of the cache shows NS and A records are in the cache for bl1[ab]
> > > however, on each non-cached query from the client both errorlines
> > > are printed in the log suggesting the resolver is not using the cached
> > > NS records.
> > > 
> > > The client receives a valid answer, so my only real problem seems to be
> > > the amount of spam I get in our logfiles.
> > > 
> > > The blocklist is served by rbldnsd, manually query-ing gives my a
> > > valid response.
> > > 
> > > Could anybody tell me what problem bind is complaining about?
> > > 
> > > Please CC me as I am not on this list.
> > 
> > Run "dig +trace +all 1.2.4.2.x.y.z.example.com txt" and look at the
> > results.  Somewhere in that chain there will be a broken delegation.
> > This may manifest itself as a authority section in the reply that
> > doesn't match the delegation.
> 
> 
> The only thing that doesn't match is the TTL, 7200 on the delegation,
> 300 on the authoritative side.
> 

The problem was a forward zone in our caching-only-set-up:

zone "example.com" {
        type forward;
        forwarders { 1.5.3.4; 1.5.2.2; };
};

The idea was to always be able to resolve example.com even during
network outages, so not be dependant on the accessibility of root
nameservers. It seems later subdomains were added for blocklists.

I have removed this zone from this caching-only server, fixing the non-
improving referral issue.

Questions remains however: considering we want a strict separation
between recursive and authoritative servers, how can we tell the
recursive server to always resolve example.com at 1.5.3.4/1.5.2.2 and
yet allow delegations as well (and maybe even dnssec).

I have tried to use hint zones. Like so:

zone "example.com" { type hint; file "/etc/named/myhints"; };

/etc/named/myhints:
@                        7200  IN  NS    ns1.example.com.
@                        7200  IN  NS    ns2.example.com.
ns1.example.com.         7200      A     1.5.3.4
ns2.example.com.         7200      A     1.5.2.2

So after a reboot during a network outage the cache gets populated with
enough information to get example.com resolving.
But it seems 'hint' only work for the root "." zone.

Any comments?

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer at omroep.nl, 035-6773555                         \/