non-improving referral
Leo Baltus
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 resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving referral
Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving referral
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.
--
Leo Baltus, internetbeheerder /\
NPO ICT Internet Services /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/
beh...@omroep.nl, 035-6773555 \/
Barry Margolin
Leo Baltus <Leo.B...@omroep.nl> wrote:
> Hi,
>
> 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
> resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637:
> non-improving referral
> Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53
> resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637:
> non-improving referral
>
> 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.
It *is* using these NS records. It's complaining that there's a problem
with the responses these machines are sending.
> 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.
I think what it's complaining about is that the response to the query is
a referral to the same or a higher level in the DNS hierarchy. It
should be either an ordinary response, a referral to nameservers for a
subzone, or an NXDOMAIN.
Can you post the result of "dig 1.2.4.2.x.y.z.example.com
@bl1a.example.com +norec"?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mark Andrews
In message <2010102616...@omroep.nl>, Leo Baltus writes:
> Hi,
>
> 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
>
> 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 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.
> --
> Leo Baltus, internetbeheerder /\
> NPO ICT Internet Services /NPO/\
> Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/
> beh...@omroep.nl, 035-6773555 \/
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Leo Baltus
Op 28/10/2010 om 13:38:13 +1100, schreef Mark Andrews:
The only thing that doesn't match is the TTL, 7200 on the delegation,
300 on the authoritative side.
Leo Baltus
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?