Querying directly a nameserver works, while forwarding not

[Daniele Imbrogino]

Hi all.

I just installed BIND9 via 'apt-get install' and for the moment I just want to use it as cache-server.

The only thing I've edited is the forwarders section on the options statement in '/etc/bind/named.conf.options', adding as forwarders 10.0.2.3, a working nameserver on my private network.

I restarted BIND9 and then I tried, for example, 'dig www.apple.com' obtaining "connection timed out; no servers could be reached".

But if I try 'dig @10.0.2.3 www.apple.com' it works correctly and I obtain the correct answer.

Why? How can I resolve this problem?

Thank you.

[Noel Butler]

On Wed, 2012-12-05 at 10:23 +0100, Daniele Imbrogino wrote:

/etc/bind/named.conf.option

WTF is that file?  it certainly is not an ISC named file.

if you are using some butchered to buggery distros file, please ask on your distros mailing list
we are not to know what that file contains, or expects

[Hauke Lampe]

On 05.12.2012 10:23, Daniele Imbrogino wrote:

> I restarted BIND9 and then I tried, for example, 'dig www.apple.com'
> obtaining "connection timed out; no servers could be reached".
> But if I try 'dig @10.0.2.3 www.apple.com' it works correctly and I obtain
> the correct answer.
>
> Why? How can I resolve this problem?

Look at your resolv.conf and make sure that it actually directs queries
to your newly installed BIND.

Check the log for mentions of rejected queries, even though those
shouldn't result in a timeout. The default configuration allows
recursive queries from localhost and your local network.

If all else fails, trace the query packets with tcpdump and find out
where they end up.


Hauke.

[Matus UHLAR - fantomas]

>On Wed, 2012-12-05 at 10:23 +0100, Daniele Imbrogino wrote:
>> /etc/bind/named.conf.option

On 05.12.12 21:47, Noel Butler wrote:
>WTF is that file? it certainly is not an ISC named file.

It's file containing the options section, installed by default in debian.
From the changelog:

* Do options definitions in /etc/bind/named.conf.options, makes life
easier in the face of named.conf changes from upstream.

>if you are using some butchered to buggery distros file, please ask on
>your distros mailing list
>we are not to know what that file contains, or expects

it should only contain the options { }; directive with included options.

The bad part is when someone maintains multiple servers with similar
settings, only the differing options should be included in external file,
with common options in main config file.

debian uses:

- named.conf

// no host-specific options
include "named.conf.options"

- named.conf.options

options {
listen-on "...";
};


I used instead:

- named.conf:

options {
// common.options
...
include "named.conf.options";
};

- named.conf.options:
// host-specific options
listen-on "...";

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".

[Daniele Imbrogino]

resolv.conf contains only 127.0.0.1 as nameserver.

The syslog contains a lot of errors as "insecurity proof failed", "no valid RRSIG", "got insecure response" that I don't understand.

[Hauke Lampe]

Your forwarder probably doesn't handle DNSSEC responses well. Therefore
your BIND cannot validate the answers and returns a failure code.

Either update the forwarder/enable DNSSEC (older versions of BIND 9
require "dnssec-enable yes;" in the options clause), or disable DNSSEC
validation in your local BIND (set "dnssec-validation no;").



Hauke

[Sten Carlsen]

Or consider not doing forwarding, that usually gives fewer problems if possible.

Hauke

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

[Daniele Imbrogino]

I'm testing new configuration on VirtualBox following the advice of not forwarding.

Furthermore, I exclude any reference to DNSSEC.

So, in these conditions and assuming an empty cache, if I query for a remote domain name, my server should query a root-server and then iterate, right?

Well, Wireshark shows me outcoming queries and incoming responses to/from root-servers, but "dig www.apple.com" (for example) fails with a timeout.

"syslog" has a lot of "DNS format error ... non-improving referral" and "error (FORMERR) resolving" entries.

This is my very vary basic "named.conf" file

options {
        directory "/var/cache/bind";
}

zone "." {
        type hint;
        file "/etc/bind/db.root";
};

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

I've also updated "db.root" from ftp.internic.net/domain/db.cache

2012/12/5 Sten Carlsen <st...@s-carlsen.dk>

[Sten Carlsen]

My next move would be to look for issues in the network, I would look at what wireshark can sniff out. I would look for packets with errors. The purpose is to find out if the network is mangling packets.

[Mark Andrews]

In message <CAL_2sc0MnJtUYiakXx71hMN5...@mail.gmail.com>, Daniele Imbrogino writes:
> I'm testing new configuration on VirtualBox following the advice of not
> forwarding.
> Furthermore, I exclude any reference to DNSSEC.
>
> So, in these conditions and assuming an empty cache, if I query for a
> remote domain name, my server should query a root-server and then iterate,
> right?
> Well, Wireshark shows me outcoming queries and incoming responses to/from
> root-servers, but "dig www.apple.com" (for example) fails with a timeout.
>
> "syslog" has a lot of "DNS format error ... non-improving referral" and
> "error (FORMERR) resolving" entries.

Find the "transparent" DNS cache and nuke it. Most site that do
this deploy a ordinary DNS recursive server and that DOES NOT work
with recursive server expecting to be talking to authoritative
servers.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org