Bind 8.2.3 - Problem with allow-query in options and zone together

Kevin Darcy kcd at daimlerchrysler.com
Tue Jul 31 21:51:46 UTC 2001


Yes, it is a bug in BIND 8, and one that won't be fixed. Dunno whether it
also exists in BIND 9.

In any case, class=ANY (otherwise known as QCLASS=*) is very rare. Why do
you even care?


- Kevin

Michael Kjorling wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I personally would expect BIND to behave this way. The class IN
> (Internet) is the default, but you could just as well spell it out
> like so:
>
>         zone "pirum.com" in { ...
>
> I don't even think there is a class 'any', but I could be wrong on
> that.
>
> Anyway, why are you limiting _queries_ like this? It would make more
> sense to limit only recursion:
>
>         options {
>                 allow-recursion { localhost; };
>         };
>
> Then, you don't have to worry about side effects like this.
>
> Michael Kjörling
>
> On Jul 31 2001 09:15 -0700, Rupert Perry wrote:
>
> >
> > Hi,
> >
> > I have configured my BIND to not allow any queries at the global level
> > (i.e. in options) and then to specifically allow anyone to query one
> > of the zones that my DNS server provides.  According to the BIND
> > documentation, this should mean that all queries are disallowed,
> > except for queries relating to zones provided by my server.
> >
> > This is what a snippet of my config file looks like:
> >
> > options {
> >         allow-query { none; };  // By default no queries are allowed
> > };
> >
> > zone "pirum.com" {
> >         type master;
> >         file "/etc/bind/db.pirum";
> >         allow-query { any; };
> > };
> >
> > Using this set-up, I can perform a normal MX lookup for zone pirum.com
> > without any problems (dig @ns.pirum.com pirum.com mx), but if I repeat
> > the query with the class set to 'any' instead of default value of 'IN'
> > (dig @ns.pirum.com pirum.com mx -c any), the query is refused by BIND
> > .  If I don't set the allow-query global setting in options, the
> > second query returns the same results as the first query, as expected.
> >
> > It seems to me that this is a bug in BIND, as the expected behaviour
> > would be for the MX record detail to be returned for both queries, not
> > just when the class is set to 'IN'.  Am I right in thinking this?
> > Next question - How can I work around this problem without removing
> > the allow-query { none; }; setting from options?
> >
>





More information about the bind-users mailing list