Bind 9.8 DNS recursion dont work from the client side - Bug?

2011-05-16 Thread Juergen Dietl
Hello,

I try to make an nslookup from the client. The server dont know the zone and
for this it should do recursion to another DNS-Server

options {
dump-file "/var/log/named_dump.db";
notify-source xx.x.xxx.xxx port 53;
notify yes;
listen-on port 53 { xx.x.xxx.xxx; };
check-names slave ignore;
directory "/";
statistics-file "/var/log/named.stats";
listen-on-v6 { none; };
forwarders { xx.xxx.x.xxx; xx.xxx.x.xxx; };
forward first;
recursion yes;
};


I get back a refused from the server.

When I do a trace the server send the client:

Server can“t do recursive query (flag set).

But when I do a dig on the server on that name I get an answer and I have
the flags:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

qr ... query
rd ... recursive desired
ra ... recursive available

An it asks the right servers.

So why can i do it from the server but not from a client? This is a strange
behavior. Is there a bug in 9.8?
I have no restriction set on the server.

Any idea?
thanx for all your help,
cheers,
Juergen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind 9.8 DNS recursion dont work from the client side - Bug?

2011-05-16 Thread Phil Mayers

On 16/05/11 11:00, Juergen Dietl wrote:

Hello,

I try to make an nslookup from the client. The server dont know the zone
and for this it should do recursion to another DNS-Server

options {
dump-file "/var/log/named_dump.db";
notify-source xx.x.xxx.xxx port 53;
notify yes;
listen-on port 53 { xx.x.xxx.xxx; };
check-names slave ignore;
directory "/";
statistics-file "/var/log/named.stats";
listen-on-v6 { none; };
forwarders { xx.xxx.x.xxx; xx.xxx.x.xxx; };
forward first;
recursion yes;
};


I get back a refused from the server.


You need an allow-recursion ACL. See the ARM for the way that 
allow-recusion, allow-query and allow-query-cache interact.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind 9.8 DNS recursion dont work from the client side - Bug?

2011-05-16 Thread Juergen Dietl
Hello Phil,

thanx a lot for your help.

allow-recursion {any;}; .Works now.

allow-query {any;};
did also work.

Is this a new behavior? Because in 9.7.3 I dont have to allow querys.

thanx a lot,
cheers,
Juergen


2011/5/16 Phil Mayers 

> On 16/05/11 11:00, Juergen Dietl wrote:
>
>> Hello,
>>
>> I try to make an nslookup from the client. The server dont know the zone
>> and for this it should do recursion to another DNS-Server
>>
>> options {
>> dump-file "/var/log/named_dump.db";
>> notify-source xx.x.xxx.xxx port 53;
>> notify yes;
>> listen-on port 53 { xx.x.xxx.xxx; };
>> check-names slave ignore;
>> directory "/";
>> statistics-file "/var/log/named.stats";
>> listen-on-v6 { none; };
>> forwarders { xx.xxx.x.xxx; xx.xxx.x.xxx; };
>> forward first;
>> recursion yes;
>> };
>>
>>
>> I get back a refused from the server.
>>
>
> You need an allow-recursion ACL. See the ARM for the way that
> allow-recusion, allow-query and allow-query-cache interact.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Dual-stack BIND resolver behaviour

2011-05-16 Thread Dennis Perisa
Hi folks,

We are looking to dual-stack our 9.7.3 DNS resolvers and I had a
question about BIND's behaviour in a dual-stack configuration.

Assuming the resolver's cache is empty, will a query that arrives on
an IPv6 socket always result in an outgoing query to a root server's
IPv6 address? I have the same question for IPv4 queries.

Dennis
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Dual-stack BIND resolver behaviour

2011-05-16 Thread Anand Buddhdev
On 16/05/2011 14:11, Dennis Perisa wrote:

> Hi folks,
> 
> We are looking to dual-stack our 9.7.3 DNS resolvers and I had a
> question about BIND's behaviour in a dual-stack configuration.
> 
> Assuming the resolver's cache is empty, will a query that arrives on
> an IPv6 socket always result in an outgoing query to a root server's
> IPv6 address? I have the same question for IPv4 queries.

Hi Dennis,

There's no relation between incoming recursive queries, and the outgoing
queries BIND makes to look for answers.

Whether BIND contacts the IPv4 or IPv6 address of a server (including
the root servers) depends on the latency to that server.

Regards,

Anand Buddhdev
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Dual-stack BIND resolver behaviour

2011-05-16 Thread lst_hoe02

Zitat von Anand Buddhdev :


On 16/05/2011 14:11, Dennis Perisa wrote:


Hi folks,

We are looking to dual-stack our 9.7.3 DNS resolvers and I had a
question about BIND's behaviour in a dual-stack configuration.

Assuming the resolver's cache is empty, will a query that arrives on
an IPv6 socket always result in an outgoing query to a root server's
IPv6 address? I have the same question for IPv4 queries.


Hi Dennis,

There's no relation between incoming recursive queries, and the outgoing
queries BIND makes to look for answers.

Whether BIND contacts the IPv4 or IPv6 address of a server (including
the root servers) depends on the latency to that server.


Does the latency apply per IP or per Hostname? If per Hostname the  
IPv6 address will be prefered in case the root servers are reachable  
by both IPv4 and IPv6, no? Also first connection will be tried with  
IPv6 on most OS, no?


Regards

Andreas


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


9.8.0-P1 platform.h questions

2011-05-16 Thread Dennis Clarke

I compiled 9.8.0-P1 on both 32-bit and 64-bit Solaris Sparc and the output
in all the header files looks identical with the exception of platform. I
expect to see things like this :

The 32-bit build results in :

 #define ISC_PLATFORM_QUADFORMAT "l"

The 64-bit build platform.h has this :

 #define ISC_PLATFORM_QUADFORMAT "ll"


That seems perfectly fine and reasonable.


Not so reasonable is this :

#undef ISC_PLATFORM_HAVEIFNAMETOINDEX

  versus

#define ISC_PLATFORM_HAVEIFNAMETOINDEX 1

The compile was done on the same server with either CFLAGS having 
-xarch=v9 for 64-bit and then  -xarch=v8 for the 32-bit builds. Everything
seems fine but this server does have if_nametoindex(3XNET) as well as
if_nametoindex(3NSL) where the 3xnet libs are "X/Open Networking Services
Library Functions".

Why would platform.h be so different as there were a multitude of such
differences?


-- 
Dennis Clarke
dcla...@blastwave.org


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users