Question about dynamic IPv6-PTR-Generation
Hi list I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE"-mechanism for IPv4 has done it. I read about Delegation, self-registration with "tcp-self" or using Wildcards with the disadvantage, that every query has the same response. Is there a (planned) way, to generate reverse-responses "on-the-fly" with bind? I'm using the latest bind (9.10.4-P2). Many thanks for your help. 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
Zones declared in a catalog-zone are not transferred successfully over XoT
Hi list
Running a primary and a secondary with each BIND-9.18.9 and using
catalog zones.
I'm trying to use XoT for the catalog-zones. The catalog zone itself is
transferred over XoT without any issues, but the zones *within* the
catalog-zone aren't transferred succesfully.
On the primary, I configured a "listen-on"-directive for TLS:
tls "xot" {
cert-file "/etc/named/tls/tls.pem";
key-file "/etc/named/tls/tls.key";
protocols { TLSv1.2; };
session-tickets yes;
};
options {
...
listen-on port 853 tls "xot" { 192.168.1.1; };
};
On the secondary, I configured a tls profile too:
tls "xot" {
protocols { TLSv1.2; };
session-tickets yes;
};
and the necessary catalog-zones configuration:
...
catalog-zones {
zone "catz.example.local"
in-memory no
zone-directory "/var/named/slave/catzones"
min-update-interval 5
default-primaries { 192.168.1.1 port 853 tls "xot"; };
};
...
What I see here, is that the secondary tries to transfer the zones
(which are declared in the catalog-zone) from the primary with UDP-853
and does nothing with TLS (and just one thing with TCP, see below).
The secondary gives up trying with UDP-853 (6x) and tries to connect
with TCP (but no TLS) one time and shows then the following error:
09-Jan-2023 15:57:49.787 general: info: zone example.ch/IN: refresh:
retry limit for primary 192.168.1.1#853 exceeded (source 0.0.0.0#0)
09-Jan-2023 15:57:49.787 xfer-in: info: zone example.ch/IN: Transfer
started.
09-Jan-2023 15:57:49.788 xfer-in: info: transfer of 'example.ch/IN' from
192.168.1.1#853: connected using 192.168.1.1#853 TSIG testkey
09-Jan-2023 15:57:49.788 xfer-in: error: transfer of 'example.ch/IN'
from 192.168.1.1#853: failed while receiving responses: end of file
09-Jan-2023 15:57:49.788 xfer-in: info: transfer of 'example.ch/IN' from
192.168.1.1#853: Transfer status: end of file
09-Jan-2023 15:57:49.788 xfer-in: info: transfer of 'example.ch/IN' from
192.168.1.1#853: Transfer completed: 0 messages, 0 records, 0 bytes,
0.001 secs (0 bytes/sec) (serial 0)
The appropriate tcpdump looks like this where 192.168.1.2 is the
secondary and 192.168.1.1 is the primary:
15:56:19.719792 IP 192.168.1.2.45333 > 192.168.1.1.853: UDP, length 159
15:56:34.735035 IP 192.168.1.2.45333 > 192.168.1.1.853: UDP, length 159
15:56:49.741560 IP 192.168.1.2.45333 > 192.168.1.1.853: UDP, length 159
15:57:04.757216 IP 192.168.1.2.31594 > 192.168.1.1.853: UDP, length 144
15:57:19.757964 IP 192.168.1.2.31594 > 192.168.1.1.853: UDP, length 144
15:57:34.773366 IP 192.168.1.2.31594 > 192.168.1.1.853: UDP, length 144
15:57:49.789218 IP 192.168.1.2.37670 > 192.168.1.1.853: Flags [S], seq
1845821283, win 24400, options [mss 1220,nop,nop,sackOK,nop,wscale 7],
length 0
15:57:49.789457 IP 192.168.1.1.853 > 192.168.1.2.37670: Flags [S.], seq
385431624, ack 1845821284, win 24400, options [mss
1220,nop,nop,sackOK,nop,wscale 7], length 0
15:57:49.789503 IP 192.168.1.2.37670 > 192.168.1.1.853: Flags [.], ack
1, win 191, length 0
15:57:49.789745 IP 192.168.1.2.37670 > 192.168.1.1.853: Flags [P.], seq
1:147, ack 1, win 191, length 146
15:57:49.789816 IP 192.168.1.1.853 > 192.168.1.2.37670: Flags [.], ack
147, win 199, length 0
15:57:49.790013 IP 192.168.1.1.853 > 192.168.1.2.37670: Flags [F.], seq
1, ack 147, win 199, length 0
15:57:49.790070 IP 192.168.1.2.37670 > 192.168.1.1.853: Flags [F.], seq
147, ack 2, win 191, length 0
15:57:49.790134 IP 192.168.1.1.853 > 192.168.1.2.37670: Flags [.], ack
148, win 199, length 0
Any hints how I need to configure the "default-primaries"-option in the
"catalog-zones"-directive to properly "speak" XoT?
btw: Using dig for transferring the zone from the primary with XoT and
TSIG is working fine:
$ dig @192.168.1.1 -k /tmp/key +tls +onesoa axfr example.ch
Many thanks in advance,
Tom
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zones declared in a catalog-zone are not transferred successfully over XoT
Hi Aram Thanks a lot for your quick response. I've tested with 9.18.10 which definitely solved this issue and XoT for catalog-zones is now working fine. Best regards, Tom On 1/9/23 16:38, Aram Sargsyan wrote: Hello Tom, I see you are using BIND 9.18.9, can you retry with the latest version of BIND 9.18? An issue, which looks similar to the one that you are experiencing, was fixed in BIND 9.18.10, see https://gitlab.isc.org/isc-projects/bind9/-/issues/3638 Kind regards, Aram -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Hi list Using BIND-9.19.10: An A-query on our resolver for "ns2.comtronic.ch" causes the following info in the named.log, after the first response was answered to the client and cached and then the entry is flushed from cache with "rndc flushname ns2.comtronic.ch": 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A' The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks like this (after flushing the cached name with "rndc flushname ns2.comtronic.ch"): # Client query 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative server for A 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] A? ns2.comtronic.ch. (45) # Querying TLD nameserver for A and 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] ? ns2.comtronic.ch. (45) 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? ns2.comtronic.ch. (45) # Response from the authoritative 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A 195.200.242.162 (89) # Delegations back from the TLD nameserver for the A and query 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 (695) 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 (695) # Query against another authoritative for A and 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] ? ns2.comtronic.ch. (45) 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] A? ns2.comtronic.ch. (45) # Answer back from the authoritative (no record found for "ns2.comtronic.ch) 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 A 195.200.242.162 (61) 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- 0/1/1 (96) BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. BIND-9.18.12 doesn't query for lookup after flushing the name, where BIND-9.19.10 always does with the same configuration..., why? See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced "loop detection resolving" info (after flushing the name with "rndc flushname ns2.comtronic.ch"): # Query from the client 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45) # Query from the resolver to the TLD server 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45) # Response back from the authoritative server 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89) # Delegation answer from the TLD server 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695) # A 2nd query to the same authoritative 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45) # 2nd response back from the authoritative server 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61) The info "loop detected resolving" is always reproducable in BIND-9.19.10 after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. So my questions are: - What does "loop detected resolving 'ns2.comtronic.ch/A' means here? - Why is "loop detected resolving 'ns2.comtronic.ch/A'" always reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12? - Why does BIND-9.19.10 behaves differently to BIND-9.18.12 regarding lookups after flushing the name "ns2.comtronic.ch"? - BIND-9.19.10 does A and lookups after flushing the name "ns2.comtronic.ch", where BIND-9.18.12 only queries for A records Many thanks for any hints. Best regards, Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Hi Ondrej I've created the issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/3885 Best regards, Tom On 2/21/23 14:24, Ondřej Surý wrote: Tom, the ADB (Address DataBase) responsible for caching the delegations had been heavily refactoring in 9.19 branch, I think the best course of action would be to fill a GitLab issue with the description, so we can follow-up there. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 21. 2. 2023, at 10:03, Tom wrote: Hi list Using BIND-9.19.10: An A-query on our resolver for "ns2.comtronic.ch" causes the following info in the named.log, after the first response was answered to the client and cached and then the entry is flushed from cache with "rndc flushname ns2.comtronic.ch": 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A' The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks like this (after flushing the cached name with "rndc flushname ns2.comtronic.ch"): # Client query 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative server for A 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] A? ns2.comtronic.ch. (45) # Querying TLD nameserver for A and 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] ? ns2.comtronic.ch. (45) 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? ns2.comtronic.ch. (45) # Response from the authoritative 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A 195.200.242.162 (89) # Delegations back from the TLD nameserver for the A and query 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 (695) 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 (695) # Query against another authoritative for A and 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] ? ns2.comtronic.ch. (45) 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] A? ns2.comtronic.ch. (45) # Answer back from the authoritative (no record found for "ns2.comtronic.ch) 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 A 195.200.242.162 (61) 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- 0/1/1 (96) BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. BIND-9.18.12 doesn't query for lookup after flushing the name, where BIND-9.19.10 always does with the same configuration..., why? See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced "loop detection resolving" info (after flushing the name with "rndc flushname ns2.comtronic.ch"): # Query from the client 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45) # Query from the resolver to the TLD server 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45) # Response back from the authoritative server 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89) # Delegation answer from the TLD server 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695) # A 2nd query to the same authoritative 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45) # 2nd response back from the authoritative server 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61) The info "loop detected resolving" is always reproducable in BIND-9.19.10 after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. So my questions are: - What does "loop detected resolving 'ns2.comtronic.ch/A' means here? - Why is "loop detected resolving 'ns2.comtronic.ch/A'" always reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12? - Why does BIND-9.19.10 behaves differently to BIND-9.18.12 regarding lookups after flushing the name "ns2.comtronic.ch"? - BIND-9.19.10 does A and lookups after flushing the name "ns2.comtronic.ch",
Re: Question about dynamic IPv6-PTR-Generation
Many thanks for your quick feedback. This is the configuration-option, where I'm searching for. But probably this will take some time, until it's accepted, tested, implemented...etc. What do you propose in the meantime instead of using wildcards or allow the clients to register themselves or making static PTR-entries? How does other companies handle this issue? Kind regards, Tom On 08/26/2016 09:17 AM, Woodworth, John R wrote: Hi list I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE" -mechanism for IPv4 has done it. I read about Delegation, self-registration with "tcp-self" or using Wildcards with the disadvantage, that every query has the same response. Is there a (planned) way, to generate reverse-responses "on-the-fly" with bind? I'm using the latest bind (9.10.4-P2). Tom, ** Full disclosure: I am directly involved in the Internet-Draft (I-D) referenced in the below response. Although this does not necessarily help you today, some colleagues and I are working on a new standard which addresses this problem in a more general way by introducing a new RR type. It provides several features beyond simply extending the $GENERATE directive to enormous proportions such as: allowing AXFR transfers of the "intent" of BULK record generation. If you are interested in learning more about this, please follow the link in my signature below. We appreciate any comments/ suggestions regarding this draft. Regards, John -- John Woodworth CenturyLink, Inc. Q. Can a $GENERATE work for DNS on a /64 of reverse?? A. BULK CAN [ http://tools.ietf.org/html/draft-woodworth-bulk-rr-02 ] Many thanks for your help. 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 -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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
Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"
Hi list Using self-compiled latest bind (9.10.4-P2): I have a bind-setup with activated response-policy-zones. For *each* client-forward-query, which has a valid dns-response, I got an error in the client-log (for NXDOMAIN-Reponses, I didn't have such errors... ex. "dig @nameserver aasledkfjasdlkfjsadlf.asdlfkjsadlfkjasdjflk"): - 30-Aug-2016 06:43:51.722 client: error: query client=0x7f1074112200 thread=0x7f107a8a7700 (google.com/A): rpz_rewrite_name: mismatched summary data; continuing - 30-Aug-2016 06:46:19.312 client: error: query client=0x7f10741614e0 thread=0x7f107b0a8700 (yahoo.com/A): rpz_rewrite_name: mismatched summary data; continuing ... ... The client receives the right response, dns-rpz is also working, but I'm suspicious about the errors mentioned above. Any hints? Thanks a lot. 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
Re: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"
Hi list After some more troubleshooting, I was able to locate the problem: - One Spamhaus-Zone-File (dbl.rpz.spamhaus.org, ca. 180MB in "masterfile-format text;") is loaded correctly, but if this zone is loaded, then I got the mentioned errors. - Configuring the "masterfile-format map;" for this zone, then the error disappered. Any hints for this behaviour? Kind regards, On 08/30/2016 06:53 AM, Tom wrote: Hi list Using self-compiled latest bind (9.10.4-P2): I have a bind-setup with activated response-policy-zones. For *each* client-forward-query, which has a valid dns-response, I got an error in the client-log (for NXDOMAIN-Reponses, I didn't have such errors... ex. "dig @nameserver aasledkfjasdlkfjsadlf.asdlfkjsadlfkjasdjflk"): - 30-Aug-2016 06:43:51.722 client: error: query client=0x7f1074112200 thread=0x7f107a8a7700 (google.com/A): rpz_rewrite_name: mismatched summary data; continuing - 30-Aug-2016 06:46:19.312 client: error: query client=0x7f10741614e0 thread=0x7f107b0a8700 (yahoo.com/A): rpz_rewrite_name: mismatched summary data; continuing ... ... The client receives the right response, dns-rpz is also working, but I'm suspicious about the errors mentioned above. Any hints? Thanks a lot. 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
Re: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"
Sorry...wrong post. After a little bit more testing, the errors are still appearing. The masterfile-format didn't solved the errors Thank you, Tom On 08/30/2016 08:20 AM, Tom wrote: Hi list After some more troubleshooting, I was able to locate the problem: - One Spamhaus-Zone-File (dbl.rpz.spamhaus.org, ca. 180MB in "masterfile-format text;") is loaded correctly, but if this zone is loaded, then I got the mentioned errors. - Configuring the "masterfile-format map;" for this zone, then the error disappered. Any hints for this behaviour? Kind regards, On 08/30/2016 06:53 AM, Tom wrote: Hi list Using self-compiled latest bind (9.10.4-P2): I have a bind-setup with activated response-policy-zones. For *each* client-forward-query, which has a valid dns-response, I got an error in the client-log (for NXDOMAIN-Reponses, I didn't have such errors... ex. "dig @nameserver aasledkfjasdlkfjsadlf.asdlfkjsadlfkjasdjflk"): - 30-Aug-2016 06:43:51.722 client: error: query client=0x7f1074112200 thread=0x7f107a8a7700 (google.com/A): rpz_rewrite_name: mismatched summary data; continuing - 30-Aug-2016 06:46:19.312 client: error: query client=0x7f10741614e0 thread=0x7f107b0a8700 (yahoo.com/A): rpz_rewrite_name: mismatched summary data; continuing ... ... The client receives the right response, dns-rpz is also working, but I'm suspicious about the errors mentioned above. Any hints? Thanks a lot. 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
Re: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"
Is there a workaround/configuration-directive not to log every request with this "error"? One way would be using BIND 9.9.9-P2 (because this code was added in 9.10.x...), but I would prefer 9.10.x. Kind regards, Tom On 08/31/2016 03:05 PM, Tony Finch wrote: Tom wrote: I have a bind-setup with activated response-policy-zones. For *each* client-forward-query, which has a valid dns-response, I got an error in the client-log (for NXDOMAIN-Reponses, I didn't have such errors... ex. "dig @nameserver aasledkfjasdlkfjsadlf.asdlfkjsadlfkjasdjflk"): There's a comment before this error message saying: /* * Continue after a policy record that is missing * contrary to the summary data. The summary * data can out of date during races with and among * policy zone updates. */ Spamhaus RPZ updates frequently, which might be related to your problem. However I would not expect an update race to cause a complaint for every query... Tony. ___ 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: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"
Hi Mukund Many thanks for your hint. In fact named was compiled with "--enable-querytrace". After recompiling 9.10.4-P2 without querytrace, the log looks good. Kind regards, Tom On 09/06/2016 09:32 AM, Mukund Sivaraman wrote: Hi Tom On Tue, Sep 06, 2016 at 07:37:50AM +0200, Tom wrote: Is there a workaround/configuration-directive not to log every request with this "error"? One way would be using BIND 9.9.9-P2 (because this code was added in 9.10.x...), but I would prefer 9.10.x. (1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10 and higher (or 9.9 subscription branch that's available to ISC customers). RPZ in vanilla 9.9 is unmaintained and unsupported (it was experimental there). (2) We'll look at tweaking this log message, but if you want to just not see this log message, just recompile after removing the offending CTRACE statement from bin/named/query.c. In fact, this code is normally enabled when configured with --enable-querytrace. Do you have query tracing configured? Is seeing this additional log message so inconvenient then? Mukund ___ 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
Overwrite SOA-Records in RPZ-Responses?
Hi list, From "https://kb.isc.org/getAttach/21/AA-00512/rpz.txt";, Chapter 3 - Subscriber Behavior: ... ... If a policy trigger results in a modified answer, then that modified answer will include in its "authority" section the SOA RR of the DNS RPZ whose policy was used to generate the modified answer. This SOA RR will tell both the fully qualified name of the DNS RPZ and the serial number of the policy data which was connected to the DNS control plane at the time the answer was modified. ... Is there a way to overwrite the SOA-Record in a RPZ-Response "on-the-fly", whose zone is configured as "slave"? Because we use configured some third-party-rpz-zones, the soa-record is predefined... 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
BIND-RPZ and Views
Hi Using BIND 9.10.4-P2: I've a question about configuring DNS-RPZ and views: I configured view1 and view2. After configuring all rpz-zones in both views, I had errors like this (slave file in view2 is already in use from view1): config: error: /etc/named/named.conf:403: writeable file 'slave/malware.rpz.spamhaus.org': already in use: /etc/named/named.conf:259 Is there a way to support RPZ in views? I want to achieve that Customer01 (view01) should have different RPZ-options than Customer02 (view02) using the same RPZ-Files. 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
Re: CDS-deletion record "CDS 0 0 0 00" is failing with bind-9.14.9 and bind-9.14.8
Hi With 9.16.0, the CDS deletion (https://gitlab.isc.org/isc-projects/bind9/issues/1554) is still not working and is ending with the same error as bind-versions before: 20-Feb-2020 17:31:25.381 general: error: zone example.com/IN (unsigned): CDS/CDNSKEY consistency checks failed 20-Feb-2020 17:31:25.381 zoneload: error: zone example.com/IN (unsigned): not loaded due to errors. In which version will this issue be fixed? Many thanks. Kind regards, Tom On 11.01.20 08:48, Mark Andrews wrote: Open a ticket saying “CDS/CDNSKEY not handled when performing constancy checks”. ___ 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: CDS-deletion record "CDS 0 0 0 00" is failing with bind-9.14.9 and bind-9.14.8
Hi Mark Thank you for your answer. BIND is definitely running the current version: $ rndc status version: BIND 9.16.0 (Stable Release) () running on server: Linux x86_64 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 UTC 2019 boot time: Thu, 20 Feb 2020 16:30:15 GMT last configured: Thu, 20 Feb 2020 16:31:25 GMT configuration file: /etc/named/named.conf (/opt/chroot/bind/etc/named/named.conf) CPUs found: 4 worker threads: 4 UDP listeners per interface: 4 number of zones: 110 (98 automatic) 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: 2/150 TCP high-water: 103 server is up and running I've removed the CDS/CDNSKEY records from the zone with dnssec-settime -K [key-directory] -D sync now Kexample.com... So the CDS/CDNSKEY are no more longer existing in the zone and are no longer queryable with dig -> as expected: $ dig @127.0.0.1 +noall +answer cds example.com -> No output $ dig @127.0.0.1 +noall +answer cdnskey example.com -> No output So from my point of view, I have now a clear starting point where no longer CDS/CDNSKEY records are published. When I now configure the explicit deletion record(s) within the zone for "CDS" and/or "CDS/CDNSKEY", then BIND is still failing with the mentioned error. The zonefile looks like this: SCHNIPP $TTL 3600 example.com.IN SOA ns1.example.com. dnsadmin.example.com. ( 2020022104 10800 3600 1209600 3600 ) example.com.IN NS ns1.example.com. example.com.IN NS ns2.example.com. @ IN CDS 0 0 0 00 @ IN CDNSKEY 0 3 0 AA== SCHNAPP 21-Feb-2020 08:13:40.939 general: error: zone example.com/IN (unsigned): CDS/CDNSKEY consistency checks failed 21-Feb-2020 08:13:40.939 zoneload: error: zone example.com/IN (unsigned): not loaded due to errors. Thank you. Kind regards, Tom On 20.02.20 19:41, Mark Andrews wrote: Tom, I would run ‘rndc status’ or ‘dig ch txt version.bind @server’ and confirm that you have restarted named with the new code. I’ve had hundreds of 'bug reports’ about non fixed bugs that where operators failing to restart named after installing the new version. The new code is in 9.16.0, 9.14.11, and 9.11.16. I would check that the *only* CDS record is a deletion record is present. A CDS deletion record and a non CDS deletion record is a error. Similarly for CDNSKEY. A CDS/CDNSKEY deletion record and other CDS/CDNSKEY records in a RRset make no sense. You are either deleting all DS records or replacing all the DS records with the CDS records, or generating a new set of DS records from the CDNSKEY records. You can't do both at once. Mark On 21 Feb 2020, at 03:54, Ondřej Surý wrote: Hi Tom, On 20 Feb 2020, at 17:42, Tom wrote: Hi With 9.16.0, the CDS deletion (https://gitlab.isc.org/isc-projects/bind9/issues/1554) is still not working and is ending with the same error as bind-versions before: 20-Feb-2020 17:31:25.381 general: error: zone example.com/IN (unsigned): CDS/CDNSKEY consistency checks failed 20-Feb-2020 17:31:25.381 zoneload: error: zone example.com/IN (unsigned): not loaded due to errors. In which version will this issue be fixed? it will be included in the next version when the issue in question gets picked up by a developer, be triaged, test written and code fixed. I can’t really say when this will happen, our developer resources are thin and there are more issues that require our attention. That said - this is open source and we happily accept external contributions in a form of merge request in our gitlab instance (you need to ask for a permission to fork the project) or as a patch. This seems to be fairly trivial bug that might be a good start if anybody wants to help fix bugs in BIND 9. Cheers, Ondrej -- Ondřej Surý ond...@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 ___ 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: CDS-deletion record "CDS 0 0 0 00" is failing with bind-9.14.9 and bind-9.14.8
Hi Mark Heureka..., that did the trick. The zone is inline signed and after I added the already existing DNSKEY records in the raw zone file, the CDS/CDNSKEY deletion record was accepted and the zone was loaded. Many thanks. Kind regards, Tom On 21.02.20 21:08, Mark Andrews wrote: > There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for > the > parent to accept them. There must be DNSKEY records present for them to be > signed. > Add a DNSKEY record to that test zone and it will load. > > For inline zone just copy the final DNSKEY RRset from the signed version of > the > zone to the raw zone when adding the deletion CDS and CDNSKEY records. Wait > for > the parent zone to remove the DS records, then remove the CDS, CDNSKEY, and > DNSKEY > records from the raw zone. > > Mark > >> On 21 Feb 2020, at 18:31, Tom wrote: >> >> Hi Mark >> >> Thank you for your answer. BIND is definitely running the current version: >> >> $ rndc status >> version: BIND 9.16.0 (Stable Release) () >> running on server: Linux x86_64 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 >> 23:58:53 UTC 2019 >> boot time: Thu, 20 Feb 2020 16:30:15 GMT >> last configured: Thu, 20 Feb 2020 16:31:25 GMT >> configuration file: /etc/named/named.conf >> (/opt/chroot/bind/etc/named/named.conf) >> CPUs found: 4 >> worker threads: 4 >> UDP listeners per interface: 4 >> number of zones: 110 (98 automatic) >> 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: 2/150 >> TCP high-water: 103 >> server is up and running >> >> >> I've removed the CDS/CDNSKEY records from the zone with dnssec-settime -K >> [key-directory] -D sync now Kexample.com... >> >> So the CDS/CDNSKEY are no more longer existing in the zone and are no longer >> queryable with dig -> as expected: >> $ dig @127.0.0.1 +noall +answer cds example.com -> No output >> $ dig @127.0.0.1 +noall +answer cdnskey example.com -> No output >> >> So from my point of view, I have now a clear starting point where no longer >> CDS/CDNSKEY records are published. >> >> When I now configure the explicit deletion record(s) within the zone for >> "CDS" and/or "CDS/CDNSKEY", then BIND is still failing with the mentioned >> error. >> >> The zonefile looks like this: >> SCHNIPP >> $TTL 3600 >> example.com. IN SOA ns1.example.com. dnsadmin.example.com. ( >> 2020022104 >> 10800 >> 3600 >> 1209600 >> 3600 ) >> >> example.com. IN NS ns1.example.com. >> example.com. IN NS ns2.example.com. >> >> @IN CDS 0 0 0 00 >> @IN CDNSKEY 0 3 0 AA== >> SCHNAPP >> >> >> 21-Feb-2020 08:13:40.939 general: error: zone example.com/IN (unsigned): >> CDS/CDNSKEY consistency checks failed >> 21-Feb-2020 08:13:40.939 zoneload: error: zone example.com/IN (unsigned): >> not loaded due to errors. >> >> >> Thank you. >> >> Kind regards, >> Tom >> >> >> >> On 20.02.20 19:41, Mark Andrews wrote: >>> Tom, >>> I would run ‘rndc status’ or ‘dig ch txt version.bind @server’ and >>> confirm >>> that you have restarted named with the new code. I’ve had hundreds of 'bug >>> reports’ about non fixed bugs that where operators failing to restart named >>> after >>> installing the new version. The new code is in 9.16.0, 9.14.11, and >>> 9.11.16. >>> I would check that the *only* CDS record is a deletion record is present. >>> A CDS deletion record and a non CDS deletion record is a error. Similarly >>> for CDNSKEY. A CDS/CDNSKEY deletion record and other CDS/CDNSKEY records >>> in a RRset make no sense. You are either deleting all DS records or >>> replacing >>> all the DS records with the CDS records, or generating a new set of DS >>> records >>> from the CDNSKEY records. You can't do both at once. >>> Mark >>>> On 21 Feb 2020, at 03:54, Ondřej Surý wrote: >>>> >>>> Hi Tom, >>>> >>>>> On 20 Feb 2020, at 17:42, Tom wrote: >>>>> >>>>> Hi >>>>> >>>>> With 9.16.0, the CDS
CDS/CDNSKEY are not published with BIND-9.16.1 and dnssec-policies
Hi
Using BIND-9.16.1.
In the last ISC dnssec webinar
(https://www.youtube.com/watch?v=2aB__FZZQ84) I heared, that CDS/CDNSKEY
records automatically should be published when using dnssec-policies.
My policy looks like this:
dnssec-policy "test-policy" {
dnskey-ttl 60;
keys {
ksk lifetime unlimited algorithm ecdsa256;
zsk lifetime unlimited algorithm ecdsa256;
};
};
and the zone like this:
zone "example.com" {
type master;
file "master/example.com.zone";
key-directory "/etc/named/keys/example.com";
dnssec-policy "test-policy";
};
When digging this zone for CDS/CDNSKEY records, then these keys are not
existing:
$ dig +norec +noall +answer @127.0.0.1 cds example.com
$ dig +norec +noall +answer @127.0.0.1 cdnskey example.com
The keyfile for "example.com" also do not show a "published"-date:
$ cat Kexample.com.+013+02624.key
; This is a key-signing key, keyid 2624, for example.com.
; Created: 20200409061638 (Thu Apr 9 08:16:38 2020)
; Publish: 20200409061638 (Thu Apr 9 08:16:38 2020)
; Activate: 20200409061638 (Thu Apr 9 08:16:38 2020)
example.com. 60 IN DNSKEY 257 3 13
uV/NtPZSL1fmO3FAi4pZCcbTl19iD3SizgVcDXGJEl1g4l/cHUGvVl33
3cx2cODA6RUj55pZa77g1VBtFBXByg==
Any hints, why in this case the dnssec-policy mechanism doesn't publish
the CDS/CDNSKEY records?
Many thanks.
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
Hints for forwarding a subdomain on a authoritative server
Hi list
Our BIND (9.16.4) is authoritative for zone "example.com". Now I need to
forward a subzone "sub.example.com" to another nameserver instance on
the same server, running for example under port 5353:
A few years ago, this topic was already discussed:
https://lists.isc.org/pipermail/bind-users/2009-April/076156.html
My BIND config looks like this:
== SCHNIPP ==
zone "example.com" {
type master;
file "master/example.com.hosts";
};
zone "sub.example.com" {
type forward;
forwarders { 127.0.0.1 port 5353; };
forward only;
};
== SCHNAPP ==
In the zonefile for "example.com" I have a delegation like this (as
described in the post above):
sub.example.com.IN NS subns.example.com.
So, the authoritative server understands not to be responsible for this
zone and forwards the request to the other nameserver.
But: The zone-forwarding is only working, when I enable "recursion" on
the authoritative server. Does this means, that zone-forwarding really
requires recursion? Is there a better way with not enabling recursion
(perhaps with views) to accomplish this?
Many thanks for any hints.
Kind regards,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
managed-keys-error since BIND-9.16.15
Hi After upgrading to BIND-9.16.15, I have the following error in named.log: 30-Apr-2021 12:41:29.194 general: error: managed-keys.bind.jnw: journal file corrupt: expected serial 1823, got 1824 30-Apr-2021 12:41:29.194 general: error: managed-keys-zone: dns_journal_compact failed: unexpected error $ l /var/named/managed-keys.bind* -rw-r--r--. 1 named named 821 30. Apr 12:41 /var/named/managed-keys.bind -rw-r--r--. 1 named named 4.5K 30. Apr 12:41 /var/named/managed-keys.bind.jnl Yesterday (after initially starting the latest version) the error occured the first time on server1. Then I stopped named on server1, removed both files (.bind and .bind.jnl), and startet named again. Today, the same error appeared one time on server2, but named seems working fine, also DNSSEC verification. With "named-journalprint" I'm able to print to content of the managed-keys.bind.jnl. Any hints about this error? Thank you. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys-error since BIND-9.16.15
I see the same error also on a couple of slave zones on a updated authoritative server, not only on the "managed-keys.bind"-file. So this is also not critical and can be ignored? 03-May-2021 00:20:28.532 general: error: /var/named/slave/example.com.hosts.jnw: journal file corrupt: expected serial 2021050100, got 2021050300 03-May-2021 00:20:28.532 general: error: zone example.com/IN: dns_journal_compact failed: unexpected error Thank you. Kind regards, Tom On 01.05.21 08:52, Mark Andrews wrote: Named should automatically correct this error. The journal version was not updated when the transaction header was updated. This has been corrected and named detects the unexpected transaction header and writes out a corrected journal. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Using catz (catalog zones): BIND does not remove the catz-journal file on the slave
Hi Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), then the journal files are not removed on the slave: Current situation before removing the zone "example.com" from catz: $ ls -lahF -rw-r--r--. 1 named named 4.0K 28. Jul 15:21 __catz___default_catalog.123456.local_example.com.db -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl After removing the zone on the master (catz), the slave removes the __catz___default_...-files for the corresponding zone, but not the journal-file: 28-Jul-2021 15:29:56.018 general: info: catz: updating catalog zone 'catalog.123456.local' with serial 2021072803 28-Jul-2021 15:29:56.018 xfer-in: info: zone catalog.123456.local/IN: transferred serial 2021072803: TSIG 'master-slave' 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123456.local/IN' from 172.16.1.1#53: Transfer status: success 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123546.local/IN' from 172.16.1.1#53: Transfer completed: 1 messages, 5 records, 343 bytes, 0.001 secs (343000 bytes/sec) (serial 2021072803) 28-Jul-2021 15:29:56.020 general: info: catz: deleting zone 'example.com' from catalog 'catalog.123456.local' - success 28-Jul-2021 15:29:56.021 general: warning: catz: catz_delzone_taskaction: zone 'example.com' deleted $ ls -lahF -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl Is this intentional or possibly a bug? Many thanks. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question about "max-zone-ttl" in dnssec-policy
Hi list Testing dnssec-policy with BIND-9.16.21: I'd like to better understand the "max-zone-ttl"-directive. So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, but when I configure the default zone TTL or even a ressource record TTL higher than the "max-zone-ttl" (for example to 7200s), then it's not capped, as described in the documentation. Look here: - Within the dnssec-policy, I've defined "max-zone-ttl 3600;" - The RR "www.example.com." has a TTL of 7200 - The server returns a TTL of 7200 $ dig @192.168.1.10 www.example.com +dnssec +multi ... ... ;; ANSWER SECTION: www.example.com.7200 IN A 127.0.0.1 www.example.com.7200 IN RRSIG A 13 3 7200 ( 20211002202425 20210920143830 42786 example.com. 3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== ) ... ... What do I misunderstand here? Many thanks for a hint. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about "max-zone-ttl" in dnssec-policy
Hi Matthijs Thank you for your explanation. The documentation says, that "any record encountered with a TTL higher than max-zone-ttl is capped at the maximum permissible TTL value". Is the documentation wrong here? Thank you. Kind regards, Tom On 21.09.21 09:47, Matthijs Mekking wrote: Hi Tom, The max-zone-ttl is there to calculate the right timings for key rollovers. It won't alter the zone TTL values. You should set the max-zone-ttl to whatever the highest TTL is in your zone to make sure key rollovers timings are correct. This value exists until we have added code to the key manager that will read the zone's contents and detect the maximum TTL automatically. I hope this clarifies things. Best regards, Matthijs On 20-09-2021 17:47, Tom wrote: Hi list Testing dnssec-policy with BIND-9.16.21: I'd like to better understand the "max-zone-ttl"-directive. So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, but when I configure the default zone TTL or even a ressource record TTL higher than the "max-zone-ttl" (for example to 7200s), then it's not capped, as described in the documentation. Look here: - Within the dnssec-policy, I've defined "max-zone-ttl 3600;" - The RR "www.example.com." has a TTL of 7200 - The server returns a TTL of 7200 $ dig @192.168.1.10 www.example.com +dnssec +multi ... ... ;; ANSWER SECTION: www.example.com. 7200 IN A 127.0.0.1 www.example.com. 7200 IN RRSIG A 13 3 7200 ( 20211002202425 20210920143830 42786 example.com. 3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== ) ... ... What do I misunderstand here? Many thanks for a hint. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ECS-IP in the RPZ-Log?
Hi Using BIND-9.16.21. I'm wondering, if it's possible to have the ECS client IP address in the RPZ log. In front of our BIND, which has an RPZ configuration, is a dnsdist, which inject the ECS-IP. BIND could log the ECS-IP with the builtin "querylog" (rndc querylog on). In the following example, the effective client-IP is 172.16.16.33/32, which is logged fine here: 27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 172.16.16.33/32/0] But in the RPZ log, I can correctly see only the dnsdist IP and not the one from the effective source (172.16.16.33): 27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via example.ch.blacklist-rpz.test.local Is there a way to have/see the ECS-IP in the RPZ log? Many thanks. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-policy is not signing anymore
g
$ dig +short @127.0.0.1 +norec +dnssec dnskey example.ch
256 3 13 3YU6kADe6IRhJ2rcmHOrPgH6tq/7PQQP7VpLBA70p/bPQFPRagdxuGdl
XrDg7tQ9WTr553BA5dUGqRBEYYQTUw==
257 3 13 bT4QClt+P9+t1+vF/Ulj7DSISBVMV86TktfNqheiUVGqfZ2hsEpYP140
flVurgV17M/nzujoMW0KgyTuP3p4Kw==
The dnssec-policy looks like this:
dnssec-policy "thewaytogo-faster" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 30d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 7d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
When running "rndc sign example.ch", then nothing happens -> I'm not
sure, if "rndc sign" is still possible with "dnssec-policy"...?
Any hints, how I can recover this state to a working signing-state
without recreating a new KSK?
I assume, that disabling DNSSEC completely and creating a new ZSK/KSK
will work, but in the case now, I already have the mentioned KSK (61416).
Thank you.
Kind regards,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy is not signing anymore
Hi Matthijs
I've tried several times to reproduce this behavior..., dnssec-policy
always does his job. I did not currently succeed in reproducing the
behavior. I will make a few more attempts and otherwise inform you.
Thank you.
Best regards,
Tom
On 29.11.21 10:56, Matthijs Mekking wrote:
Hi Tom,
On 29-11-2021 09:36, Tom wrote:
Hi
Using BIND-9.16.22:
After some tests with the new KASP feature, I'm running in a issue,
where BIND isn't signing the zone anymore.
In the old fashion way (auto-dnssec maintain;), I was able - under
some circumstances - to remove the ".signed" and ".signed.jnl" and
.jnl-files, restart BIND and everything was fine, the zone was signed
automatically with the existing keys.
In the special case now, I removed the ZSK key files and removed all
.signed and .signed.jnl and .jnl-files for a zone (like in the old
way). The KSK is still existing, a new ZSK is created through the
"dnssec-policy":
The dnssec-policy checks the key files against the policy. If you remove
the ZSK key files, it has no ZSK any longer while the policy dictates
so. That's why it will create a new ZSK.
In other words, don't remove your key files.
(Removing .signed and .jnl files should be fine and be recreated).
## BIND detects the already existing KSK, but logs a warning the the
KSK is missing or inactive.
29-Nov-2021 07:28:25.653 dnssec: info: keymgr: DNSKEY
example.ch/ECDSAP256SHA256/27534 (ZSK) created for policy
thewaytogo-faster
29-Nov-2021 07:28:25.654 dnssec: info: Fetching
example.ch/ECDSAP256SHA256/61416 (KSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/61416 (KSK) is now published
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/61416 (KSK) is now active
29-Nov-2021 07:28:25.654 dnssec: info: Fetching
example.ch/ECDSAP256SHA256/27534 (ZSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY
example.ch/ECDSAP256SHA256/27534 (ZSK) is now published
29-Nov-2021 07:28:25.654 general: info: CDS for key
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.654 general: info: CDNSKEY for key
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.659 dnssec: info: zone example.ch/IN (signed):
next key event: 29-Nov-2021 09:33:25.641
29-Nov-2021 07:28:25.660 general: warning: zone example.ch/IN
(signed): Key example.ch/ECDSAP256SHA256/61416 missing or inactive and
has no replacement: retaining signatures.
I am not able to reproduce this. Is this after a restart or a reload?
Perhaps it's better to report an issue on our gitlab:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new
Please provide the steps to reproduce and logs with debug level 3.
Best regards,
Matthijs
## But the KSK (61416) is existing and seems signing
$ rndc dnssec -status example.ch
dnssec-policy: thewaytogo-faster
current time: Mon Nov 29 09:10:42 2021
key: 61416 (ECDSAP256SHA256), KSK
published: yes - since Tue Oct 12 16:50:17 2021
key signing: yes - since Tue Oct 12 16:50:17 2021
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 27534 (ECDSAP256SHA256), ZSK
published: yes - since Mon Nov 29 07:28:25 2021
zone signing: no
Next rollover scheduled on Mon Dec 6 05:23:25 2021
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: hidden
So, BIND detects the already existing KSK and ZSK, but is not able to
sign the dnskey-rrset with the KSK or some TXT-records with the ZSK.
## DNSKEY RR are existing, the RRSIG is missing
$ dig +short @127.0.0.1 +norec +dnssec dnskey example.ch
256 3 13 3YU6kADe6IRhJ2rcmHOrPgH6tq/7PQQP7VpLBA70p/bPQFPRagdxuGdl
XrDg7tQ9WTr553BA5dUGqRBEYYQTUw==
257 3 13 bT4QClt+P9+t1+vF/Ulj7DSISBVMV86TktfNqheiUVGqfZ2hsEpYP140
flVurgV17M/nzujoMW0KgyTuP3p4Kw==
The dnssec-policy looks like this:
dnssec-policy "thewaytogo-faster" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 30d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 7d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
When running "rndc sign example.ch", then nothing happens -> I'm not
sure, if "rndc sign" is still possible with "dnssec-policy"...?
Any hints, how I can recover this state to a working signing-state
without recreating a new KSK?
I assume, that disabling DNSSEC completely and creating a new ZSK/KSK
will work, but in the case now, I already have the mentioned KSK (61416).
Thank you.
Kind regards,
Changing ZSK-lifetime in dnssec-policy is not applied
Hi
Using BIND-9.16.22 and dnssec-policy:
I've migrated an already existing and signing "auto-dnssec"-configured
zone to dnssec-policy (same algorithms). That worked without any issues.
After a while, I changed the ZSK lifetime from 30d to 60d (see below) in
the dnssec-policy:
dnssec-policy "thewaytogo" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};
After reloading/restarting named, I can't see the new lifetime
(scheduled rollover), neither in the rndc-output, nor in the keyfile
itself (ZSK 63304). The new lifetime should be 12/13 Apr and not 13 Mar.
# rndc-output
$ rndc dnssec -status example.com
dnssec-policy: thewaytogo
current time: Fri Feb 11 13:02:10 2022
key: 455 (ECDSAP256SHA256), ZSK
published: yes - since Wed May 20 14:50:09 2020
zone signing: no
Key is retired, will be removed on Mon Jun 29 15:55:09 2020
- goal: hidden
- dnskey: omnipresent
- zone rrsig: unretentive
key: 63304 (ECDSAP256SHA256), ZSK
published: yes - since Fri Feb 11 08:19:18 2022
zone signing: yes - since Fri Feb 11 09:24:18 2022
Next rollover scheduled on Sun Mar 13 07:19:18 2022
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: rumoured
key: 39500 (ECDSAP256SHA256), KSK
published: yes - since Wed May 20 14:50:09 2020
key signing:yes - since Wed May 20 14:50:09 2020
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
# key-file
; This is the state of key 63304, for example.com.
Algorithm: 13
Length: 256
Lifetime: 2592000
Predecessor: 455
KSK: no
ZSK: yes
Generated: 20220211071918 (Fri Feb 11 08:19:18 2022)
Published: 20220211071918 (Fri Feb 11 08:19:18 2022)
Active: 20220211082418 (Fri Feb 11 09:24:18 2022)
Retired: 20220313082418 (Sun Mar 13 09:24:18 2022)
Removed: 20220323092918 (Wed Mar 23 10:29:18 2022)
DNSKEYChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
ZRRSIGChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
GoalState: omnipresent
Any hints for this?
Many thanks.
Best regards,
Tom
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Changing ZSK-lifetime in dnssec-policy is not applied
Hi Matthijs
Perfect, thank you for this information and clarifying this.
Best regards,
Tom
On 14.02.22 09:59, Matthijs Mekking wrote:
Hi Tom,
The lifetime is applied to new keys, so when the ZSK is rolled the
lifetime of the successor key should be 60 days.
I have considered applying it to existing keys as well (and maybe we
will some day), but there are a bunch of corner cases that make it
non-trivial, especially when keys are involved that are in the middle of
a rollover.
Best regards,
Matthijs
On 11-02-2022 13:16, Tom wrote:
Hi
Using BIND-9.16.22 and dnssec-policy:
I've migrated an already existing and signing "auto-dnssec"-configured
zone to dnssec-policy (same algorithms). That worked without any
issues. After a while, I changed the ZSK lifetime from 30d to 60d (see
below) in the dnssec-policy:
dnssec-policy "thewaytogo" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};
After reloading/restarting named, I can't see the new lifetime
(scheduled rollover), neither in the rndc-output, nor in the keyfile
itself (ZSK 63304). The new lifetime should be 12/13 Apr and not 13 Mar.
# rndc-output
$ rndc dnssec -status example.com
dnssec-policy: thewaytogo
current time: Fri Feb 11 13:02:10 2022
key: 455 (ECDSAP256SHA256), ZSK
published: yes - since Wed May 20 14:50:09 2020
zone signing: no
Key is retired, will be removed on Mon Jun 29 15:55:09 2020
- goal: hidden
- dnskey: omnipresent
- zone rrsig: unretentive
key: 63304 (ECDSAP256SHA256), ZSK
published: yes - since Fri Feb 11 08:19:18 2022
zone signing: yes - since Fri Feb 11 09:24:18 2022
Next rollover scheduled on Sun Mar 13 07:19:18 2022
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: rumoured
key: 39500 (ECDSAP256SHA256), KSK
published: yes - since Wed May 20 14:50:09 2020
key signing: yes - since Wed May 20 14:50:09 2020
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
# key-file
; This is the state of key 63304, for example.com.
Algorithm: 13
Length: 256
Lifetime: 2592000
Predecessor: 455
KSK: no
ZSK: yes
Generated: 20220211071918 (Fri Feb 11 08:19:18 2022)
Published: 20220211071918 (Fri Feb 11 08:19:18 2022)
Active: 20220211082418 (Fri Feb 11 09:24:18 2022)
Retired: 20220313082418 (Sun Mar 13 09:24:18 2022)
Removed: 20220323092918 (Wed Mar 23 10:29:18 2022)
DNSKEYChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
ZRRSIGChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
GoalState: omnipresent
Any hints for this?
Many thanks.
Best regards,
Tom
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
"Length"-output in DNSSEC-Policy state-files vs. "Key Length"-output on dnsviz.net
Hi list Using BIND-9.16.27: I'm wondering about the value of the "Length"-field in the dnssec-policy state-file output, which results in "Length: 256" for domains, which are signed with algorithm 13 (ECDSAP256SHA256) and the "Key length"-output for the domain on "dnsviz.net" (ZSK or KSK), which results in "Key Length: 512". # state file $ grep Length Karcademics.ch.+013+19238.state Length: 256 # The ZSK/KSK for this domain on "dnsviz.net" Key Length: 512 What's the difference between this both values? Many thanks. Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "Length"-output in DNSSEC-Policy state-files vs. "Key Length"-output on dnsviz.net
Hi Tony Many thanks for your explanation! Tom On 10.05.22 10:46, Tony Finch wrote: Tom wrote: I'm wondering about the value of the "Length"-field in the dnssec-policy state-file output, which results in "Length: 256" for domains, which are signed with algorithm 13 (ECDSAP256SHA256) That's the size of the cryptographic modulus, i.e. the size of the numbers in the guts of the cryptographic algorithm. and the "Key length"-output for the domain on "dnsviz.net" (ZSK or KSK), which results in "Key Length: 512". For P-256 the public key needs two coordinates to identify the point on the curve, so it's twice the nominal size of the algorithm. DNSviz is not being entirely consistent here, because RSA public keys also require a few more bits than their nominal size (for the public exponent), but DNSviz shows their nominal size rather than the size of the public key blob in the DNSKEY record. (The public exponent is usually 65537, which is why RSA keys typically start AwEAA rather than being completely random.) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK
Hi list
After switching from "semi-automatic"-signing to dnssec-policy
(everything identical, except new ZSK rollover) I have the following
rndc output:
$ rndc dnssec -status example.ch
dnssec-policy: 60d_zsk_rollover
current time: Wed May 11 09:54:55 2022
key: 45819 (ECDSAP256SHA256), KSK
published: yes - since Mon Apr 27 08:00:01 2020
key signing:yes - since Mon Apr 27 08:00:01 2020
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 17242 (ECDSAP256SHA256), ZSK
published: yes - since Mon May 9 16:25:59 2022
zone signing: yes - since Mon May 9 17:30:59 2022
Next rollover scheduled on Fri Jul 8 15:25:59 2022
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: rumoured
key: 52021 (ECDSAP256SHA256), ZSK
published: yes - since Mon Apr 27 08:00:01 2020
zone signing: no
Key is retired, will be removed on Mon Jul 6 09:05:01 2020
- goal: hidden
- dnskey: omnipresent
- zone rrsig: unretentive
The ZSK 52021 is the old one (from semi-automatic), the ZSK 17242 is the
new one, which was created after reloading named while applying the new
dnssec-policy.
The current behavior I see is, that already existing RR are still signed
with the "old" key (52021) and newly created RR are signed with the new
ZSK (17242). Is this normal behavior and yes, after which time will the
existing RR also be signed with the new ZSK (17242)?
The dnssec-policy configuration looks like this:
dnssec-policy "60d_zsk_rollover" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};
Many thanks for hints/explanations.
Best regards,
Tom
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK
On 11.05.22 11:26, Mark Andrews wrote: Signature-refresh determines when the RRSIGs will be replaced by looking at the expiration time and working backwards. New RRSIGs are generate Using signature-interval. Ah, perfect. Thx. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question about additional section in BIND-responses
Hi list Using BIND-9.18.5 as a recursive server: What's the reason, that BIND answers with the additional section for the the following query where for example Knot resolver and also PowerDNS resolver doesn't add the additional section for the same query? # Querying BIND $ dig @test ns bastelwurstel.ch ; <<>> DiG 9.18.5 <<>> @test ns bastelwurstel.ch ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44509 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5591e3c9e8f24edb010062fbb2eb6e52ddd8fb37 (good) ;; QUESTION SECTION: ;bastelwurstel.ch. IN NS ;; ANSWER SECTION: bastelwurstel.ch. 288 IN NS ns2.netnoise.ch. bastelwurstel.ch. 288 IN NS ns1.netnoise.ch. ;; ADDITIONAL SECTION: ns1.netnoise.ch.3565IN A 46.22.21.106 ns2.netnoise.ch.3565IN A 46.22.21.107 ;; Query time: 0 msec ;; SERVER: 10.100.102.21#53(test) (UDP) ;; WHEN: Tue Aug 16 17:08:27 CEST 2022 ;; MSG SIZE rcvd: 152 # Querying Knot $ dig @localhost -p ns bastelwurstel.ch ; <<>> DiG 9.18.5 <<>> @localhost -p ns bastelwurstel.ch ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1240 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;bastelwurstel.ch. IN NS ;; ANSWER SECTION: bastelwurstel.ch. 600 IN NS ns2.netnoise.ch. bastelwurstel.ch. 600 IN NS ns1.netnoise.ch. ;; Query time: 44 msec ;; SERVER: 127.0.0.1#(localhost) (UDP) ;; WHEN: Tue Aug 16 17:23:27 CEST 2022 ;; MSG SIZE rcvd: 90 BIND (resolver) is configured with "minimal-responses yes;", but I assume this is an authoritative-only-option, right? When flushing the cache for the servers mentioned in the additional section (rndc flushname ns1.netnoise.ch; rndc flushname ns2.netnoise.ch), then the response looks similar to Knot's/PDNS's response: # Querying BIND after flushing the cache $ dig @test ns bastelwurstel.ch ; <<>> DiG 9.18.5 <<>> @test ns bastelwurstel.ch ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39403 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 6d897a3fd76dd815010062fbb44d5082963f3c5dedd4 (good) ;; QUESTION SECTION: ;bastelwurstel.ch. IN NS ;; ANSWER SECTION: bastelwurstel.ch. 596 IN NS ns2.netnoise.ch. bastelwurstel.ch. 596 IN NS ns1.netnoise.ch. ;; Query time: 4 msec ;; SERVER: 10.100.102.21#53(test) (UDP) ;; WHEN: Tue Aug 16 17:14:21 CEST 2022 ;; MSG SIZE rcvd: 120 Any hints why BIND adds the additional section while other resolvers doesn't? Is there an option in BIND to behave like Knot/PDNS? Many thanks. Regards, Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about additional section in BIND-responses
On 8/17/22 02:27, Evan Hunt wrote: On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote: Using BIND-9.18.5 as a recursive server: What's the reason, that BIND answers with the additional section for the the following query where for example Knot resolver and also PowerDNS resolver doesn't add the additional section for the same query? [...] Any hints why BIND adds the additional section while other resolvers doesn't? Is there an option in BIND to behave like Knot/PDNS? The option is "minimal-responses". If you set it to "yes", it will omit authority and additional section data except when necessary. The default is "no-auth-recursive", which omits authority section data when it isn't strictly necessary, but will still add additional data for records in the answer section. I've already set "minimal-responses yes;", but the additional section/data is still shown. So based on your explanation, BIND assumes, this data is necessary, why? And why behaves BIND different here than Knot/PDNS where no additional section is shown for the same query? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about additional section in BIND-responses
On 8/17/22 06:45, Tom wrote: On 8/17/22 02:27, Evan Hunt wrote: On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote: Using BIND-9.18.5 as a recursive server: What's the reason, that BIND answers with the additional section for the the following query where for example Knot resolver and also PowerDNS resolver doesn't add the additional section for the same query? [...] Any hints why BIND adds the additional section while other resolvers doesn't? Is there an option in BIND to behave like Knot/PDNS? The option is "minimal-responses". If you set it to "yes", it will omit authority and additional section data except when necessary. The default is "no-auth-recursive", which omits authority section data when it isn't strictly necessary, but will still add additional data for records in the answer section. I've already set "minimal-responses yes;", but the additional section/data is still shown. So based on your explanation, BIND assumes, this data is necessary, why? And why behaves BIND different here than Knot/PDNS where no additional section is shown for the same query? Does an BIND expert has an idea or an explanation, why the additional section is still shown, although "minimal-responses yes;" is set? And why the additional section seems necessary for BIND and not for example for Knot/PDNS for the same query? Many thanks for any hints. Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'inline-signing' might go away and be replaced by dnssec-policy ?
On 10/26/22 10:19, Matthijs Mekking wrote:
Thanks for this. It probably should be removed from the docs at this point.
When introducing dnssec-policy, my goal was to reduce the dozens of
DNSSEC related configuration options that are scattered throughout
named.conf and contain them in one stanza. But some options are more
difficult to be replaced than others.
On 24-10-2022 18:16, PGNet Dev wrote:
i've read this comment
'inline-signing' might go away and be replaced by dnssec-policy
now a few times, in posts and in docs
currently, WITH 'dnssec-policy' signing enabled & in-use, i've
zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
dnssec-policy "test";
inline-signing yes;
...
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in
order to _not_ overwrite original zone files/data on signing. e.g.,
with the config above
cd namedb/primary/
ls -1 *example*
example.com.zone < THIS is the original,
unsigned zone data
example.com.zone.jbk
example.com.zone.jnl
example.com.zone.signed < THIS is the signing-generated
zone data, which gets propagated
example.com.zone.signed.jnl
without it, the original "example.com.zone" is overwritten with signed
data.
is there already config in, or planned for, 'dnssec-policy' that
preserves that separate-file functionality, preserving the original?
There are two ways of DNSSEC maintenance in BIND. One is the
inline-signing approach, that preserves the original zone file. The
other is to apply the changes directly to the zone (and zone file) and
requires the zone to allow dynamic updates.
Since the latest release dnssec-policy requires either inline-signing to
be set to yes, or allow dynamic updates.
I am thinking of adding inline-signing to dnssec-policy, do you think
that would that be useful?
Matthijs,
Yes, from my point of view, that would surely be useful. I would very
much welcome a configuration option within the dnssec-policy-statement,
to globally enable inline-signing for all dnssec-signed zones.
Best regards,
Matthijs
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Hi Marco Probably Knot could help here (https://www.knot-dns.cz/docs/3.2/html/modules.html#synthrecord-automatic-forward-reverse-records) where Knot is able to generate IPv6-PTR and IPv6- based on a pattern "on-the-fly". Do you want to achieve something like this? # Reverse-Lookup $ dig @resolver +short -x 2a02:1368:6000::cafe static-2a02-1368-6000--cafe.cust.swissbackbone.net. # Forward-Lookup () $ dig @resolver +short static-2a02-1368-6000--cafe.cust.swissbackbone.net. 2a02:1368:6000::cafe Best regards, Tom On 10/27/22 19:23, Marco wrote: Am 27.10.2022 um 09:52:55 Uhr schrieb Grant Taylor via bind-users: This is a singular IP (presumably link-net) for a customer. So there would be exactly one forward and one reverse PTR record. It isn't, because a customer gets /48 or /56 in most cases. The customer's router can use various methods to assign addresses, auto configuration and DHCPv6. If the ISP wants to provide reverse zone for all possible addresses (ISP doesn't know which one of the assigned are used by the customer), it must have all reverse zones on their zone file or dynamically create them when a DNS server receives a request. I remember years ago that DHCP servers could be configured to dynamically update the forward and / or reverse zone when providing a lease to a client. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'inline-signing' might go away and be replaced by dnssec-policy ?
On 10/26/22 13:13, Tom wrote:
On 10/26/22 10:19, Matthijs Mekking wrote:
Thanks for this. It probably should be removed from the docs at this
point.
When introducing dnssec-policy, my goal was to reduce the dozens of
DNSSEC related configuration options that are scattered throughout
named.conf and contain them in one stanza. But some options are more
difficult to be replaced than others.
On 24-10-2022 18:16, PGNet Dev wrote:
i've read this comment
'inline-signing' might go away and be replaced by dnssec-policy
now a few times, in posts and in docs
currently, WITH 'dnssec-policy' signing enabled & in-use, i've
zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
dnssec-policy "test";
inline-signing yes;
...
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in
order to _not_ overwrite original zone files/data on signing. e.g.,
with the config above
cd namedb/primary/
ls -1 *example*
example.com.zone < THIS is the original,
unsigned zone data
example.com.zone.jbk
example.com.zone.jnl
example.com.zone.signed < THIS is the
signing-generated zone data, which gets propagated
example.com.zone.signed.jnl
without it, the original "example.com.zone" is overwritten with
signed data.
is there already config in, or planned for, 'dnssec-policy' that
preserves that separate-file functionality, preserving the original?
There are two ways of DNSSEC maintenance in BIND. One is the
inline-signing approach, that preserves the original zone file. The
other is to apply the changes directly to the zone (and zone file) and
requires the zone to allow dynamic updates.
Since the latest release dnssec-policy requires either inline-signing
to be set to yes, or allow dynamic updates.
I am thinking of adding inline-signing to dnssec-policy, do you think
that would that be useful?
Matthijs,
Yes, from my point of view, that would surely be useful. I would very
much welcome a configuration option within the dnssec-policy-statement,
to globally enable inline-signing for all dnssec-signed zones.
Matthijs, regarding your question about "adding inline-signing to
dnssec-policy": Is this something you'll be implementing in the near future?
Best regards,
Matthijs
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DF-Flag on UDP-based sockets?
Hi list Regarding ARM 9.18.9 (https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-edns-udp-size): "The named now sets the DON’T FRAGMENT flag on outgoing UDP packets." Tested with BIND-9.18.9, I didn't saw any UDP packets, where the "DF"-flag was set on the IP header (true for TCP, but never seen for UDP). Which circumstands or which queries enforces BIND9 to set the "DF"-flag on outgoing UDP-based packets? Any hints for this? Thanks a lot. Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DF-Flag on UDP-based sockets?
On 11/30/22 09:27, Borja Marcos wrote: On 30 Nov 2022, at 08:20, Tom wrote: Hi list Regarding ARM 9.18.9 (https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-edns-udp-size): "The named now sets the DON’T FRAGMENT flag on outgoing UDP packets." Tested with BIND-9.18.9, I didn't saw any UDP packets, where the "DF"-flag was set on the IP header (true for TCP, but never seen for UDP). Which circumstands or which queries enforces BIND9 to set the "DF"-flag on outgoing UDP-based packets? I have checked on FreeBSD 13.1 and indeed I don’t see the flag. Neither for UDP queries or responses. What OS are you trying? Might be OS dependant. I'm trying on linux. It seems, that this behavior was introduced with https://gitlab.isc.org/isc-projects/bind9/-/commit/371f829327b8f4cdfae4fa0cca512dcf483eff23 and reverted with https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4668/diffs but the ARM wasn't reverted/corrected. Does someone of ISC agree? If so, I'll file a bug. Thank you. Tom Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND-RPZ and Views
Hi What is the supported/preferred way for implementing slave-rpz's in views? I want to achieve, that view1 has a different policy-configuration (passthru, given, nxdomain..) than the ones configured in view2 using the same slave-rpz-files. If not obligatory, I would not synchronize/transfer the slave-zone again...just for the view2. Thank you. Tom On 09/16/2016 12:22 PM, Tony Finch wrote: Anand Buddhdev wrote: In newer versions of BIND, you cannot share a writable file in different views. This is a bad configurtion, and newer versions of BIND reject it. Just use different file names. To clarify, you couldn't in older versions of BIND either! It would cause weird data corruption problems. Tony. ___ 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
Running current version of bind in a jail?
Hi list From https://kb.isc.org/article/AA-00768/0/Getting-started-with-BIND-how-to-build-and-run-named-with-a-basic-recursive-configuration.html: "Running named in a chroot jail (many still do, but this shouldn't be necessary with modern versions of BIND)".: What's the reason, that it isn't necessary to run modern version of bind in a jail? 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
response-rate-limiting - "window" explained?
Hi Can someone explain the behaviour of "window" in the rate-limit-context? I've tried "responses-per-second 10; window 3;" and had the same results as "responses-per-second 10; window 5;". Any simple explanation for the "window"-directive? Many thanks. 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
Question about: "rate-limit: stop limiting responses to 1.1.1.0/24 for www.example.com"
Hi list
I'm testing rate-limits (BIND 9.11.2) and I'm unsure, how I've to
understand the following "stop-limiting"-log-entry:
1)
04-Jan-2018 15:09:10.852 rate-limit: info: limit responses to 1.1.1.0/24
for www.example.com IN A (7ae73d9b)
2)
04-Jan-2018 15:09:10.852 rate-limit: info: client @0x7f16440ee550
13.93.86.165#55203 (www.example.com): rate limit drop response to
1.1.1.0/24 for www.example.com IN A (7ae73d9b)
3)
04-Jan-2018 15:09:16.773 rate-limit: info: client @0x7f16440fcc30
13.93.86.165#33997 (www.example.com): rate limit drop response to
1.1.1.0/24 for www.example.com IN A (7ae73d9b)
4)
04-Jan-2018 15:10:20.266 rate-limit: info: stop limiting responses to
1.1.1.0/24 for www.example.com IN A (7ae73d9b)
- #1-#3 seems clear, because they reaches the configured threshold. But
what about the entry #4? Why does this logentry only appears about 60-65
seconds later, after I've stopped the "test"-attack (confirmed multiple
times..)?
My rate-config:
rate-limit {
responses-per-second 5;
slip 0;
window 5;
};
Many thanks.
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
Re: response-rate-limiting - "window" explained?
I've tested several "window"-values (5-3600) with fast-querying the
nameserver from one single client with always the same query. As
explained by Tony the "window" means the time, which the client must
wait, after he stops fast-querying the nameserver while he was
successfully dropped.
In my tests, I never had to wait for about more than about 5s.
I've configured rate-limits like this:
rate-limit {
responses-per-second 5;
slip 0;
window 5;
log-only no; };
Could someone explain the problem here? Why do I never have to wait
longer than about 5s until I'm able to query the nameserver from the
unique client with the same query again?
Many thanks.
Kind regards,
Tom
On 03/27/2017 11:33 AM, Tony Finch wrote:
Tom wrote:
Can someone explain the behaviour of "window" in the rate-limit-context?
It basically determines the time after a client that was querying very
fast but then stopped is allowed to receive responses again.
When a client repeats a query, its counter is decremented until it reaches
the minimum `-1 * window * responses-per-second`. Its counter is
incremented by `responses-per-second` each second, so after the client
stops querying it will be `window` seconds before the counter becomes
positive which means the client is allowed to receive responses again.
Tony.
___
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: response-rate-limiting - "window" explained?
Mmmh...I can't verify the meaning of the "window"-value. In my
flood-tests, it makes no differences, if I set this value to 5 or 60 or
even 3600. The only value which affects the behavior is "slip" and
"responses-per-second".
When I fast-querying (100r/s) the nameserver with the following
configuration:.
rate-limit {
responses-per-second 5;
slip 0;
window 5;
log-only no;
};
the nameserver answers always every five seconds for five requests:
Mon Jan 8 07:36:05 CET 2018 querying example.org
Mon Jan 8 07:36:05 CET 2018 querying example.org
Mon Jan 8 07:36:05 CET 2018 querying example.org
Mon Jan 8 07:36:05 CET 2018 querying example.org
Mon Jan 8 07:36:05 CET 2018 querying example.org
Mon Jan 8 07:36:10 CET 2018 querying example.org
Mon Jan 8 07:36:10 CET 2018 querying example.org
Mon Jan 8 07:36:10 CET 2018 querying example.org
Mon Jan 8 07:36:10 CET 2018 querying example.org
Mon Jan 8 07:36:10 CET 2018 querying example.org
Mon Jan 8 07:36:15 CET 2018 querying example.org
Mon Jan 8 07:36:15 CET 2018 querying example.org
Mon Jan 8 07:36:15 CET 2018 querying example.org
Mon Jan 8 07:36:15 CET 2018 querying example.org
Mon Jan 8 07:36:15 CET 2018 querying example.org
And here it makes no differences, if I set the "window"-value to 5 or 60
or 3600.
Any hints / explanation for the behavior of the "window"-value?
Many thanks.
Tom
On 01/05/2018 07:27 PM, Tony Finch wrote:
Tom wrote:
Could someone explain the problem here? Why do I never have to wait longer
than about 5s until I'm able to query the nameserver from the unique client
with the same query again?
The 60s is the delay after a client has stopped making queries when the
information about that client can be forgotten. RRL logs "stop limiting"
at that point which is a bit misleading.
Tony.
___
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: response-rate-limiting - "window" explained?
On 01/08/2018 12:37 PM, Tony Finch wrote: Tom wrote: Mmmh...I can't verify the meaning of the "window"-value. In my flood-tests, it makes no differences, if I set this value to 5 or 60 or even 3600. You'll only notice the window if you pause your flood test - it's basically the recovery time. (This is why the "stop limiting" log message is misleading: RRL actually stops limiting after the window passes, but it logs 60s later.) This delayed log-entry seems now clear. The relevant part of the ARM is: Response rate limiting uses a "credit" or "token bucket" scheme. Each combination of identical response and client has a conceptual account that earns a specified number of credits every second. A prospective response debits its account by one. Responses are dropped or truncated while the account is negative. Responses are tracked within a rolling window of time which defaults to 15 seconds, but can be configured with the window option to any value from 1 to 3600 seconds (1 hour). The account cannot become more positive than the per-second limit or more negative than window times the per-second limit. When the specified number of credits for a class of responses is set to 0, those responses are not rate limited. So, during your flood test, your client's token bucket will have its minimym value, -1 * window * responses-per-second. When it stops, the token bucket value will increase by `responses-per-second` each second, so it will increase past zero after `window` seconds, and at that point RRL will stop dropping responses. This means, that with a "window 30;", I'll have to wait for about 30s until the nameserver stops dropping requests (after I've stopped flooding)right? In my tests, this never matches. If I set the "responses-per-second 5;" and the "window 30;", then begin flooding (the responses are correctly dropped), then stop flooding, then querying the nameserver from the same source for the same RR, I'll get immediately the right answer. Any explanations for this behavior? Kind regards, Tom Tony. ___ 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: response-rate-limiting - "window" explained?
On 01/09/2018 02:49 PM, Tony Finch wrote: Tom wrote: If I set the "responses-per-second 5;" and the "window 30;", then begin flooding (the responses are correctly dropped), then stop flooding, then querying the nameserver from the same source for the same RR, I'll get immediately the right answer. Any explanations for this behavior? Try more than once - you are probably seeing the effect of the "slip" setting, which is supposed to allow legitimate clients to get answers even when they are being spoofed by a DDoS attack. I tried many times with different values for "window" (window 5;, window 30;, window 3600;) Always the same effect with the following command: while true; do echo -n "$(date) "; dig +short +ignore +tries=1 @x.x.x.x www.example.com; sleep .01; done Slip is set to "0" (always drop). After stopping the flood, I'm immediately able to query the same record (www.example.com) with a positive answer. Does the "window 5;" or "window 30;" or "window 3600;" possibly has no effect? Thank you. Kind regards, Tom Also, if you are using DiG then to see the proper effect you'll want to set the +ignore +tries=1 options (and maybe +timeout=1). Tony. ___ 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: response-rate-limiting - "window" explained?
On 01/09/2018 05:11 PM, Tony Finch wrote: Tom wrote: Slip is set to "0" (always drop). After stopping the flood, I'm immediately able to query the same record (www.example.com) with a positive answer. Does the "window 5;" or "window 30;" or "window 3600;" possibly has no effect? The script below works for me. My server is configured with responses-per-second 2; slip 0; The script "floods" at 10 qps for 15 seconds (enough to fill the window), then drops to 1qps and times how long it takes to recover. At the end it says the recovery time was 20 seconds. This is a bit more than the window size because I wasn't completely quiet during the recovery time. Many thanks for this hint/script. The rate-limit works as explained. My misunderstanding was, that I didn't set the query-process(es) in the background. Kind regards, Tom #!/bin/sh set -eu dig='dig +ignore +tries=1 +timeout=1 +norec dotat.at @grey.dotat.at' start=$(date +%s) while [ $(date +%s) -lt $(($start + 15)) ] do $dig | grep aa & sleep 0.1 done end=$(date +%s) while ! $dig | grep aa do :; done echo $(( $(date +%s) - $end )) Tony. ___ 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
DNSSEC and automatic renewal of RRSIG-expiration-time
Hi list Using latest BIND (9.12.1) with dnssec and inline-signing enabled. SIG-VALIDITY-INTERVAL is set to 1 day (for testing). Look the following RRSIG: test01.example.com. 300 IN RRSIG A 8 3 300 ( 20180504060124 20180503052321 1 test01.example.com. rUch7bFR18Nmaeu+gqS29fG8oTPQm1SIBe9x+0iVPpXw GnXBy6bZacXiBwYPjgJd7GK+3giGq/Mw2URXexW8PuuV IGBz8bRUczNbQPHsaZUWXlv32RelJArykWB8S/N5pvOn r8Q9w4asKR6JNiDnzoF/09EVlSyXvaluVrZT7kMGKdgC OB7H20kwcBkGdwUYMclna2XmddQMeicc5yjxglQgpg89 48Om5L8A0hjGDQEyTTTaOA91D+7/F2yI99TPvSYizC+6 vYUoleAIWQi3GRG/KJRd9N8OouZIYgOtf2jKPwsEQwhQ sS7G3w4BxrkEB8Q8btx5CWaKX2CVD8Jv2A== ) The record does expire in a few hours. Does the "inline-signing"-mechanism also automatically renew the expiration-time of the RRSIGs? If so: When or in which interval does BIND verify the expiration-times of the RRSIGs and renew them? If no, what do I have to do, to force BIND automatically to renew the RRSIGs? 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
Re: Logrotate for bind9
On 07/04/2018 04:00 PM, Anand Buddhdev wrote: On 04/07/2018 15:50, Blason R wrote: Hi There, I am not getting appropriate results for my custom daily logrorate for bind9 logs on Ubuntu. It's more useful if you show us your logrotate snippet, so we can point out what is wrong with it. Can someone please help me with the settings which would include below stuff 1. Should rotate daily daily 2. Compress compress 3. create new file Usually not needed, because BIND creates the log file itself. 4. keep last 180 entries rotate 180 Do I need stop bind9 while logs are being rotated? What is the correct procedure to start logs in new file? You don't have to stop BIND to rotate log files. Instead, you just run "rndc reconfig" and that causes BIND to reopen its log files. If it finds that the files have been moved (by logrotate) it will create new log files. ...or you use "copytruncate", so the file will be copied and the other stuff (compress, rotate 180, etc..) and then truncated, so BIND has still the same filedescriptors open, but the logfile is rotated :-). This way, you don't need to "rndc reconfig". Kind regards, Tom Anand ___ 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
Understanding TTL in "rndc dumpdb"-output
Hi After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN response with a minimum-ttl (in the soa) of 3600. When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc dumpdb" and look for the negative ttl, then a value much bigger than 3600 is shown (608363): # grep testbla /var/named/data/named_dump.db testbla11.example.com. 608363 \-ANY ;-$NXDOMAIN This number decrements every second. What is this number? The same behavior for positive answers too. The A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc dumpdb"-output I have a value for 605082. Any hints? 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
Re: Understanding TTL in "rndc dumpdb"-output
Hi Michal Thank you for this feedback. I've checked the serve-stale status, which is currently off. # rndc serve-stale status _default: off (stale-answer-ttl=1 max-stale-ttl=604800) _bind: off (stale-answer-ttl=1 max-stale-ttl=604800) Is this a normal behavior, that in the "rndc dumpdb" nevertheless the TTL in the form of "serve-stale" is shown (even if the serve-stale-status = off)? Thank you. Tom On 23.10.18 10:25, Michał Kępień wrote: After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN response with a minimum-ttl (in the soa) of 3600. When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc dumpdb" and look for the negative ttl, then a value much bigger than 3600 is shown (608363): # grep testbla /var/named/data/named_dump.db testbla11.example.com. 608363 \-ANY ;-$NXDOMAIN This number decrements every second. What is this number? The same behavior for positive answers too. The A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc dumpdb"-output I have a value for 605082. This happens due to the serve-stale feature being available in BIND 9.12 and later, with max-stale-ttl set to 604800 by default (note that this does *not* mean serving stale answers is enabled by default). The TTLs you are seeing in the cache dump essentially indicate how much longer any given record will be kept in the cache database. The serve-stale "offset" is indicated in a comment near the top of the dump; I am fairly sure it will say "; using a 604800 second stale ttl" in your case. ___ 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
Rewrite/Override QTYPE with RPZ
Hi all Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is this planned in future releases of BIND? 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
Re: Rewrite/Override QTYPE with RPZ
Fore example "example.com" and "*.example.com" are blacklisted. I would like to return a real ip address for special query types like MX or TXT, but not for A or . Tom On 08.11.18 16:44, Barry Margolin wrote: In article , Tom wrote: Hi all Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is this planned in future releases of BIND? What would be the point? If a query is for MX, and you return A instead, the client won't be able to do anything with it. ___ 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: Rewrite/Override QTYPE with RPZ
I mean the other way: My feeded RPZ blocks othercompany.com and *.othercompany.com. Therefore any qtype (MX, A, ...) are blocked for this domain. Is there a way with BIND just to whitelist the MX for othercompany.com and the consequent A-Record (ex. mail.othercompany.com) that we are able to send mail to othercompany.com? On 09.11.18 14:39, Lightner, Jeffrey wrote: That wouldn't help you much. Many mail systems these days check not only your MX record but also your PTR record to make sure the IP you came from has a valid (i.e. not generic) reverse lookup. They'll also check things like dkim or spf TXT records. If they don't like what they find they'll simply reject email even if you haven't been blacklisted. In general blacklisting services blacklist specific IPs rather than domains anyway. A work around would be to change the outbound IP your mail server uses rather than changing other records. Of course you'd have to make additional changes for the PTR, A/ and TXT records for the new IP you select. Many blacklisting services have a way to delist yourself. However, if you don't fix the underlying problem that caused you to be blacklisted in the first place any new IP will quickly be blacklisted as well and/or delisting yourself a second time is much more difficult. If you are sending multiple automated emails (e.g. invoices or marketing materials) to customers you need to be monitoring for returns and removing rejected email addresses from your databases. These often occur because the customer no longer has the email address they originally gave you (or they had a typo in what they gave you). -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tom Sent: Thursday, November 08, 2018 11:49 PM To: bind-users@lists.isc.org Subject: Re: Rewrite/Override QTYPE with RPZ Fore example "example.com" and "*.example.com" are blacklisted. I would like to return a real ip address for special query types like MX or TXT, but not for A or . Tom On 08.11.18 16:44, Barry Margolin wrote: In article , Tom wrote: Hi all Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is this planned in future releases of BIND? What would be the point? If a query is for MX, and you return A instead, the client won't be able to do anything with it. ___ 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 ___ 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: Rewrite/Override QTYPE with RPZ
Hi Daniel Thank you for your feedback. This could be a solution. It seems, that unbound can do this (not verified) and BIND-RPZ can't do this actually: https://serverfault.com/questions/18748/overriding-some-dns-entries-in-bind-for-internal-networks Any plans for BIND? Tom On 12.11.18 08:14, Daniel Stirnimann wrote: Hello Tom, My feeded RPZ blocks othercompany.com and *.othercompany.com. Therefore any qtype (MX, A, ...) are blocked for this domain. Is there a way with BIND just to whitelist the MX for othercompany.com and the consequent A-Record (ex. mail.othercompany.com) that we are able to send mail to othercompany.com? If the action of your RPZ policy is a CNAME redirecting the user to a walled garden and that walled garden runs an MTA you could configure it as a relay server. We have a similar setup where the MTA on the walled garden rejects the email so that the sending MTA immediately gets a feedback. 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
BIND 9.12.3-P1: No additional section
Hi list, After migrating from 9.11.x to 9.12.3-P1, I recognized, that BIND is giving no "additional sections" back, although "minimal-responses" is set to "no". I think this is correct and does not affect the authoritative behavior. But I don't understand, why this happens when "minimal-responses no;" is configured. 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
Re: BIND 9.12.3-P1: No additional section
Authoritative servers: A direct query to a BIND-9.12.3-P1 authoritative server for "mydomain.net": $ dig +norec -4 @ns3.example.com www.mydomain.net ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec -4 @ns3.example.com www.mydomain.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36984 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 847bc109e7f71243dd664e215c3ec4c412619cff362fd7fc (good) ;; QUESTION SECTION: ;www.mydomain.net. IN A ;; ANSWER SECTION: www.mydomain.net. 3600IN A 44.44.44.44 ;; AUTHORITY SECTION: mydomain.net. 3600IN NS ns3.example.com. mydomain.net. 3600IN NS ns2.example.com. mydomain.net. 3600IN NS ns1.example.com. The same direct query here to a BIND-9.11.x authoritative server (also a slave like the BIND-9.12.3-P1) for "mydomain.net": $ dig +norec -4 @ns1.example.com www.mydomain.net ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec -4 @ns1.example.com www.mydomain.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24450 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 975a61dc07fe107fc5acdc2d5c3ec54df206b954894a2c4f (good) ;; QUESTION SECTION: ;www.mydomain.net. IN A ;; ANSWER SECTION: www.mydomain.net. 3600IN A 44.44.44.44 ;; AUTHORITY SECTION: mydomain.net. 3600IN NS ns2.example.com. mydomain.net. 3600IN NS ns1.example.com. mydomain.net. 3600IN NS ns3.example.com. ;; ADDITIONAL SECTION: ns1.example.com.7200IN A 1.1.1.1 ns2.example.com.7200IN A 2.2.2.2 ns3.example.com.7200IN A 3.3.3.3 ns1.example.com.7200IN 2001:db8::1 ns2.example.com.7200IN 2001:db8::2 ns3.example.com.7200IN 2001:db8::3 In both authoritative configurations I've set "minimal-responses no;", but on 9.12.3-P1, no additional section comes back. Thank you. Kind regards, Tom On 15.01.19 19:15, Evan Hunt wrote: On Tue, Jan 15, 2019 at 02:40:51PM +0100, Tom wrote: After migrating from 9.11.x to 9.12.3-P1, I recognized, that BIND is giving no "additional sections" back, although "minimal-responses" is set to "no". I think this is correct and does not affect the authoritative behavior. But I don't understand, why this happens when "minimal-responses no;" is configured. Authoritative or recursive? Can you give a specific example of a query that isn't getting an additional section and should? ___ 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: BIND 9.12.3-P1: No additional section
On 16.01.19 08:08, Evan Hunt wrote: On Wed, Jan 16, 2019 at 07:02:05AM +0100, Tom wrote: $ dig +norec -4 @ns3.example.com www.mydomain.net ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec -4 @ns3.example.com www.mydomain.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36984 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 847bc109e7f71243dd664e215c3ec4c412619cff362fd7fc (good) ;; QUESTION SECTION: ;www.mydomain.net. IN A ;; ANSWER SECTION: www.mydomain.net. 3600IN A 44.44.44.44 ;; AUTHORITY SECTION: mydomain.net. 3600IN NS ns3.example.com. mydomain.net. 3600IN NS ns2.example.com. mydomain.net. 3600IN NS ns1.example.com. Huh, looks like you're right. Both of these servers also authoritative for example.com, I'm guessing? Yes.., correct. Both are also authoritative for "example.com". It seems that if the additional data comes from a different zone on the same server (as opposed to the same zone, or from the cache), then it's not being looked up. I don't think this change was intentional. It was introduced during the work to improve performance in delegation-heavy zones: the old code would search through all of the zone databases every time it went to look up additional data. The newer code saves time by searching only the database that it's already found. That's more efficient and yields correct results in the "minimal-responses yes" case, but it's wrong for "no". It's possible there was a reason for the change that I've forgotten, but I think we intended to leave the "no" behavior alone. Thanks for bringing it up, I'll open a bug ticket about it. Perfect.., thank you. ___ 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
0-TTL when querying "invalid" soa
Hi list The following "invalid" soa-query responds with NXDOMAIN and with a ttl of 0 for the SOA-Record in the authoritative section: $ dig +norec +noquestion @ns1.yahoo.com. soa asfasdfdas.yahoo.com ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec +noquestion @ns1.yahoo.com. soa asfasdfdas.yahoo.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42800 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1272 ; COOKIE: 352e18e0eb38280a875e08255c506acd96bbdf698575699e (good) ;; AUTHORITY SECTION: yahoo.com. 0 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2019012908 3600 300 1814400 600 When directly querying the "valid" soa record, then the correct ttl for the soa-record is shown: ~$ dig +norec +noquestion @ns1.yahoo.com. soa yahoo.com ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec +noquestion @ns1.yahoo.com. soa yahoo.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12677 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1272 ; COOKIE: af18a9cdfa9d627675f37ac25c506ae626caee21d6718b5c (good) ;; ANSWER SECTION: yahoo.com. 1800 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2019012908 3600 300 1814400 600 When directly forcing an NXDOMAIN (query an A-record, which doesn't exist), then the correct ttl for negative-caching is shown: $ dig +norec +noquestion @ns1.yahoo.com. asdfasfdasf.yahoo.com ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec +noquestion @ns1.yahoo.com. asdfasfdasf.yahoo.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15170 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1272 ; COOKIE: 8050b624605c3cb9c99cb11e5c506b0d0bd93eb038992f6a (good) ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2019012908 3600 300 1814400 600 When querying the authoritative google-ns for "soa asdfasdfdas.google.com", then a ttl of 60s is shown: $ dig +norec +noquestion @ns1.google.com. soa asdfasdfasd.google.com ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec +noquestion @ns1.google.com. soa asdfasdfasd.google.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41492 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; AUTHORITY SECTION: google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 231384568 900 900 1800 60 We're running BIND-9.12.3-P1 on our authoritative servers and we have the same behavior with 0-ttl with a invalid soa-query. Is this bind-specific? Why does an invalid soa-record responds with 0-ttl in the authority-section? 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
Re: 0-TTL when querying "invalid" soa
Perfect.., many thanks for your hints. Tom On 29.01.19 16:33, Tony Finch wrote: Tom wrote: We're running BIND-9.12.3-P1 on our authoritative servers and we have the same behavior with 0-ttl with a invalid soa-query. Is this bind-specific? Why does an invalid soa-record responds with 0-ttl in the authority-section? Funnily enough, this little obscurity came up elsewhere just last week. I had the same question back in 2012: https://lists.isc.org/pipermail/bind-users/2012-June/087843.html https://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery The latter link explains the reason for this odd behaviour. [ Last week we also discussed an odd bit of text in RFC 1035: "For example, SOA records are always distributed with a zero TTL to prohibit caching." But RFC 2181 said you must no longer do that. ] https://twitter.com/fanf/status/1087708537600569344 Tony. ___ 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 debugging: TC and AD-Flag set?
Hi list I've enabled deep log-debugging in BIND 9.12.2-P1 (resolver) for DNSSEC purposes and was wondering, why my resolver received a "authenticated data" answer from one of the authoritative server for "org." (199.19.57.1), while the response has the TC (truncated) flag set too: 25-Feb-2019 08:26:05.172 resolver: debug 10: log_ns_ttl: fctx 0x7f89ac0021a0: rctx_answer: dnssec-failed.org (in 'org'?): 1 0 25-Feb-2019 08:26:05.172 dnssec: debug 3: validating dnssec-failed.org/DS: starting 25-Feb-2019 08:26:05.172 dnssec: debug 3: validating dnssec-failed.org/DS: attempting positive response validation 25-Feb-2019 08:26:05.172 dnssec: debug 9: validating dnssec-failed.org/DS: get_key: creating fetch for org DNSKEY 25-Feb-2019 08:26:05.172 resolver: debug 1: fetch: org/DNSKEY 25-Feb-2019 08:26:05.172 resolver: debug 10: log_ns_ttl: fctx 0x7f89a8c0: fctx_create: org (in 'org'?): 1 0 25-Feb-2019 08:26:05.172 resolver: debug 11: sending packet to 199.19.57.1#53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1478 ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ; COOKIE: c03358ce09f38ecc ;; QUESTION SECTION: ;org. IN DNSKEY 25-Feb-2019 08:26:05.265 resolver: debug 10: received packet from 199.19.57.1#53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1478 ;; flags: qr aa tc ad; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;org. IN DNSKEY ... ... Any hints for this behavior? Many thanks. 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
Error: zone example.com/IN (signed): receive_secure_serial: unchanged
Hi list We're sometimes receiving the same error as described in https://gitlab.isc.org/isc-projects/bind9/issues/256 after reloading BIND. zone example.com/IN (signed): receive_secure_serial: unchanged What does this error exactly means? What can I do to prevent this error? It seems, that DNSSEC is working fine, but the error is confusing. 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
Re: Error: zone example.com/IN (signed): receive_secure_serial: unchanged
Hi list Any hints on the error below after restarting bind (using BIND-9.12.3-P1)? zone example.com/IN (signed): receive_secure_serial: unchanged DNSSEC is working fine on the zone "example.com", but as I mentioned: The severity is "error" and it's not clear why. Many thanks for any hints/ideas. Kind regards, Tom On 11.03.19 09:14, Tom wrote: Hi list We're sometimes receiving the same error as described in https://gitlab.isc.org/isc-projects/bind9/issues/256 after reloading BIND. zone example.com/IN (signed): receive_secure_serial: unchanged What does this error exactly means? What can I do to prevent this error? It seems, that DNSSEC is working fine, but the error is confusing. 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
DNS-resolution failed for "www.gracenote.com" when "qname-minimization relaxed|strict;"
Hi list
Using BIND-9.14.1 as a resolver and qname-minimization set to "relaxed":
The following A-record resp. CNAME could not be resolved, when
qname-minimization is enabled (strict or relaxed):
www.gracenote.com
With qname-minimization enabled, BIND tries to get the NS record for
"glb.gracenote.com" (after BIND received the CNAME
"web.glb.gracenote.com") which results in:
$ dig @bind-9.14.1 +noall +answer ns glb.gracenote.com
glb.gracenote.com. 0 IN NS
sc-gtm-1a.globix-sc.gracenote.com.
Then BIND tries to get the ip address for the mentioned NS
(sc-gtm-1a.globix-sc.gracenote.com.) above, which results in NXDOMAIN:
$ dig @bind-9.14.1 +noall +answer +comment
sc-gtm-1a.globix-sc.gracenote.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17096
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9b42859a64d8ace1d701a0565cd94f43afdf5dc2a0368d96 (good)
From the client-perspective, the whole query results in SERVFAIL:
$ dig @bind-9.14.1 +noall +comment www.gracenote.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47277
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ffb32844e0c268e28df22c8a5cd9528e2dfff5e5f2f857cf (good)
Question:
Is there a simple way, where I can configure a zone-wide exception for
"qname-minimization" in a (pseudo)-way like this:
zone "gracenote.com." { qname-minimization off; };
What's the best way to "enable" resolution for the mentioned zone
without disabling qname-minimization?
Many thanks for any hints.
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
CDS-deletion record "CDS 0 0 0 00" is failing with bind-9.14.9 and bind-9.14.8
Hi list Using BIND 9.14.9 or BIND 9.14.8 and a zonefile with cds-deletion record: @ IN CDS 0 0 0 00 The zone does not load with the following error: 10-Jan-2020 21:35:47.075 general: error: zone example.com/IN (unsigned): CDS/CDNSKEY consistency checks failed 10-Jan-2020 21:35:47.076 zoneload: error: zone example.com/IN (unsigned): not loaded due to errors. The same zonefile with the same cds deletion-entry with bind-9.14.3 loads perfectly and could also be queried: $ dig +noall +answer @ns1.example.com cds example.com example.com.3600INCDS0 0 0 00 Any hints for this? 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
Re: Logging issue with bind
> Von: Raven
> > > I am currently trying to setup query logging with bind on a debian
> > > server, but I seem unable to.
> > > logging {
> > >channel munin_log {
> > > file "/var/log/bind9/query.log" versions 30 size 15m;
> > > severity dynamic;
> > "severity dynamic" starts at 0 i.e. off.
correct.
> >
> > Just remove the "severity" line.
No, let it be, it's nothing wrong with it.
> Still not working I'm afraid.
> What else could it be? Some debian-specific bug?
No, nothing Debian-specific :-)
You told Bind how to log queries in the config.
Now you have to tell Bind that he should start with the querylogging.
Do:
rndc querylog
Tom.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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: block ddns by name
> Von: Tony Finch
> > Does anyone know if there is a way to prevent the creation of certain
> > records - by name?
>
> update-policy {
> deny "*" name "internal.example.com";
> # ...
> };
Hi,
I have a quite similar question but can't figure it out from the doc for
update-policy:
I have a few DHCP-clients which are sending really stupid hostnames to the DHCP
and via DHCP they got into my DNS zones.
Example: A few IP-phones are sending as their hostname eight times xFF. And
this not printable name is then in DNS where I (and a few older nameserver)
don't want it.
So is there something possible like
update-policy { deny "*" name /^a-zA-Z0-9_\-/; };
?
(For thos who don't speak regex: deny all names with something in it what is no
letter or digit or underscore or dash.
Tom.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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
how to generate the name of a .nzf file?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, perhaps my idea is quite stupid. I think about following scenario: A primary nameserver is script-managed via rdnc addzone/delzone and nsupdate with data from a database. I know, rndc generates nzf files, which are named by hash values of the corresponding view names. Now there are eg. 50.000 zones configured in that way. At black friday the system crashes and has to be replaced by a new system. File-based backups of the old system are of course too old and a recovery by this way requires zone updates since last backup time, so its rated as deprecated. My idea: Transfer of the the actual generated zone files to the new system and then performing 50.000 rndc addzone commands to build the nzf files. The rndc commands will take a lot of time, so it's faster, to generate the nzf files at my own and transfer them to the new system, too. Starting named - done. The question is: how to generate the name of a nzf file? Is there a tool or an easy way? - -- Greetings, Thomas Müller Entwickler Dedicated Server - --- Telefon: + 49 (0)30 - 398 02 - 0 Telefax: + 49 (0)30 - 398 02 - 0 E-Mail:t.muel...@strato-rz.de Website: http://www.strato.de - --- STRATO AG Pascalstraße 10 10587 Berlin - --- Vorsitzender des Aufsichtsrates: Phil Zamani Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson, Christian Müller, Christoph Steffens, René Wienholtz Amtsgericht Berlin-Charlottenburg HRB 79450 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFPaJNkboB3gPvObwIRAocOAJ9iJ2h+LSQVAfdU1j8+xTsbJxxJSACdE+E7 HZhAzeyEdNwiPk5chtCWbyk= =04Pm -END PGP SIGNATURE- ___ 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: how to generate the name of a .nzf file?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jan-Piet,
>> The question is: how to generate the name of a nzf file?
>> Is there a tool or an easy way?
>
> Maybe something like this? (Untested)
>
> echo -n internal | shasum -a 256 | awk '{printf "%16.16s\n", $1}'
>
Great - it works. :-D
- --
Greetings,
Thomas Müller
Entwickler Dedicated Server
-
---
Telefon: + 49 (0)30 - 398 02 - 0
Telefax: + 49 (0)30 - 398 02 - 0
E-Mail:t.muel...@strato-rz.de
Website: http://www.strato.de
-
---
STRATO AG
Pascalstraße 10
10587 Berlin
-
---
Vorsitzender des Aufsichtsrates: Phil Zamani
Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson,
Christian Müller, Christoph Steffens, René Wienholtz
Amtsgericht Berlin-Charlottenburg HRB 79450
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFPaXE2boB3gPvObwIRAk5DAKCSCmM9aZuO3wXQ+SqnvPAe9nrFiQCeKrgn
yStrnFFz5815rWG00wmD62M=
=pENY
-END PGP SIGNATURE-
___
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: Moving DNS out of non-cooperative provider
On Mon, 18 Jun 2012, Alexander Gurvitz wrote: Can someone enlighten me on the following scenario (I guess it's explained somewhere, but can't find the info.): example.com was served by ns.OLDprovider.net example.com owner wants to move his domain to ns.NEWprovider.net oldprovider.net is not cooperating, and continues to serve example.com 172800 NS ns.OLDprovider.net (*.gtld-servers.net and ns.newprovider.com now serve example.com 172800 NS ns.NEWprovider.net) Recursive resolver ns.isp.com queried for www.example.com every few minutes, and currently have example.com 45892 NS ns.OLDprovider.net in it's cache. www.example.com have TTL of 3600. Thus each hour ns.isp.com queries ns.OLDprovider.net, with each query gets new NS record, and... refreshes the NS TTL ? Will ns.isp.com EVER query ns.NEWprovider.net ? I'd be happy to know how BIND behaves, but also how other servers may behave in this case. It is not a question of how bind behaves. It is a question of how does dns work. Bottom line is, setup nameservers with $NEWPROVIDER and change the nameserver records with your registrar and move on. All will be well when the ttl's time out. Until the ttl's timeout, resolvers with the old nameservers cached will still query them. Once the ttl's time out the new servers will be queried. Hope this helps, -- Tom Diehl tdi...@rogueind.com Spamtrap address mtd...@rogueind.com___ 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
Stalling slave transfers
Hi, I have a problem with one of 3 slave servers, all set up the exact same way, with the exact same bind version and configuration. One slave has a problem transfering zones from the master. The logfiles are flooded with "received notify for zone" .. "refresh in progress, refresh check queued" lines and "rndc status" returns a constant high number of "soa queries in progress". After a few hours the zones are transfers, so the connection to the master is working, but there is a major delay. I tried resetting the slave and transfering ALL slave zones again, which worked fine instantly. The problem still appeared again after a few hours though. The master has three network-paths, one on external IP, one on internal IP and one on IPv6. All 3 paths work fine, because the transfers happen after an hour or so. There is no hints in the master's log. The other two slaves are running perfectly, no errors or delays what so ever. Bind version 9.9.2-P2 (recently upgraded to). Any hints would be appreciated, as I feel like I've exhausted most options. Thank you. -- Tom Sommer ___ 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: Stalling slave transfers
On 5/8/13 12:25 PM, Cathy Almond wrote: On 08/05/13 08:26, Tom Sommer wrote: Hi, I have a problem with one of 3 slave servers, all set up the exact same way, with the exact same bind version and configuration. One slave has a problem transfering zones from the master. The logfiles are flooded with "received notify for zone" .. "refresh in progress, refresh check queued" lines and "rndc status" returns a constant high number of "soa queries in progress". After a few hours the zones are transfers, so the connection to the master is working, but there is a major delay. I tried resetting the slave and transfering ALL slave zones again, which worked fine instantly. The problem still appeared again after a few hours though. The master has three network-paths, one on external IP, one on internal IP and one on IPv6. All 3 paths work fine, because the transfers happen after an hour or so. There is no hints in the master's log. The other two slaves are running perfectly, no errors or delays what so ever. Bind version 9.9.2-P2 (recently upgraded to). Any hints would be appreciated, as I feel like I've exhausted most options. Thank you. Have a look at this KB article (you'll need to register to view - but registration is open to all): https://kb.isc.org/article/AA-00726/30/Tuning-your-BIND-configuration-effectively-for-zone-transfers-particularly-with-many-frequently-updated-zones.html Also - and this isn't covered in that article (yet) - if you're using views, then use-alt-transfer-source defaults to 'yes'. You might want to set it explicitly to 'no' or to define alt-transfer-source and/or alt-transfer-source-v6. Thank you, great resource. I think I solved it with raising serial-query-limit, it's just odd that it's not required on the other two servers. Another issue has arisen now though, the logfile is filled with lots of named[5596]: zone example.com/IN: refresh: failure trying master 1.2.3.4#53 (source 0.0.0.0#0): operation canceled But if I do a "dig example.com @1.2.3.4" it's working just fine. Same server as with the previous issue. Any thoughts? Thank you. // 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
Re: Stalling slave transfers
On 5/8/13 8:15 PM, Tom Sommer wrote: Another issue has arisen now though, the logfile is filled with lots of named[5596]: zone example.com/IN: refresh: failure trying master 1.2.3.4#53 (source 0.0.0.0#0): operation canceled and named[5596]: zone example.com/IN: refresh: retry limit for master 1.2.3.4#53 exceeded (source 0.0.0.0#0) // 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
Re: Stalling slave transfers
On 5/9/13 11:36 AM, Cathy Almond wrote: I don't think you solved the problem - I think you moved it (or made it happen faster...) The refresh errors indicate that the master isn't responding to your slave for some reason. That's what you'll need to investigate. I would suggest auditing the differences between this slave and the others in their named configurations as well as their configured IP interfaces and routing tables. A pair of network packet traces (slave and the non-responding auth server) might also point you in the right direction. Right, but when I perform a "dig" from the server OS, the transfer and network-communication work fine - so there are no signs as to why named can't connect to the master, but the OS can. I'll do some more digging. Thanks. ___ 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: Stalling slave transfers
On 5/9/13 2:19 PM, Luther, Dan wrote: > Tom, > > What happens when you "dig +tcp example.com @1.2.3.4"? Specifically I'm > wondering here if the slave you're having problems with is blocking TCP port > 53. Such a configuration would allow you to query the master server, but not > transfer to/from it. That works fine, but I think I figured out the problem, it was due to the server having acquired a 2nd (autodiscovered) IPv6 address, and it was using that as transfer source. It would be very helpful if the logfile said the actual source IP, and not just 0.0.0.0#53 or ::#0. That would help debugging a lot. I'm down to only seeing the error "retry limit for master" and "refresh: failure trying master" on IPv6 now, and only occasionally. It also appears the master is sending two notifies for each zone, to each slave, one on IPv4 and one on IPv6? // 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
DNS64 and DNSSEC - AD bit not set (RFC 6147)
Hi list, Just wanted to check my understanding of BIND9's implementation of DNS64 against RFC 6147. Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a security-aware & validating recursive resolver with will never synthesise a record via DNS64 when queried with DO=1 irregardless of the CD bit. When changing "break-dnssec" to "yes", querying with DO=1 will always trigger synthesis of a DNS64 record, irregardless of the CD bit. Both of these configurations seem to conflict with the DNS64 RFC 6147, which specifies that (so long as the upstream negative and positive A responses validate) the recursive resolver can still synthesise the DNS64 when queried with DO=1 and CD=0 but must return the answer with the AD bit set. Only when queried with both DO=1 and CD=1 must it not synthesise the DNS64 . Is there any way to configure BIND9 to comply with this RFC 6147 behaviour? We're on 9.8.2, but I couldn't find anything related in the CHANGES for either 9.8 or 9.9. Thanks, 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
Re: DNS64 and DNSSEC - AD bit not set (RFC 6147)
On 27 Mar 2014, at 14:48, Mark Andrews wrote: > No. If the answer is secure and DO=1 then it won't synthesis. > > RFC 6147 just gets DO and CD semantics completely wrong. The WG > wanted there to be signaling that the client was going to validate > and DNSSEC does not have such signaling. The best DNSSEC can do > is DO=1 indicates that the client might validate. This is independent > of CD. Isn't this signalling defined as the purpose of the CD bit in RFC 4035? My naive understanding is something like: DS=1 CD=0 "I am not going to validate this, I want you to check it" DS=1 CD=1 "I am going to validate this, so I don't care if you check it" > A validating stub resolver should send it queries with CD=0 so that > the recursive server can filter out bad responses from upstream. > Only if it gets SERVFAIL should it attempt the query with CD=1 in > case the resolver has bad time or bad trust anchors. Right, this is what our current stub resolvers are doing (well, I'm not sure about the retry with CD=1 on SERVFAIL, but they're sending DS=1 CD=0 queries to our recursive resolvers). > Named doesn't lie when DO=1 *and* it is possible to detect the lie. > "break-dnssec yes;" tells named to lie even when it is possible to > detect the lie. So, what is a "lie" here? Assuming that the response received upstream (i.e. a negative and positive A response) has been validated, is inserting a synthesised for DNS64 "lying"? > Stub resolvers don't currently set DO=1 so DNS64 synthesis happens > for them. Our real-world case, and why I'm looking into this, is that our BIND 9.8.2 validating recursive resolvers are *not* returning synthesised DNS64 responses for DNSSEC signed zones because the downstream stub resolvers query with DS=1 and CD=0. This breaks connectivity from our IPv6-only clients for DNSSEC signed zones. As far as I can see, my two options are to enable break-dnssec in BIND, or disable DNSSEC validation in the stub resolvers. Are there any other options, and if not, are either of these two more preferred than the other? 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
BIND 9's entropy consumption
Hi! I have 4 DNS servers all running BIND 9.8.2 (the CentOS 6.5 package). One is configured as the master for about 100 zones. The other 3 are slaves for those 100 zones. On the master the amount of entropy reported by "cat /proc/sys/kernel/random/entropy_avail" was around 150. On the slaves it hovered around 90. Is there a technical reason for the difference? There is a graph of one of the slaves here: http://serverfault.com/questions/582908/entropy-deprivation-on-bind-named-servers Note: I've since enabled "rngd" and the available entropy hovers around 2k. So there problem is "solved" that way, but it still makes me very concerned that the amount of entropy in use was so different. There is no DNSSEC configured, no incremenal zone transfers (just notifications sent from the master to all slaves). Anyone have any theories on why this might be? Thanks in advance, Tom The specific version is: # named -V BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013 using libxml2 version: 2.7.6 -- Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com Skype: YesThatTom Blog: http://EverythingSysadmin.com ___ 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
Can I run two name servers on one host with two IP addresses?
I have a single server with access to several IP addresses from my dedicated host provider. They do not provide DNS service so I currently use my domain registrar. I would like to run my own DNS server but I only have the one server (with 5 IP addresses). Is it possible (and permitted) to run DNS with just one real server? Thanks. Best 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
Re: Can I run two name servers on one host with two IP addresses?
On Wed, Aug 19, 2015 at 5:59 PM, Reindl Harald wrote: > Am 20.08.2015 um 00:53 schrieb Tom Browder: >> I have a single server with access to several IP addresses from my ... >> I would like to run my own DNS server but I only have the one server ... > they have to be on different IP networks and the reason si simply to avoid a > single-point of failure > so even if you have different IP ranges on your single machine don't do it - ... That makes sense--thanks, Reindl! Best, -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
Allowable reverse mapping zone file names
I do not control 3-octet networks but need reverse mapping for my mail server. Two questions: 1. Where is the doc that completely describes the allowable reverse mapping zone file names? 2. When running my own authoritative name servers, do I need reverse mapping for anything other than my single mail server? Thanks. Best 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
rndc on local host: need named running?
My plan is to have two remote, authoritative name servers (master and slave) for my owned domains. I would like to use rndc to control them from my local host. A couple of questions: 1. Does named need to be running on the local host? 2. Can I use rndc from my local host which doesn't have a fixed ip address? Thanks. Best 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
Re: Allowable reverse mapping zone file names
On Saturday, August 27, 2016, /dev/rob0 wrote: > On Sat, Aug 27, 2016 at 10:47:36AM -0500, Tom Browder wrote: > > I do not control 3-octet networks but need reverse mapping for my > > mail server. > > Discuss that with your ISP or netblock owner. ... Thanks for the good advice, "/dev/robo." Best 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
Re: rndc on local host: need named running?
On Saturday, August 27, 2016, Warren Kumari wrote: > On Saturday, August 27, 2016, Tom Browder > wrote: > >> My plan is to have two remote, authoritative name servers (master and >> slave) for my owned domains. I would like to use rndc to control them from >> my local host. >> A couple of questions: >> > ... Thanks, Warren! Best 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
Re: Allowable reverse mapping zone file names
On Saturday, August 27, 2016, Lyle wrote: ... > As far as question 2, depends on if the reverse zones were delegated to > you or not. It depends on your ISP. Many do not delegate reverse lookup > zones to the end user. In that case, you have to ask them to insert the > records you think necessary including your mail server's host name. > Thanks, Lyle! Best 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
Re: rndc on local host: need named running?
On Saturday, August 27, 2016, Lyle wrote: > On 08/27/16 10:54, Tom Browder wrote: > > https://calomel.org/dynamic_dns_ddns.htmlMy plan is to have two > > 2. Can I use rndc from my local host which doesn't have a fixed ip address? > > ... > Let me Google that for you and the answer is: > https://www.safaribooksonline.com/library/view/dns-bind/ > 0596004109/ch03s04.html > Thanks, Lyle. I've seen that, I have the book. But it's not real clear to a novice that it works without the remote host knowing the incoming ip address. But I have enough info now to risk putting my name servers on line without fear of destroying the dns system of the internet! Best 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
Re: rndc on local host: need named running?
On Tuesday, August 30, 2016, Cathy Almond wrote: > On 28/08/2016 02:48, Lyle wrote: > > Use any in the allow stanza. > > You'll be using a shared key for this to work anyway, but I'd suggest > being slightly more paranoid than 'any' in the allow stanza - perhaps > the address range in which your local machine is to be allocated its > address? > Thanks, Cathy. Best 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
Re: rndc on local host: need named running?
On Tuesday, August 30, 2016, Woodworth, John R < john.woodwo...@centurylink.com> wrote: > > I have a slightly unorthodox view on this which may even offer a bit more > > security. The answers are listed below inline. > > ... Thanks, John. Best 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
Request reverse dns mapping advice
I have two remote servers, one with one IPv4 address, and one with five IPv4 addresses. My ISP will provide reverse mapping for all if I provide the desired rDNS record for each address. The rDNS record for the one-address server is not a problem, but I would appreciate opinions on the choice of names for the records for the multiple-address server. The server is currently is or will be performing the following roles: 1. Apache web server for 10+ virtual hosts (name based, each with its own domain name). 2. Planned: A mail server to be used for all my current (and future) domains. 3. Planned: A slave (secondary), authoritative DNS server for my domains (the single-adddress server will be the master). My idea is to use this list of names for the rDNS record for each of the five addresses: 1. pick a primary domain from the list of virtual hosts (example2.com) 2. use the "real" host name of the server (juvat.example1.com) 3. the mail server name (mail.example1.com) 4. the dns server name (ns2.example1.com) 5. another domain from the virtual hosts list (example 3.com) Note that I alse have IPv6 addresses with which I will create similar rDNS records matching the names I use for the IPv4 records. Thanks for your always helpful advice. Best 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
Re: Request reverse dns mapping advice
On Monday, September 5, 2016, John Levine wrote: > >1. pick a primary domain from the list of virtual hosts (example2.com) > >2. use the "real" host name of the server (juvat.example1.com) > >3. the mail server name (mail.example1.com) > >4. the dns server name (ns2.example1.com) > >5. another domain from the virtual hosts list (example 3.com) > > Publish a PTR with the mail server name, forget about the rest of > them. ... Thank you, John, for the good advice. I thought I had read that somewhere but haven't been able to find it again. On today's Internet, you want your mail server to EHLO with a name > that has matching forward and reverse DNS with the server's IP. If > you don't, you look unnecessarily like a spambot. ... A very good reason, indeed! Thanks again. Best 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
Re: failed to start BIND 9.16.34 on Ubuntu 20.04
On 11/11/2022 01.47, Ling Yun wrote: # systemctl status bind9 ● named.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Thu 2022-11-10 21:51:18 CST; 48s ago Docs: man:named(8) Process: 96944 ExecStart=/usr/sbin/named -f $OPTIONS (code=killed, signal=ABRT) Main PID: 96944 (code=killed, signal=ABRT) Nov 10 21:51:18 h2o systemd[1]: named.service: Scheduled restart job, restart counter is at 6. Nov 10 21:51:18 h2o systemd[1]: Stopped BIND Domain Name Server. Nov 10 21:51:18 h2o systemd[1]: named.service: Start request repeated too quickly. Nov 10 21:51:18 h2o systemd[1]: named.service: Failed with result 'signal'. Nov 10 21:51:18 h2o systemd[1]: Failed to start BIND Domain Name Server. These log messages are irrelevant - it's just the systemd's restart facility rate-limit. Please attach the log which contains the real cause of failure, e.g. by using: # journalctl -u bind9 -- Tom Krizek OpenPGP_0x01623B9B652A20A7.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RT-Number?
I just read the release notes from Bind 9.7.2-P3 and noticed that behind every short description of a change there is a number beginning with RT. I hope this is some kind of ticket number were more detailed information about this change could be found? My question: Were do I find these tickets? (wouldn't make much sense to publish their numbers if the tickets themself couldn't be read, but I couldn't find them on the ISC homepage) -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zones not getting transferred after a restart
Consider the option "transfers-in". Look at the output of: rndc status If you notice that the "soa queries in progress" number is high in proportion to the number of slave zones maintained by the server, you should increase the transfers-in number (the default is 10 as I recall). That means that your server is limiting itself to only 10 simultaneous zone retrievals from the masters of the zones. I didn't get the response I liked in my particular case until I tweaked the number to about 70% of the "soa queries in progress" number. As with tweaking any parameter on a heavily used system, you might want to look at the typical system vital statistics after tweaking the value and looking at how any of those things (cpu, mem, disk i/o, network i/o, general load, etc) may now be trending differently after a day/week. Richard On 3/15/2011 6:29 PM, Mark Andrews wrote: In message, Bernhard Schmidt writes: Hi, we have an internal distribution point running BIND 9.5.0-P2 (SLES 11.1 distribution package). It slaves about 1800 zones from a commercial DNS management software running on 127.0.0.1:8054 and distributes them towards our servers. Whenever we restart BIND on that system, the 1800 zones are loaded within two seconds (1800 loaded serial x entries, running), but it takes up to 30 minutes (26 minutes the last time) where it does not do any AXFR upstream and logs 15-Mar-2011 09:36:47.334 zone kongress.xxx.de/IN: notify from 127.0.0.1#8054: refresh in progress, refresh check queued on every notify it receives. I cannot really see SOA queries upstream either. When that time has passed by it catches up with the zone transfers. Other than having "edns no" and "request-ixfr no" set for the upstream server (due to bugs in this field) the configuration is pretty standard. I'm not really opposed to updating the BIND to a newer version, but given I'd have to go away from the distribution package where I feel fine using it (firewalled system, only reachable by our other servers) I'd rather know for sure that this problem is solved. I see similar issues on our frontend servers running 9.7.3. Can anyone explain how I can speedup this progress? Disable notify for the zones. Increase soa-query-rate. It also applies to notifies. Also I'd like to disable/tune down the 15-Mar-2011 08:25:36.828 zone xxx.in-addr.arpa/IN: refresh: skipping zone transfer as master 127.0.0.1#8054 (source 0.0.0 .0#0) is unreachable (cached) thing. Good idea, but stopping all zone transfers for 10 minutes from the only master just because it was unreachable for a few seconds is a bad idea. Adjust lame-ttl. I have searched for a named.conf knob and have failed to find any. Closest I have found is serial-query-rate, which is not set in our environment and should default to 20. The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
what does dig +trace do?
Hi, I have a question: What does dig +trace exactly do? The reason for my question is: I have a internal-only DNS in our company with my own root-zone. And normaly all things are fine. But when there is an issue I would like to analyze with dig +trace, the command fails. If I do dig +trace example.com I get something like this: ; <<>> DiG 9.8.0-P4 <<>> +trace example.com ;; global options: +cmd . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; connection timed out; no servers could be reached I don't understand why there is a timeout. Next zone on the trace should be the com. domain which is hosted on the same servers as the rootzone. I don't see any DNS-problems at all, only the +trace-option is behaving weird. Can anybode tell me why? What does this option what normal DNS queries don't do? Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ 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: RE: what does dig +trace do?
> > What strikes me as odd is that the first query does return 4 (internal) > root servers, but no glue records ? I have no idea why this is this way. > Given those root name servers, do you have A-records for root[1234] in > your root zone ? Yes, of course. From my root-zone: . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. root1. 10800 IN A 10.111.111.111 root2. 10800 IN A 10.111.112.112 root3. 10800 IN A 10.111.113.113 root4. 10800 IN A 10.111.114.114 com. 10800 IN NS root3. com. 10800 IN NS root4. All these records I can query with dig without any problem, but dig +trace still fails. :-( -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ 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: RE: RE: what does dig +trace do?
Original-Nachricht > I believe what is missing the root cache file. > > The root server would have glue records point to GTLDs, like this > > Then the GTLDs would have glue records pointing to nameserver of the > domain you are trying to trace. > > What you are seeing is your local nameservers, it seems to me they don't > have access to the Internet or a firewall is blocking some of the > response or you don't have the root cache file to do hints or > combination of all the above. Hi Gary, yes, all of the above. But this is no mistake, it's the intended architecture. My DNS-server is an internal one without any conection to the internet. There is no root hint file because I have a internal root zone on my own. And my root servers have the glue records in this root zone and the NS records for the TLDs as well. So dig +trace should work. Or has the trace-option the IP-addresses of the Internet-root-servers hardwired in the the sourcecode? -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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: RE: what does dig +trace do?
> >> What strikes me as odd is that the first query does return 4 (internal) > >> root servers, but no glue records ? > > > >I have no idea why this is this way. > > Because +trace only displays the answer section of the responses by > default. > Try "dig +trace +additional". Hi Chris, you are right, thank you. With this I see the glue records: ; <<>> DiG 9.8.0-P4 <<>> +trace example.com ;; global options: +cmd . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. root1. 10800 IN A 10.111.111.111 root2. 10800 IN A 10.111.112.112 root3. 10800 IN A 10.111.113.113 root4. 10800 IN A 10.111.114.114 ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; connection timed out; no servers could be reached The main problem is still the same though. The trace option fails with a timeout. Even thought I'm operating on the shell of one of the root-servers itself (so there is not much network in between to cause trouble). -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ 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
