Bind not forwarding all requests

[Romgo]

Hello,

I found the issue :

I had 2 old zone with forwarders configured, the forwarders was down.
One equipment was still using one of this zone, so bind wasn't able to
contact the forwarders and fall back to root zone.

I don't really why it try the root zone but since I delete those old zone I
don't have any new queries to the root zone.

According to what I read about "forward only" :

"it doesn't try to contact other name servers to find information if the
forwarders don't give it an answer."

I had exactly opposite behaviour.

Thank you for the help !




On 10 December 2012 11:52, Romgo <romgo at free.fr> wrote:

> Hello all,
>
> I tried to add the forwarders in the root zone :
>
> /etc/bind/named.conf:9: option 'forward' is not allowed in 'hint' zone '.'
> /etc/bind/named.conf:10: option 'forwarders' is not allowed in 'hint' zone
> '.'
> So I really don't understand the behaviour...
>
> Is there a bug tracker for Bind ?
>
> Regards
>
>
>
>
> On 9 December 2012 13:32, Romgo <romgo at free.fr> wrote:
>
>> Hello,
>>
>> yes I have a db.root file which contains Root servers.
>> /etc/resolv.conf is configured to ask to him self.
>>
>> Forward is not configured at zone level, it is specified in
>> named.conf.options
>> In an option{} block, so I guess this should apply for all, if not
>> specify at the zone level.
>>
>> Here is my conf for root zone :
>>
>> // prime the server with knowledge of the root servers
>> zone "." {
>>         type hint;
>>         file "/etc/bind/db.root";
>> };
>>
>>
>> should I try to force forwarders in zone "." ?
>>
>>
>> On 8 December 2012 20:22, Romgo <romgo at free.fr> wrote:
>>
>>> Hello,
>>>
>>> yes I have a db.root file which contains Root servers.
>>> /etc/resolv.conf is configured to ask to him self.
>>>
>>> Forward is not configured at zone level, it is specified in
>>> named.conf.options
>>> In an option{} block, so I guess this should apply for all, if not
>>> specify at the zone level.
>>>
>>> Here is my conf for root zone :
>>>
>>> // prime the server with knowledge of the root servers
>>> zone "." {
>>>         type hint;
>>>         file "/etc/bind/db.root";
>>> };
>>>
>>>
>>> should I try to force forwarders in zone "." ?
>>>
>>>
>>>
>>>
>>> On 8 December 2012 00:26, Leonard Mills <lenm at yahoo.com> wrote:
>>>
>>>>
>>>> Which zone(s) have that forward clause?  To do what I think you want to
>>>> do, the zone should be the root (dot and only the dot in the zone name)
>>>>
>>>> Your named will use the builtin roots for any non-local lookups.
>>>> Forwarding "." will send all non-local traffic to your edge daemon.
>>>>
>>>> Len
>>>>
>>>>   ------------------------------
>>>> *From:* Romgo <romgo at free.fr>
>>>> *To:* bind-users at lists.isc.org
>>>> *Sent:* Friday, December 7, 2012 9:05 AM
>>>> *Subject:* Bind not forwarding all requests
>>>>
>>>> Hello,
>>>>
>>>> I am currently running two bind9 server on Debian Squeeze.
>>>>  1:9.7.3.dfsg-1~squeeze8
>>>>
>>>> Server 1 is internal dns server and serve some local zone. This server
>>>> should forward all unknown requests to our  public DNS server. So I
>>>> configured this server as follow :
>>>> /etc/bind/named.conf.options
>>>>
>>>>   forward only;
>>>>         forwarders {
>>>>           ip_server_2;
>>>>         };
>>>>
>>>>
>>>> The second server is allowed to do DNS request on the internet, so
>>>> there is no forwarder configured.
>>>>
>>>> The issue is that I see on my firewall that server1 is trying to do DNS
>>>> requests on DNS ROOT server.
>>>>
>>>> Any idea why I do have this issue ? wrong configuration ?
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>> unsubscribe from this list
>>>>
>>>> bind-users mailing list
>>>> bind-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20121210/0a167d75/attachment.html>