Bind 9.8 DNS recursion dont work from the client side - Bug?
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?
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?
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
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
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
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
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