Re: tool for finding undelegated children in your DNS
I have been told this is a very poor description of the problem. What I am concerned about is, how people with a sort of lazy zone file can assess the potential impact of QNAME minimization on their ability to answer for all of their zones. I have gotten two suggestions off list: - I would use named-checkzone to print the zone with all owner names printed out and then use text processing tools - “dig ds -f list-of-zones”, Those that return NXDOMAIN are likely missing NS records. Any other ideas? Has anyone done this kind of housekeeping on their own zones? > On Jul 26, 2018, at 11:41 AM, Victoria Risk wrote: > > Does anyone know of a good tool that you can run on your DNS records to find > parent + child pairs where there is no NS record for the child in the parent? > > Someone must have a perl script for that, right? > > Thank you for any suggestions. > > Vicky > > > > > > ___ > 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 Victoria Risk Product Manager Internet Systems Consortium vi...@isc.org ___ 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: dnssec-signzone sometimes does lowercase DNSSEC records
> On 27 Jul 2018, at 1:34 am, Daniel Stirnimann > wrote: > > Hello all, > > dnssec-signzone (BIND 9.12.2) sometimes does lowercase DNSSEC records. > This seems a problem especially for NSEC records which are case > sensitive. dnssec-verify is moaning with errors like this: The case of the names doesn’t matter from a protocol perspective. > Bad NSEC record for ipad-rigi-2.switch.ch, bit map mismatch Which is the bit map of types in NSEC record. This should be independent of the case of the names. > Example: > > dnssec-signzone -o switch.ch. switch.ch Kswitch.ch.+013+44373.private > > Output, note that ipv4.switch.ch is originally written as IPv4.switch.ch > but the DNSSEC records are all in lowercase. > ... > IPv4.switch.ch. 86400 IN APL 1:0.0.0.0/0 > ipv4.switch.ch. 86400 IN RRSIGAPL 13 3 86400 > 20180817132852 20180726134251 44373 switch.ch. > mf2CacXrMqsePVoC+WvjX4CHcJBBP6CZPmzl1LXj5X6pNVVb2T7DzzsZ > PvvflRNol1sYSyxtn0Tlv8BFqYsISA== > ipv4.switch.ch. 180 IN NSEC cam.ipv4.switch.ch. APL > RRSIG NSEC > ipv4.switch.ch. 180 IN RRSIG NSEC 13 3 180 > 20180823223316 20180726134251 44373 switch.ch. > zxGwOJsnbK4OEDqlyQ/Hxea3m/W2aFwg2OKDos1u6rJNTW64Gp6cg3Ce > EiNX3JY9VMsKXAFsGYKjnjtzNM/VEA== > ipad-rigi-2.switch.ch.86400 IN A130.59.97.30 > ipad-rigi-2.switch.ch.86400 IN RRSIGA 13 3 86400 > 20180814152223 20180726134251 44373 switch.ch. > AsQJ3ONoS19evdbsIf3Xkfs+s66cFc3KVLrTvK3BA1kqZKTKUwdz1iqs > vSPVtF7SjcBfVQU71a8FDUtjOfrCtg== > ipad-rigi-2.switch.ch.86400 IN LOC 47 22 23.970 N 8 31 > 52.201 E 415.00m 1m 1m 10m > ipad-rigi-2.switch.ch.86400 IN RRSIGLOC 13 3 86400 > 20180815150750 20180726134251 44373 switch.ch. > 1/co/914PvPKscFDM+tveLuywfnnTmkjv8vfZlPUY/wwGWugcDcOMvP4 > B2ldHp2T8GPv1cbCSQG1/ibWAbR5WQ== > ipad-rigi-2.switch.ch.180 IN NSEC ipv4.switch.ch. A > LOC RRSIG NSEC > ... > > > Is this bug related to https://gitlab.isc.org/isc-projects/bind9/issues/420 > > I guess, I could start to lowercase all owner names or move to NSEC3. I > tested both approaches and they work. or just turn off the added internal verification step until the issue with it is fixed. dnssec-signzone -P Can you file a bug report please. Mark > Daniel > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: SERVFAIL and peak utilization
Hi, here is some further debugging on what I believe are queries
involving SERVFAIL:
26-Jul-2018 17:44:40.168 query-errors: debug 1: client @0x7fbee80f39b0
127.0.0.1#61547 (69.248.70.96.bad.psky.me): query failed (SERVFAIL)
for 69.248.70.96.bad.psky.me/IN/A at ../../../bin/named/query.c:8580
26-Jul-2018 17:44:40.168 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for 69.248.70.96.bad.psky.me/A in
10.96: timed out/success
[domain:psky.me,referral:1,restart:2,qrysent:4,timeout:3,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
26-Jul-2018 17:44:40.172 query-errors: debug 1: client @0x7fbed81218a0
127.0.0.1#61547 (176.216.85.209.psbl.surriel.com): query failed
(SERVFAIL) for 176.216.85.209.psbl.surriel.com/IN/A at
../../../bin/named/query.c:8580
26-Jul-2018 17:44:40.172 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for 176.216.85.209.psbl.surriel.com/A
in 10.000128: timed out/success
[domain:psbl.surriel.com,referral:2,restart:1,qrysent:2,timeout:1,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
26-Jul-2018 17:44:40.173 query-errors: debug 1: client @0x7fbedc134ed0
127.0.0.1#61547 (176.216.85.209.dnsbl-3.uceprotect.net): query failed
(SERVFAIL) for 176.216.85.209.dnsbl-3.uceprotect.net/IN/A at
../../../bin/named/query.c:8580
26-Jul-2018 17:44:40.173 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for
176.216.85.209.dnsbl-3.uceprotect.net/A in 10.97: timed
out/success
[domain:dnsbl-3.uceprotect.net,referral:2,restart:1,qrysent:2,timeout:1,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
There appears to be a few timeout errors. Is this an indication there
is a performance problem with the cable modem or connection?
Thanks,
Alex
On Thu, Jul 26, 2018 at 1:57 PM, John Miller wrote:
> Hi Alex,
>
> What does your query volume look like on this server? Depending on
> volume, the BIND defaults for:
>
> - clients-per-query
> - max-clients-per-query
> - recursive-clients
> - tcp-clients
>
> and others may not be set high enough. Check pp. 106-108 in the
> latest 9.11 manual for more details on each of these.
>
> Of course, if you're only seeing SERVFAIL for a handful of domains,
> then they may have some sort of delegation issue, or there might be a
> network issue between your caching servers and them.
>
> John
>
>
> On Thu, Jul 26, 2018 at 1:07 PM, Alex wrote:
>> Hi,
>>
>> I have a bind-9.11.4 server on a fedora28 system and are frequently
>> seeing SERVFAIL errors like this:
>>
>> 26-Jul-2018 12:54:04.255 query-errors: info: client @0x7f764314a5c0
>> 127.0.0.1#50719 (223.178.102.199.cidr.bl.mcafee.com): query failed
>> (SERVFAIL) for 223.178.102.199.cidr.bl.mcafee.com/IN/A at
>> ../../../bin/named/query.c:4140
>>
>> I believe this happens more frequently at times of peak link
>> utilization, but it also appears to happen during normal times.
>>
>> This is a local caching server I've set up but it also appears to
>> exist on other systems that have been set up to be authoritative for
>> our domain.
>>
>> How can I troubleshoot this further?
>>
>> Here is the named.conf for this caching server:
>>
>> acl "trusted" {
>> { 127/8; };
>> { 68.195.191.40/29; };
>> { 192.168.1.0/24; };
>> { 107.155.67.2/32; };
>> };
>>
>> options {
>> listen-on port 53 { 127.0.0.1; 68.195.191.45; };
>> listen-on-v6 port 53 { none; };
>> directory "/var/named";
>> dump-file "/var/named/data/cache_dump.db";
>> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
>> memstatistics-file "/var/named/data/named.memstats"; //
>> _PATH_MEMSTATS
>> allow-query { trusted; };
>> recursion yes;
>> zone-statistics yes;
>>
>> // dnssec-enable yes;
>> // dnssec-validation yes;
>> // dnssec-lookaside auto;
>>
>> dnssec-enable no;
>> dnssec-validation no;
>> dnssec-lookaside no;
>>
>> /* Path to ISC DLV key */
>> bindkeys-file "/etc/named.iscdlv.key";
>>
>> managed-keys-directory "/var/named/dynamic";
>>
>> };
>>
>> logging {
>> channel default_debug {
>> file "data/named.run";
>> severity dynamic;
>> };
>>
>> // Record all queries to the box for now
>> channel query_info {
>>severity info;
>>file "/var/log/named.query.log" versions 3 size 10m;
>>print-time yes;
>>print-category yes;
>> };
>>
>> // added for fail2ban support
>> channel security_file {
>>severity dynamic;
>>file "/var/log/named.security.log" versions 3 size 30m;
>>print-time yes;
>>print-category yes;
>> };
>>
>> channel b_debug {
>> file "/var/log/named.debug.log" versions 2 size 10m;
>> print-time yes;
>> print-category yes;
>> print-severity yes;
>> severity dynamic;
>> };
>>
>> // Send the security related messages to a separate file.
>> channel audit_log {
>> file "/var/lo
Re: SERVFAIL and peak utilization
Hi, I've made some performance adjustments although I really don't know whether it's correct, and it doesn't seem to have solved the problem. I also notice the SERVFAIL error seems to happen in bulk - it will happen for a while and then stop. It definitely seems to occur more during peak mail volume (this is a mail server). max-clients-per-query 4000; clients-per-query 4000; recursive-clients 4000; tcp-clients 4000; Here's the named_stats.txt file from "rndc stats": +++ Statistics Dump +++ (1532630822) ++ Incoming Requests ++ 3267 QUERY ++ Incoming Queries ++ 2345 A 74 NS 69 PTR 152 MX 569 TXT 58 ++ Outgoing Rcodes ++ 1356 NOERROR 648 SERVFAIL 1070 NXDOMAIN ++ Outgoing Queries ++ [View: default] 8749 A 139 NS 133 PTR 30 MX 640 TXT 6 488 DS 87 DNSKEY [View: _bind] ++ Name Server Statistics ++ 3267 IPv4 requests received 2026 requests with EDNS(0) received 6 TCP requests received 3074 responses sent 6 truncated responses sent 1883 responses with EDNS(0) sent 1134 queries resulted in successful answer 2426 queries resulted in non authoritative answer 222 queries resulted in nxrrset 648 queries resulted in SERVFAIL 1070 queries resulted in NXDOMAIN 2190 queries caused recursion 33 duplicate queries received 4 queries dropped 156 recursing clients 3249 UDP queries received 6 TCP queries received ++ Zone Maintenance Statistics ++ ++ Resolver Statistics ++ [Common] 143 UDP queries in progress [View: default] 10272 IPv4 queries sent 2503 IPv4 responses received 611 NXDOMAIN received 1 SERVFAIL received 16 FORMERR received 14 EDNS(0) query failures 448 truncated responses received 7865 query retries 7674 query timeouts 380 IPv4 NS address fetches 33 IPv4 NS address fetch failed 1129 DNSSEC validation attempted 348 DNSSEC validation succeeded 741 DNSSEC NX validation succeeded 1 DNSSEC validation failed 78 queries with RTT < 10ms 1394 queries with RTT 10-100ms 981 queries with RTT 100-500ms 6 queries with RTT 500-800ms 1 queries with RTT 800-1600ms 150 active fetches 523 bucket size 3 REFUSED received 6146 COOKIE send with client cookie only 393 COOKIE sent with client and server cookie 291 COOKIE replies received 291 COOKIE client ok [View: _bind] 523 bucket size ++ Cache Statistics ++ [View: default] 22101 cache hits 13 cache misses 5896 cache hits (from query) 3416 cache misses (from query) 0 cache records deleted due to memory exhaustion 0 cache records deleted due to TTL expiration 2096 cache database nodes 1039 cache database hash buckets 1352276 cache tree memory total 1022492 cache tree memory in use 1022548 cache tree highest memory in use 393216 cache heap memory total 132096 cache heap memory in use 132096 cache heap highest memory in use [View: _bind (Cache: _bind)] 0 cache hits 0 cache misses 0 cache hits (from query) 0 cache misses (from query) 0 cache records deleted due to memory exhaustion 0 cache records deleted due to TTL expiration 0 cache database nodes 64 cache database hash buckets 287792 cache tree memory total 29952 cache tree memory in use 29952 cache tree highest memory in use 262144 cache heap memory total 1024 cache heap memory in use 1024 cache heap highest memory in use ++ Cache DB RRsets ++ [View: default] 963 A 299 NS 14 CNAME 23 PTR 19 MX 47 TXT 400 57 DS
Re: SERVFAIL and peak utilization
Hi,
On Thu, Jul 26, 2018 at 1:57 PM, John Miller wrote:
> Hi Alex,
>
> What does your query volume look like on this server? Depending on
> volume, the BIND defaults for:
>
> - clients-per-query
> - max-clients-per-query
> - recursive-clients
> - tcp-clients
>
> and others may not be set high enough. Check pp. 106-108 in the
> latest 9.11 manual for more details on each of these.
>
> Of course, if you're only seeing SERVFAIL for a handful of domains,
> then they may have some sort of delegation issue, or there might be a
> network issue between your caching servers and them.
I think it's happening more frequently than for just a remote
misconfigured system. Here is my rndc status, but it doesn't appear to
provide all values you've requested.
It's also occurring for queries to trustworthy remote sources:
26-Jul-2018 14:48:22.975 query-errors: debug 1: client @0x7fddb400c570
127.0.0.1#56094 (mail-dm3nam03on0041.outbound.protection.outlook.com):
query failed (SERVFAIL) for
mail-dm3nam03on0041.outbound.protection.outlook.com/IN/A at
../../../bin/named/query.c:8580
# rndc status
version: BIND 9.11.4-RedHat-9.11.4-1.fc28 (Extended Support Version)
running on bwimail03.guardiandigital.com: Linux x86_64
4.17.7-200.fc28.x86_64 #1 SMP Tue Jul 17 16:28:31 UTC 2018
boot time: Thu, 26 Jul 2018 18:47:52 GMT
last configured: Thu, 26 Jul 2018 18:47:52 GMT
configuration file: /etc/named.conf (/var/named/chroot/etc/named.conf)
CPUs found: 8
worker threads: 8
UDP listeners per interface: 7
number of zones: 103 (97 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 63/900/1000
tcp clients: 0/150
server is up and running
I've also now confirmed it's happening at times of regular network
activity. I'm really stuck. I hope someone can help.
Thanks,
Alex
>
> John
>
>
> On Thu, Jul 26, 2018 at 1:07 PM, Alex wrote:
>> Hi,
>>
>> I have a bind-9.11.4 server on a fedora28 system and are frequently
>> seeing SERVFAIL errors like this:
>>
>> 26-Jul-2018 12:54:04.255 query-errors: info: client @0x7f764314a5c0
>> 127.0.0.1#50719 (223.178.102.199.cidr.bl.mcafee.com): query failed
>> (SERVFAIL) for 223.178.102.199.cidr.bl.mcafee.com/IN/A at
>> ../../../bin/named/query.c:4140
>>
>> I believe this happens more frequently at times of peak link
>> utilization, but it also appears to happen during normal times.
>>
>> This is a local caching server I've set up but it also appears to
>> exist on other systems that have been set up to be authoritative for
>> our domain.
>>
>> How can I troubleshoot this further?
>>
>> Here is the named.conf for this caching server:
>>
>> acl "trusted" {
>> { 127/8; };
>> { 68.195.191.40/29; };
>> { 192.168.1.0/24; };
>> { 107.155.67.2/32; };
>> };
>>
>> options {
>> listen-on port 53 { 127.0.0.1; 68.195.191.45; };
>> listen-on-v6 port 53 { none; };
>> directory "/var/named";
>> dump-file "/var/named/data/cache_dump.db";
>> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
>> memstatistics-file "/var/named/data/named.memstats"; //
>> _PATH_MEMSTATS
>> allow-query { trusted; };
>> recursion yes;
>> zone-statistics yes;
>>
>> // dnssec-enable yes;
>> // dnssec-validation yes;
>> // dnssec-lookaside auto;
>>
>> dnssec-enable no;
>> dnssec-validation no;
>> dnssec-lookaside no;
>>
>> /* Path to ISC DLV key */
>> bindkeys-file "/etc/named.iscdlv.key";
>>
>> managed-keys-directory "/var/named/dynamic";
>>
>> };
>>
>> logging {
>> channel default_debug {
>> file "data/named.run";
>> severity dynamic;
>> };
>>
>> // Record all queries to the box for now
>> channel query_info {
>>severity info;
>>file "/var/log/named.query.log" versions 3 size 10m;
>>print-time yes;
>>print-category yes;
>> };
>>
>> // added for fail2ban support
>> channel security_file {
>>severity dynamic;
>>file "/var/log/named.security.log" versions 3 size 30m;
>>print-time yes;
>>print-category yes;
>> };
>>
>> channel b_debug {
>> file "/var/log/named.debug.log" versions 2 size 10m;
>> print-time yes;
>> print-category yes;
>> print-severity yes;
>> severity dynamic;
>> };
>>
>> // Send the security related messages to a separate file.
>> channel audit_log {
>> file "/var/log/named.audit.log" versions 4 size 10m;
>> severity info;
>> print-time yes;
>> print-category yes;
>> };
>>
>>
>> category queries { query_info; };
>> category default { b_debug; };
>> category config { b_debug; };
>> category security { security_file; };
>> // category lame-servers { audit_log; };
>> category lame-servers { null; };
>>
>> };
>>
>> zone "." IN {
>> type hint;
>> file "/var/named/named.ca";
>> };
>>
>> zone "localhost.localdomain" IN {
>> type master;
>> file "named.localhost
tool for finding undelegated children in your DNS
Does anyone know of a good tool that you can run on your DNS records to find parent + child pairs where there is no NS record for the child in the parent? Someone must have a perl script for that, right? Thank you for any suggestions. Vicky ___ 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: SERVFAIL and peak utilization
Hi Alex,
What does your query volume look like on this server? Depending on
volume, the BIND defaults for:
- clients-per-query
- max-clients-per-query
- recursive-clients
- tcp-clients
and others may not be set high enough. Check pp. 106-108 in the
latest 9.11 manual for more details on each of these.
Of course, if you're only seeing SERVFAIL for a handful of domains,
then they may have some sort of delegation issue, or there might be a
network issue between your caching servers and them.
John
On Thu, Jul 26, 2018 at 1:07 PM, Alex wrote:
> Hi,
>
> I have a bind-9.11.4 server on a fedora28 system and are frequently
> seeing SERVFAIL errors like this:
>
> 26-Jul-2018 12:54:04.255 query-errors: info: client @0x7f764314a5c0
> 127.0.0.1#50719 (223.178.102.199.cidr.bl.mcafee.com): query failed
> (SERVFAIL) for 223.178.102.199.cidr.bl.mcafee.com/IN/A at
> ../../../bin/named/query.c:4140
>
> I believe this happens more frequently at times of peak link
> utilization, but it also appears to happen during normal times.
>
> This is a local caching server I've set up but it also appears to
> exist on other systems that have been set up to be authoritative for
> our domain.
>
> How can I troubleshoot this further?
>
> Here is the named.conf for this caching server:
>
> acl "trusted" {
> { 127/8; };
> { 68.195.191.40/29; };
> { 192.168.1.0/24; };
> { 107.155.67.2/32; };
> };
>
> options {
> listen-on port 53 { 127.0.0.1; 68.195.191.45; };
> listen-on-v6 port 53 { none; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
> memstatistics-file "/var/named/data/named.memstats"; //
> _PATH_MEMSTATS
> allow-query { trusted; };
> recursion yes;
> zone-statistics yes;
>
> // dnssec-enable yes;
> // dnssec-validation yes;
> // dnssec-lookaside auto;
>
> dnssec-enable no;
> dnssec-validation no;
> dnssec-lookaside no;
>
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
>
> managed-keys-directory "/var/named/dynamic";
>
> };
>
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
>
> // Record all queries to the box for now
> channel query_info {
>severity info;
>file "/var/log/named.query.log" versions 3 size 10m;
>print-time yes;
>print-category yes;
> };
>
> // added for fail2ban support
> channel security_file {
>severity dynamic;
>file "/var/log/named.security.log" versions 3 size 30m;
>print-time yes;
>print-category yes;
> };
>
> channel b_debug {
> file "/var/log/named.debug.log" versions 2 size 10m;
> print-time yes;
> print-category yes;
> print-severity yes;
> severity dynamic;
> };
>
> // Send the security related messages to a separate file.
> channel audit_log {
> file "/var/log/named.audit.log" versions 4 size 10m;
> severity info;
> print-time yes;
> print-category yes;
> };
>
>
> category queries { query_info; };
> category default { b_debug; };
> category config { b_debug; };
> category security { security_file; };
> // category lame-servers { audit_log; };
> category lame-servers { null; };
>
> };
>
> zone "." IN {
> type hint;
> file "/var/named/named.ca";
> };
>
> zone "localhost.localdomain" IN {
> type master;
> file "named.localhost";
> allow-update { none; };
> };
>
> zone "localhost" IN {
> type master;
> file "named.localhost";
> allow-update { none; };
> };
>
> zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> IN {
> type master;
> file "named.loopback";
> allow-update { none; };
> };
>
> zone "1.0.0.127.in-addr.arpa" IN {
> type master;
> file "named.loopback";
> allow-update { none; };
> };
>
> zone "0.in-addr.arpa" IN {
> type master;
> file "named.empty";
> allow-update { none; };
> };
>
> include "/etc/named.root.key";
> include "/etc/rndc.key";
> ___
___
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
SERVFAIL and peak utilization
Hi,
I have a bind-9.11.4 server on a fedora28 system and are frequently
seeing SERVFAIL errors like this:
26-Jul-2018 12:54:04.255 query-errors: info: client @0x7f764314a5c0
127.0.0.1#50719 (223.178.102.199.cidr.bl.mcafee.com): query failed
(SERVFAIL) for 223.178.102.199.cidr.bl.mcafee.com/IN/A at
../../../bin/named/query.c:4140
I believe this happens more frequently at times of peak link
utilization, but it also appears to happen during normal times.
This is a local caching server I've set up but it also appears to
exist on other systems that have been set up to be authoritative for
our domain.
How can I troubleshoot this further?
Here is the named.conf for this caching server:
acl "trusted" {
{ 127/8; };
{ 68.195.191.40/29; };
{ 192.168.1.0/24; };
{ 107.155.67.2/32; };
};
options {
listen-on port 53 { 127.0.0.1; 68.195.191.45; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named.stats"; // _PATH_STATS
memstatistics-file "/var/named/data/named.memstats"; // _PATH_MEMSTATS
allow-query { trusted; };
recursion yes;
zone-statistics yes;
// dnssec-enable yes;
// dnssec-validation yes;
// dnssec-lookaside auto;
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside no;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
// Record all queries to the box for now
channel query_info {
severity info;
file "/var/log/named.query.log" versions 3 size 10m;
print-time yes;
print-category yes;
};
// added for fail2ban support
channel security_file {
severity dynamic;
file "/var/log/named.security.log" versions 3 size 30m;
print-time yes;
print-category yes;
};
channel b_debug {
file "/var/log/named.debug.log" versions 2 size 10m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
// Send the security related messages to a separate file.
channel audit_log {
file "/var/log/named.audit.log" versions 4 size 10m;
severity info;
print-time yes;
print-category yes;
};
category queries { query_info; };
category default { b_debug; };
category config { b_debug; };
category security { security_file; };
// category lame-servers { audit_log; };
category lame-servers { null; };
};
zone "." IN {
type hint;
file "/var/named/named.ca";
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update { none; };
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
IN {
type master;
file "named.loopback";
allow-update { none; };
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update { none; };
};
include "/etc/named.root.key";
include "/etc/rndc.key";
___
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
dnssec-signzone sometimes does lowercase DNSSEC records
Hello all, dnssec-signzone (BIND 9.12.2) sometimes does lowercase DNSSEC records. This seems a problem especially for NSEC records which are case sensitive. dnssec-verify is moaning with errors like this: Bad NSEC record for ipad-rigi-2.switch.ch, bit map mismatch Example: dnssec-signzone -o switch.ch. switch.ch Kswitch.ch.+013+44373.private Output, note that ipv4.switch.ch is originally written as IPv4.switch.ch but the DNSSEC records are all in lowercase. ... IPv4.switch.ch. 86400 IN APL 1:0.0.0.0/0 ipv4.switch.ch. 86400 IN RRSIGAPL 13 3 86400 20180817132852 20180726134251 44373 switch.ch. mf2CacXrMqsePVoC+WvjX4CHcJBBP6CZPmzl1LXj5X6pNVVb2T7DzzsZ PvvflRNol1sYSyxtn0Tlv8BFqYsISA== ipv4.switch.ch. 180 IN NSEC cam.ipv4.switch.ch. APL RRSIG NSEC ipv4.switch.ch. 180 IN RRSIG NSEC 13 3 180 20180823223316 20180726134251 44373 switch.ch. zxGwOJsnbK4OEDqlyQ/Hxea3m/W2aFwg2OKDos1u6rJNTW64Gp6cg3Ce EiNX3JY9VMsKXAFsGYKjnjtzNM/VEA== ipad-rigi-2.switch.ch.86400 IN A130.59.97.30 ipad-rigi-2.switch.ch.86400 IN RRSIGA 13 3 86400 20180814152223 20180726134251 44373 switch.ch. AsQJ3ONoS19evdbsIf3Xkfs+s66cFc3KVLrTvK3BA1kqZKTKUwdz1iqs vSPVtF7SjcBfVQU71a8FDUtjOfrCtg== ipad-rigi-2.switch.ch.86400 IN LOC 47 22 23.970 N 8 31 52.201 E 415.00m 1m 1m 10m ipad-rigi-2.switch.ch.86400 IN RRSIGLOC 13 3 86400 20180815150750 20180726134251 44373 switch.ch. 1/co/914PvPKscFDM+tveLuywfnnTmkjv8vfZlPUY/wwGWugcDcOMvP4 B2ldHp2T8GPv1cbCSQG1/ibWAbR5WQ== ipad-rigi-2.switch.ch.180 IN NSEC ipv4.switch.ch. A LOC RRSIG NSEC ... Is this bug related to https://gitlab.isc.org/isc-projects/bind9/issues/420 I guess, I could start to lowercase all owner names or move to NSEC3. I tested both approaches and they work. Daniel ___ 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
