Bug 682482

I think I see the problem because I have lines in the named log file like:

06-Mar-2011 18:52:45.886 lame-servers: info: error (no valid RRSIG) resolving 'p3000fedora.lania-intra.net/DS/IN': 192.168.169.4#53
06-Mar-2011 18:52:45.902 lame-servers: info: error (insecurity proof failed) resolving 'p3000fedora.lania-intra.net/A/IN': 192.168.169.4#53
06-Mar-2011 18:55:43.981 lame-servers: info: error (no valid RRSIG) resolving 'hestia.lania-intra.net/DS/IN': 192.168.169.4#53
06-Mar-2011 18:55:44.149 lame-servers: info: error (insecurity proof failed) resolving 'hestia.lania-intra.net/A/IN': 192.168.169.4#53

On both servers, I think I should disable signing checking (since these are internal DNS servers only and not publicly accessible).

So I think in named.conf I should use:

dnssec-enable no;
dnssec-validation yes;

And make use of the "dnssec-must-be-secure" options for the forwarders to bypass the signed checking for both servers, like:

dnssec-must-be-secure "lania-intra.net" no;
dnssec-must-be-secure "169.168.192-in.addr-arpa" no;

Is this assumption right?

Just an update, I disabled dnssec completely on all affected servers since this incident was logged.

To bad no-one has responded yet.

I guess i am the only fool here having this issue with bind.

Some additional information about the situation here:

I have two DNS servers, A and B, on location A and B.

Both locations A and B are connected through a secured IP tunnel over the internet.

Both locations A and B have their own sub-netted networks.

Network A subnet 192.168.168.0/24
Network B subnet 192.168.169.0/24

Routing has been made possible from subnet A to B and vice versa.

For some applications to work properly i need DNS resolution from/to both networks.

I set up on servers A and B both forward entries in named.conf so that DNS resolution from network B is possible from DNS server A and vice versa.

On server A:

zone "169.168.192.in-addr.arpa" {
        type forward;
        forwarders { <IP from DNS server B>; };
        forward first;
};

zone "domain-b.net" IN {
        type forward;
        forwarders { <IP from DNS server B>; };
        forward first;
};

On server B:

zone "168.168.192.in-addr.arpa" {
        type forward;
        forwarders { <IP from DNS server A>; };
        forward first;
};

zone "domain-a.net" IN {
        type forward;
        forwarders { <IP from DNS server A>; };
        forward first;
};


The above has always been working until now that DNSSEC validation has been introduced.

What needs to be done here to get it working back again?

Regards,

Eddie.

I'm not able to reproduce this issue, I set servers as you and they worked fine.

Can you please attach your named.conf (please strip all private data) to this bug? Thank you in advance.

Before I do that i would like to know if it was possible for you on hetwork A to query an ip address or hostname(fqdn) from network B on DNS server A ?

My problem is that if i do that, server A goes to dns server B to query for the host or ip address and it failes with "not found: 3(NXDOMAIN)". And in syslog:
got insecure response; parent indicates it should be secure.

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

acl "linklocalv6" { fe80::/10; };
acl "A" { a.a.a.0/24; 127.0.0.1; xxxx:xx:x:xx00::/64; ::1; };
acl "B" { b.b.b.0/24; };

