Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 577
    • Issues 577
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 117
    • Merge requests 117
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #597
Closed
Open
Issue created Oct 15, 2018 by Oleg Gorokhov@oleg.gorokhov

bind 9.13 rpz regression?

Summary

Not all requests that should be processed by rpz rules are in fact processed. We have comparison between bind 9.11.4 and bind 9.13.3 showing that rpz in 9.13.3 does not work as expected. The request speed ~ 10-20rps

BIND version used

BIND 9.13.3 (Development Release) <id:c93acb9949>
running on Linux x86_64 4.14.69-27 #1 SMP Tue Sep 11 12:26:58 UTC 2018
built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-tuning=large' '--enable-static' '--enable-symtable=all' '--enable-largefile' '--enable-shared' '--with-libtool' '--with-gnu-ld' '--with-randomdev=/dev/random' '--enable-threads' '--enable-ipv6' '--disable-chroot' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=no' '--with-dlz-filesystem=no' '--with-dlz-ldap=no' '--with-dlz-odbc=no' '--with-dlz-stub=no' '--with-gssapi=no' '--with-openssl' '--with-pkcs11=no' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
compiled by GCC 7.3.0
compiled with OpenSSL version: OpenSSL 1.1.0g  2 Nov 2017
linked to OpenSSL version: OpenSSL 1.1.0g  2 Nov 2017
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with libjson-c version: 0.12.1
linked to libjson-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled

Steps to reproduce

Bind configuration has a forwarder and rpz trying to delete A records from (in our case) dns64 responses (returning to a client responses only with AAAA in the end):

forwarders {
        ::1 port 1175;
};
forward only;
response-policy { zone "skipnetworks"; } break-dnssec yes;

"skipnetworks" zone has corresponding format for that (with some exceptions in the end)

$TTL 1H
@                       SOA LOCALHOST. aaaa-only.example.com (1 1h 15m 30d 2h)
                        NS  LOCALHOST.
8.0.0.0.0.rpz-ip                CNAME   *.
8.0.0.0.1.rpz-ip                CNAME   *.
8.0.0.0.2.rpz-ip                CNAME   *.
8.0.0.0.3.rpz-ip                CNAME   *.
8.0.0.0.4.rpz-ip                CNAME   *.
...
8.0.0.0.255.rpz-ip              CNAME   *.
8.0.0.0.10.rpz-ip               CNAME   rpz-passthru.
8.0.0.0.127.rpz-ip              CNAME   rpz-passthru.

dns64 responses are generated in their turn from dns64-enabled forwarder bind (that instance generate both A and AAAA - ordinary and synthesized) started on "::1 port 1175").

What is the current bug behavior?

9.13.3 logging shows that some attempts of the same request are NOT processed by rpz (but of course SHOULD), looks like:

01-Oct-2018 16:05:42.549 queries: client @0x7f8cfc3b7330 2a02:6b8:0:XXXX:bc82:e819:5410:d4a9#36624 (YYYYY.yandex.net): query: YYYYY.yandex.net IN A +E(0)DC (2a02:6b8:0:ZZZ::5005)
01-Oct-2018 16:06:48.219 queries: client @0x7f8cfc3b7530 2a02:6b8:0:XXXX:bc82:e819:5410:d4a9#3124 (YYYYY.yandex.net): query: YYYYY.yandex.net IN A +E(0)DC (2a02:6b8:0:ZZZ::5005)
01-Oct-2018 16:06:48.219 rpz: client @0x7f8cfc3b7530 2a02:6b8:0:XXXX:bc82:e819:5410:d4a9#3124 (YYYYY.yandex.net): rpz IP NODATA rewrite YYYYY.yandex.net via 8.0.0.0.141.rpz-ip.skipnetworks

fqdn YYYYY.yandex.net has A record from network 141.0.0.0/8 and should be eliminated.

What is the expected correct behavior?

We expected correct behavior as we observe in bind 9.11.4:

  • 9.11.4 logging shows that every response/request is processed:
02-Oct-2018 11:49:14.255 queries: client @0x7f27a0017d40 2a02:6b8:c0e:XXXX:0:627:e890:e2d7#4123 (YYYYY.yandex.net): query: YYYYY.yandex.net IN A +E(0)DC (2a02:6b8:0:ZZZ::5005)
02-Oct-2018 11:49:14.255 rpz: client @0x7f27a0017d40 2a02:6b8:c0e:XXXX:0:627:e890:e2d7#4123 (YYYYY.yandex.net): rpz IP NODATA rewrite YYYYY.yandex.net via 8.0.0.0.141.rpz-ip.skipnetworks
02-Oct-2018 11:52:23.554 queries: client @0x7f270403ba60 2a02:6b8:c0e:XXXX:0:627:e890:e2d7#42427 (YYYYY.yandex.net): query: YYYYY.yandex.net IN A +E(0)DC (2a02:6b8:0:ZZZ::5005)
02-Oct-2018 11:52:23.554 rpz: client @0x7f270403ba60 2a02:6b8:c0e:XXXX:0:627:e890:e2d7#42427 (YYYYY.yandex.net): rpz IP NODATA rewrite YYYYY.yandex.net via 8.0.0.0.141.rpz-ip.skipnetworks
...

Relevant configuration files

options {

        directory "/var/cache/bind-aaaa";
        pid-file "/var/run/named-aaaa/named.pid";
        session-keyfile "/var/run/named-aaaa/session.key";

        auth-nxdomain no;    # conform to RFC1035
        listen-on port 53 { none; };
        listen-on-v6 port 53 { 2a02:6b8:0:XXXX::5005; 2a02:6b8:0:XXXX:1023; };
        allow-query { any; };
        allow-recursion { any; };
        no-case-compress { any; };

        forwarders {
                ::1 port 1175;
        };
        forward only;
        response-policy { zone "skipnetworks"; } break-dnssec yes; 

        recursive-clients 6000; # default 1000
        tcp-clients 1024;

        statistics-file "/var/tmp/named-stats/named-aaaa-only.stats";
};
zone "skipnetworks" {type master; file "skipnetworks"; allow-query {none;}; };

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem.)

Edited Oct 15, 2018 by Oleg Gorokhov
Assignee
Assign to
Time tracking