Re: DNS performance Help when query log is off -- which default parameters will impact the DNS performance
Google search for "man named" turns up: https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named.html which says (among more details): named [-4] [-6] [-c config-file] [-d debug-level] [-E engine-name] [-f] [-g] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-x cache-file] For more explanation, look at: https://kb.isc.org/article/AA-01249/0/UDP-Listeners-choosing-the-right-value-for-U-when-starting-named.html On Thu, 22 Feb 2018 01:50:22 + "PENG, JUNAN" wrote: > Hi, Paul > > UDP listeners per interface > > Do you know how to modify this parameter -- UDP listeners per > interface > > version: BIND 9.10.5-S1 (Unknown) > boot time: Tue, 13 Feb 2018 06:12:53 GMT > last configured: Tue, 13 Feb 2018 06:12:53 GMT > CPUs found: 4 > worker threads: 4 > UDP listeners per interface: 3 > number of zones: 102 > debug level: 0 > xfers running: 0 > xfers deferred: 0 > soa queries in progress: 0 > query logging is OFF > recursive clients: 0/900/1000 > tcp clients: 0/15000 > server is up and running > > BR > Michael ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS performance Help when query log is off -- which default parameters will impact the DNS performance
You may further be interested in Bind statistics for analysis of the Bind server behaviour under load. Look at an example here what metrics are avialable in general: https://github.com/lukas999/bind2pmda If you wanted to use even the PMDA, forget the github source as the PMDA is now part of the Performance CoPilot (pcp.io). Overall, it would be good, if you did some basic checks: - per thread utilization of the CPU - how do the errors start to demostrate when you get over the maximum throughput you achieved (timeouts?, errors?) - how about the socket count? Is is close to the exhaustion? Then, the conditions of your test may be of interest: - what kind of queries do you use for you test (A, TXT, AAA, UPDATE ... ?) - what load generator do you use and how does it behave (e.g. in the range from dig in loop to asynchronous handling)? Best regards Lukas Paul Kosinski writes: > Google search for "man named" turns up: > > https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named.html > > which says (among more details): > > named [-4] [-6] [-c config-file] [-d debug-level] [-E engine-name] [-f] > [-g] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks] > [-t directory] [-U #listeners] [-u user] [-v] [-V] [-x cache-file] > > For more explanation, look at: > > > https://kb.isc.org/article/AA-01249/0/UDP-Listeners-choosing-the-right-value-for-U-when-starting-named.html > > > > On Thu, 22 Feb 2018 01:50:22 + > "PENG, JUNAN" wrote: > >> Hi, Paul >> >> UDP listeners per interface >> >> Do you know how to modify this parameter -- UDP listeners per >> interface >> >> version: BIND 9.10.5-S1 (Unknown) >> boot time: Tue, 13 Feb 2018 06:12:53 GMT >> last configured: Tue, 13 Feb 2018 06:12:53 GMT >> CPUs found: 4 >> worker threads: 4 >> UDP listeners per interface: 3 >> number of zones: 102 >> debug level: 0 >> xfers running: 0 >> xfers deferred: 0 >> soa queries in progress: 0 >> query logging is OFF >> recursive clients: 0/900/1000 >> tcp clients: 0/15000 >> server is up and running >> >> BR >> Michael > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
Just wanted to follow up 9.12.1b1 fixes this issue for me. Thanks, -Nick ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
I apologize, I sent the previous email in error. This is what I get for having so many revisions of named sitting around on one server, I was not running 9.12.1b1 when I tested this. I will be more careful in the future. I just tested this with 9.12.1b1 and it still fails, the same as 9.12. I do understand that the function of rs.dns-oarc.net is to test things that can no longer be tested in 9.12, but regardless I should still be able to resolve the nameservers for rs.dns-oarc.net, right? Is anyone on 9.12 able to do this? Is this just my problem? Thank you again, -Nick -Original Message- From: NNEX Support Sent: Thursday, February 22, 2018 8:21 AM To: 'bind-users@lists.isc.org' Subject: RE: Issue running "dig txt rs.dns-oarc.net" on 9.12 Just wanted to follow up 9.12.1b1 fixes this issue for me. Thanks, -Nick ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
procedure to change database encryption with file_key_management plugin?
I've built mysqld -V mysqld Ver 10.2.14-MariaDB-log for Linux on x86_64 (Source distribution) I'm setting up encryption, following https://mariadb.com/kb/en/library/encryption/ https://mariadb.com/kb/en/library/data-at-rest-encryption/ I created my key file openssl rand -hex 32 b650adbc0c5df1bc3e766b4b65f26dc76c76ed81b955bbedaf50e1d4e16fc732 /etc/mariadb/keys.txt 1;b650adbc0c5df1bc3e766b4b65f26dc76c76ed81b955bbedaf50e1d4e16fc732 encrypted it openssl enc -aes-256-cbc -k 'test_passphrase' -md sha1 -in /etc/mariadb/keys.txt -out /etc/mariadb/keys.enc verified it openssl aes-256-cbc -d -md sha1 -k 'test_passphrase' -in /etc/mariadb/keys.enc 1;b650adbc0c5df1bc3e766b4b65f26dc76c76ed81b955bbedaf50e1d4e16fc732 I've enabled "everything" encryption using that keyfile [mysqld] plugin_dir=/opt/mariadb/lib/plugin plugin-load-add=file_key_management file-key-management file_key_management_encryption_algorithm=aes_ctr file_key_management_filekey = 'test_filekey' file_key_management_filename = /etc/mariadb/enc/keys.enc aria-encrypt-tables = 1 encrypt-binlog = 1 encrypt-tmp-disk-tables = 1 encrypt-tmp-files = 1 innodb_default_encryption_key_id = 1 innodb-encrypt-log = off innodb-encrypt-tables = on innodb-encryption-threads = 4 innodb-tablespaces-encryption = 1 verified the plugin loads mysql -e "show plugins;" | grep ENC INNODB_TABLESPACES_ENCRYPTION ACTIVE INFORMATION SCHEMA NULL BSD file_key_management ACTIVE ENCRYPTION file_key_management.so GPL on startup it looks like it starts up ok 2018-02-21 13:01:29 139729003899072 [Note] InnoDB: 5.7.21 started; log sequence number 7206290786 2018-02-21 13:01:29 139729003899072 [Note] InnoDB: Creating #1 encryption thread id 139727810316032 total threads 4. 2018-02-21 13:01:29 139729003899072 [Note] InnoDB: Creating #2 encryption thread id 139727801923328 total threads 4. 2018-02-21 13:01:29 139727818708736 [Note] InnoDB: Loading buffer pool(s) from /home/data/db/ib_buffer_pool 2018-02-21 13:01:29 139729003899072 [Note] InnoDB: Creating #3 encryption thread id 139727793530624 total threads 4. 2018-02-21 13:01:29 139729003899072 [Note] InnoDB: Creating #4 encryption thread id 139727785137920 total threads 4. 2018-02-21 13:01:29 139727818708736 [Note] InnoDB: Buffer pool(s) load completed at 180222 13:01:29 2018-02-21 13:01:29 139729003899072 [Note] Using encryption key id 1 for temporary files 2018-02-21 13:01:29 139729003899072 [Note] Server socket created on IP: '127.0.0.1'. 2018-02-21 13:01:29 139729003899072 [Note] Reading of all Master_info entries succeded 2018-02-21 13:01:29 139729003899072 [Note] Added new Master_info '' to hash table 2018-02-21 13:01:29 139729003899072 [Note] /opt/mariadb/bin/mysqld: ready for connections. Version: '10.2.14-MariaDB-log' socket: '/var/cache/mariadb/mariadb.sock' port: 3306 Source distribution and verified table encryption mysql -e "SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION;" +---+---+---++-+-+--+--++--+ | SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING | +---+---+---++-+-+--+--++--+ | 1375 | mysql/gtid_slave_pos | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 | | 1465 | mysql/innodb_index_stats | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 | | 1466 | mysql/innodb_table_stats | 1 | 1 | 1 | 1 | NULL | NULL | 1 |
FFS, completely wrong list ::facepalm::
sorry all. coffee. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
I'm sorry to keep replying to myself but I believe I've found the line of code that is causing this issue. Looking at validator.c, in the check_deadlock function, 9.12.0rc1 says: ... if (parent->event != NULL && parent->event->type == type && dns_name_equal(parent->event->name, name) && ... 9.12.0rc3 and above says: ... if (parent->event != NULL && (parent->event->type == type || parent->event->type == dns_rdatatype_cname) && dns_name_equal(parent->event->name, name) && ... By removing "parent->event->type == dns_rdatatype_cname)" (and adjusting the rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" works. I see this commit related to this line of code: https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b88824290fbf1c18f2cc I'm sure this line of code is important, otherwise it wouldn't be there and I don't know enough to be removing random bits of code, so of course I'd never run this in production. Still I want to understand why this is happening and if it’s a bug or me not understanding DNS properly. As always thank you for your time! -Nick ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-9.9.5 exits (due to assertion failure)
Hello, we are running bind-9.9.5 on Ubuntu 14.04.5 LTS. bind was installed from apt-repository (exact version is BIND 9.9.5-3ubuntu0.17-Ubuntu). Today, named died suddenly with the following message: Feb 22 17:32:28 ns1 named[1057]: adb.c:1142: INSIST((adb->entries[bucket]).head == (entry)) failed, back trace Feb 22 17:32:28 ns1 named[1057]: #0 0x7fbd9c95538d in ?? Feb 22 17:32:28 ns1 named[1057]: #1 0x7fbd9b8898ba in ?? Feb 22 17:32:28 ns1 named[1057]: #2 0x7fbd9c13f855 in ?? Feb 22 17:32:28 ns1 named[1057]: #3 0x7fbd9c1570a6 in ?? Feb 22 17:32:28 ns1 named[1057]: #4 0x7fbd9c20a313 in ?? Feb 22 17:32:28 ns1 named[1057]: #5 0x7fbd9c21460a in ?? Feb 22 17:32:28 ns1 named[1057]: #6 0x7fbd9c215ece in ?? Feb 22 17:32:28 ns1 named[1057]: #7 0x7fbd9b8abad6 in ?? Feb 22 17:32:28 ns1 named[1057]: #8 0x7fbd9b25b184 in ?? Feb 22 17:32:28 ns1 named[1057]: #9 0x7fbd9ac2203d in ?? Feb 22 17:32:28 ns1 named[1057]: exiting (due to assertion failure) Is there any known bug triggering this behaviour ? Thanks in advance. Regards, Alex ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Unclear behavior with option "lame-ttl 0;"
Hi While testing the option "lame-ttl" with values 0 (disable) or any value higher zero on our resolver, I'm unsure, if I missed something (BIND 9.11.2): lame-ttl defines the time in seconds, how long a lame-server-entry should be cached and therefore not should be further asked (because it seems to be down). See http://www.zytrax.com/books/dns/ch7/hkpng.html#lame-ttl If BIND recognizes a lame-server (written in the logfile), the corresponding server will not be contacted for authoritative queries. If I set the value "lame-ttl 0;", which means, caching lameservers will be disabled, then I would expect, that BIND will do "round-robin"-queries to all authoritative servers of a zone (includes the down-one). BUT: BIND still would have a notice of the lame-server (written in the log) and this server will still *NOT* be contacted for lookups. I've tested with simple iptables-rules on my resolver, which are blocking outbound-connections to one or more authoritative servers of a zone for simulating the "lame-servers"-behavior. Any explanation or hints for this (mis)-behavior? Thank you. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