options {
        listen-on port 53 { 127.0.0.1; a.a.a.a; };
        // listen-on-v6 port 53 { ::1; xxxx:xx:x:xx00:1::4; };
        listen-on-v6 port 53 { "any"; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { "A"; "B"; "linklocalv6"; };
        allow-transfer { "A"; "B"; };
        allow-recursion { "A"; "B"; "linklocalv6"; };
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

};

logging {
        channel default_syslog {
            syslog daemon;
        severity info;
        };
        channel standard_syslog {
            syslog daemon;
            severity dynamic;
        };
        channel named_logfile {
            file "/var/log/named.log";
            print-time yes;
            print-severity yes;
            print-category yes;
            severity dynamic;
        };
        category update { standard_syslog; };
#       category security { default_syslog; };
#       category default { named_logfile; };
        category resolver { named_logfile; };
        category lame-servers { named_logfile; };
        category query-errors { named_logfile; };
        category edns-disabled { named_logfile; };
};

key DHCP_UPDATER {
         algorithm hmac-md5;
         secret [dhcp-hidden-secret-key];
};

zone "." IN {
        type hint;
        file "named.ca";
};


// The A zones

zone "A.net" IN {
        type master;
        file "dynamic/A.net.db";
        allow-update { "A"; key DHCP_UPDATER; };
};

// Provide reverse mappings for zone a.a.a.a

zone "a.a.a.in-addr.arpa" {
        type master;
        file "dynamic/a.a.a.in-addr.arpa.db";
        allow-update { "A"; key DHCP_UPDATER; };
};

// Provide ipv6 reverse mappings too
// zone "xxxx:xx:x:xx00::/64"

zone "0.0.x.x.x.0.0.0.x.x.0.0.x.x.x.x.ip6.arpa" {
        type master;
        file "dynamic/xxxx:xx:x:xx00.ip6.arpa.db";
        allow-update { "A"; key DHCP_UPDATER; };
};


// The server zones

zone "_msdcs.A.net" IN {
        type master;
        file "dynamic/_msdcs.A.net.db";
        allow-update { "A"; };
        check-names ignore;
};

zone "_sites.A.net" IN {
        type master;
        file "dynamic/_sites.A.net.db";
        allow-update { "A"; };
};

zone "_tcp.A.net" IN {
        type master;
        file "dynamic/_tcp.A.net.db";
        allow-update { "A"; };
};

zone "_udp.A.net" IN {
        type master;
        file "dynamic/_udp.A.net.db";
        allow-update { "A"; };
};

// The provider's zone is queueried directly on it's own DNS servers

zone "tweakdsl.nl" IN {
        type forward;
        forwarders { 82.197.196.182; 82.197.196.183; };
        forward first;
};

zone "b.b.b.in-addr.arpa" {
        type forward;
        forwarders { b.b.b.3; };
        forward first;
};

zone "B.net" IN {
        type forward;
        forwarders { b.b.b.3; };
        forward first;
};

# prevent "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA"
# If the IN-ADDR.ARPA name covered refers to a internal address space you are
# using then you have failed to follow RFC 1918 usage rules and are leaking
# queries to the Internet. You should establish your own zones for these
# addresses to prevent you querying the Internet's name servers for these
# addresses. Please see http://as112.net/ for details of the problems you are
# causing and the counter measures that have had to be deployed.

# If you are not using these private addresses then a client has queried for
# them. You can just ignore the messages, get the offending client to stop
# sending you these messages as they are most probably leaking them or setup
# your own zones empty zones to serve answers to these queries.

zone "10.in-addr.arpa" {
        type master;
        file "named.empty";
};

zone "16.172.in-addr.arpa" {
        type master;
        file "named.empty";
};

zone "31.172.in-addr.arpa" {
        type master;
        file "named.empty";
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "named.empty";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Do i need to create trust keys for the forwarders?

(In reply to comment #7)
> Do i need to create trust keys for the forwarders?

It shouldn't be needed. I will try to reproduce this issue again today, with your configuration.

Ok, I was finally able to reproduce your issue. I sent a report to upstream if they consider this behavior as a bug or a feature.

Workaround is to disable DNSSEC validation in named.conf (dnssec-validation off;).

I've just received response from upstream about this issue:

.....
> zone "lania-intra.net" IN {
>         type forward;
>         forwarders { IP_of_the_server_1; };
> };

I'm pretty sure it would work if you made it a slave instead of a forward
zone.

Better yet, change it to "lania.intranet" or something so the global DNS
doesn't step on it.  Or, call up godaddy and register lania-intra.net--it
isn't necessary to make the zone data public, just registering the domain's
existence ought to do the trick.

Essentially, this server is lying to its clients, telling them there's a
zone in .net named lania-intra.  DNSSEC is checking the facts with .net,
and getting a valid signed NXDOMAIN, and calling it on the lie.
.....

In my opinion the best solution for you is to make your zones (when multiple servers serve them) as slave zones. Or register lania-intra.net. and don't make zone data public.

I must close this issue as NOTABUG. Please reopen this ticket if solutions written above don't work.

Adam,

"Workaround is to disable DNSSEC validation in named.conf (dnssec-validation
off;)"

Can I ask for an enhancement?

Could the "dnssec-validation no;" be made able to be used in a forwarders statement instead of (or also as) a global configuration option?

I see many more complaints of bind users that have serious dns resolution problems with forwarders in named.conf that do not have (or support) a dnssec tld validation check.

Also, the question raises to me that if using a .net tld for a private (not public) domain should always need a valid registration at a domain registrar.

elton-intra.net and lania-intra.net are being used this way for more then 10 years now, and i never experienced any such problems.

Please elaborate.

Regards,

Eddie.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Moving to F15.

Additional information was requested for this bug. Adding comment will automatically clear needinfo request. I see, however, no question.

"Workaround is to disable DNSSEC validation in named.conf (dnssec-validation
off;)"

Can I ask for an enhancement?

Could the "dnssec-validation no;" be made able to be used in a forwarders
statement instead of (or also as) a global configuration option?

(In reply to comment #15)
> "Workaround is to disable DNSSEC validation in named.conf (dnssec-validation
> off;)"
> 
> Can I ask for an enhancement?
> 
> Could the "dnssec-validation no;" be made able to be used in a forwarders
> statement instead of (or also as) a global configuration option?

This makes sense, will forward this RFE to upstream.