Re: Deleting a key
The DS for the new key is only rumored. I believe you want a `rndc dnssec -checkds -key 48266 published` and maybe another to withdraw the 50277 key. Peter -- 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
named hangs when trying to sign a large zone after upgrading to 9.18.28
I upgraded our DNS servers when the 9.18.28 release came out, and ran into a
problem today that I wanted to know if anyone else had seen or had any
suggestions about how to debug.
We have our DNS configured in a hidden primary configuration, where the primary
has internal and external views and serves and internal and external copy of
one of our domains. The external version is fairly small, while the internal
version is significantly larger. We use the same DNSSEC keys to sign both
versions of the domain. Every once in a while, we have encountered an issue
where the unsigned and signed versions of the domain get out of sync, which
causes this message to appear in our logs (note that I have modified all of the
following log entries to replace our domain with example.org):
25-Jul-2024 10:12:32.202 general: error: zone example.org/IN/internal (signed):
receive_secure_serial: not exact
The solution I’ve always been able to follow previously is to comment out the
DNSSEC config options in named.conf, restart named with the zone unsigned,
retransfer the unsigned zone to our secondaries, and then put back the DNSSEC
config options, restart named, and let it re-sign the zone. It takes a little
bit, but normally everything has then gotten back to normal.
Today, however, when I tried to do that, it started to sign the zone – and then
named just hung. It stopped updating any of the log files, stopped sending any
notifies, and stopped returning DNS data of any sort. When I tried to restart
named via systemctl it had to kill the process because named would not respond.
I was able to undo the DNSSEC changes, restart named, and it continued to
work. I tried it again, and named hung once again in the middle of signing the
zone. Throughout all of these restarts, the signed version of the external
zone continued to work normally.
This is frustrating because when named hangs, there are no error messages in
the logs that I can see, and no indication of why it has failed. If I try
running rndc commands locally I get this error:
rndc: recv failed: timed out
Remote servers show a timeout and then I saw this in some of their transfer
logs:
25-Jul-2024 10:27:01.827 general: info: zone example.org/IN: refresh: skipping
zone transfer as primary A.B.C.D#53 (source E.F.G.H#0) is unreachable (cached)
I was able to solve that one by sending notifies from the primary after
restarting it without DNSSEC, but I really need to get DNSSEC working again.
The configuration for the zone in named.conf is (and yes, I know I need to
update to dnssec-policy):
view "internal" {
...
zone "example.org" {
type primary;
file "/path/to/internal/example.org";
key-directory "/path/to/keys";
auto-dnssec maintain;
inline-signing yes;
};
...
};
Does anyone have any suggestions for putting named into a debug mode to try to
get more data if it hangs again? I was thinking of turning the DNSSEC options
back on but setting “notify no” so it didn’t try to notify the secondaries in
case all of the notifies and zone transfers going on while it was signing was
part of the problem.
The memory and CPU resources of the system should be sufficient – it’s got 2
virtual CPUs and 8GB of memory, but it’s not close to using up the memory, and
since it doesn’t have clients, the CPU has never been an issue before. I tried
replicating this issue on our test server but it managed to sign the zone with
no problems – though it doesn’t have as many clients.
I don’t think the new max-records-per-type or max-types-per-name options are
involved as we don’t have any cases where we have that many records with the
same name.
Thanks,
Brian
--
Brian Sebby (he/him/his) | Lead Systems Engineer
Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology
Infrastructure
Phone: +1 630.252.9935| Business Information Services
Cell: +1 630.921.4305| Argonne National Laboratory
--
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: 9.16.27 - Cache Prefetch
Hi Gabe. Prefetch still exists; reference here: https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-prefetch Hope that helps. Greg On Tue, 23 Jul 2024 at 17:36, Gabe Loyer wrote: > In searching for documentation I can only find something for prefetch in > 9.10, which apparently caused some issues. Is there any new alternative in > later versions? > > Thanks, > Gabe > -- > 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 > -- 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: New BIND releases are available: 9.18.28, 9.20.0
We use the COPR to install BIND on our servers, and I wanted to mention that it looks like in both the isc/bind and isc/bind-esv repos, the build of the package “isc-bind-bind” failed for version 9.18.28-1.1 in (as far as I can tell) only the EPEL 7 repo in Build 7776636. Could someone look at that? We’re on RHEL 8 and 9 for our BIND servers and it looks like the EPEL 8 and 9 versions build successfully, but I want to make sure that I’m not missing something. Thanks! Brian -- Brian Sebby (he/him/his) | Lead Systems Engineer Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology Infrastructure Phone: +1 630.252.9935| Business Information Services Cell: +1 630.921.4305| Argonne National Laboratory From: bind-users on behalf of Victoria Risk Date: Tuesday, July 23, 2024 at 8:32 AM To: bind-annou...@lists.isc.org , BIND Users Subject: New BIND releases are available: 9.18.28, 9.20.0 BIND users- Our July 2024 maintenance release of BIND 9. 18, as well as the new 9. 20. 0 stable branch, are available and can be downloaded from the ISC software download page, https: //www. isc. org/download. In addition to bug fixes and feature ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd BIND users- Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 stable branch, are available and can be downloaded from the ISC software download page, https://www.isc.org/download<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.isc.org_download=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=bzNtaRi91LT7NGxvLacOsRR1G9KN3r-0KTyCGEZg7W4=>. In addition to bug fixes and feature improvements, these releases also contain fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, CVE-2024-1975, CVE-2024-4076), about which more information is provided in the following Security Advisories: https://kb.isc.org/docs/cve-2024-0760<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.isc.org_docs_cve-2D2024-2D0760=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=hf52gj9SjjbMh_N66diWqdZFByhr_hEy_DLLM6useU4=> https://kb.isc.org/docs/cve-2024-1737<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.isc.org_docs_cve-2D2024-2D1737=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=QZWuJmSD9PaIQPEorLqEbgQF-tj3T27lRz28IBul8Gc=> https://kb.isc.org/docs/cve-2024-1975<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.isc.org_docs_cve-2D2024-2D1975=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=3rxkgsPWVjucjy0uQLiFWNSKqV579E-ri6R2zGqDFw8=> https://kb.isc.org/docs/cve-2024-4076<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.isc.org_docs_cve-2D2024-2D4076=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=z2wPjQ7Pj0Dh9Bc02avjPawaCkKA3fdgEZ2ztpWVH3Y=> A summary of significant changes in the new releases can be found in their release notes: - Current supported stable branches: 9.18.28 - https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.isc.org_isc_bind9_9.18.28_doc_arm_html_notes.html=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=eL3vtH4F4vRw0n1gERxG-YbNvYiZUwcADdS64amUM94=> 9.20.0 - https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.isc.org_isc_bind9_9.20.0_doc_arm_html_notes.html=DwQFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=jByNiOTuwi2CKgchg6VaHFIewzRSMvAtPq-UNd3NZ04=> We also have a nice blog post from Ondřej Surý on the 9.20.0 release, including performance testing results (https://www.isc.org/blogs/2024-bind920/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.isc.org_blogs_2024-2Dbind920_=DwMFaQ=VNwPUykuud53CG9rFjagOIJ6-Rup94jYcsvLgLkfjkk=jaYfnGHWNQHXZDHWVerNDw=enZ9AiHfKVqcG4gKXlgwWb68BKijXJQ5qOejq2wTquhkSEG-taOVu6pEsM7QCg7z=UUKshb2znNU4e4TPM0Yd2ufCIHmbyXxSKZu0ptJ8B3c=>). --- Please Note: To create an effective mitigation for CVE-2024-1737 we have introduced two new configurable limits that prevent the loading (into zones or into cache) of DNS resource records (RRs) that exceed them. We therefore recommend reading this KB article
Re: strange reply dumped URGENT
Hi,
Sorry I had to fix for my customer the domain ore.org.bo, but I have
open another domain to test: testadmin.ovh
Sorry for all this change. I have defined better test case and have
normal IP to prevent problem from this part.
69.162.65.138-> not my IP 2803:1920::4:a09 IPv6 only, VPS customer (here I'm the
customer) <-> EDGE 199.38.247.210 IPv4+IPv6 <-> upstream provider of my
autonomous system Each time I try enable log, named not start, see
attached file Debian 12 into /etc/bind/named.conf.local I replace
(/var/log/bind.log exist with bind user): logging { category
default { null; }; }; logging { channel bind_log {
file "/var/log/bind.log" versions 3 size 10m;
severity info; print-category yes;
print-severity yes; print-time yes;
}; category default { bind_log; }; category
lame-servers { null; }; category update { bind_log; };
category update-security { bind_log; }; category security {
bind_log; }; };
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/15/24 02:43, Mark Andrews wrote:
Really it is very hard to help people who keep changing random things making a
moving
target. You started out with a machine at 45.225.75.8 that could reach
2803:1920::c:1963
based on the forward zone declaration so it had to be dual stacked (both IPv4
and IPv6).
You have now added two new machines 69.162.65.138 and 192.169.93.210 which may
or may not
be able to reach 2803:1920::c:1963 and have changed the delegation to point to
them and they
return NXDOMAIN for smtp.ore.org.bo.
Now if you have IPv4 only nameservers that need to get the zone content from an
IPv6 only
server you will need to have an intermediate dual stacked server that can
transfer the zone
content from the IPv6 only server and send it to the IPv4 only servers when
they request it.
P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)
Also read the nameserver’s logs. They will help you work out what is going
wrong.
2803:1920::c:1963 (IPv6 only):
zone ore.org.bo {
type primary;
file "ore.org.bo.db”;
};
45.225.75.8/ (dual stacked):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
69.162.65.138 (IPv4 only):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 45.225.75.8; };
};
Alternatively you can add IPv6 to an IPv4 only machine using services like
https://tunnelbroker.net/ even when the ISP does not support IPv6.
Mark
On 15 Jul 2024, at 11:00, Herman Brule wrote:
I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have
bind9):
dig A ore.org.bo @199.38.247.210
With on 199.38.247.210 (work):
zone ore.org.bo {
type master;
file "/etc/bind/ore.org.bo.db";
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
;; QUESTION SECTION:
;ore.org.bo.IN A
;; ANSWER SECTION:
ore.org.bo. 3600IN A 45.225.75.8
;; Query time: 99 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:53:38 UTC 2024
;; MSG SIZE rcvd: 83
With on 199.38.247.210 (not work):
zone ore.org.bo {
type secondary;
file “/etc/bind/ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
;; QUESTION SECTION:
;ore.org.bo.IN A
;; Query time: 87 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:56:01 UTC 2024
;; MSG SIZE rcvd: 67
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/14/24 20:00, Mark Andrews wrote:
On 13 Jul 2024, at 12:44, Herman Brule wrote:
Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure
Re: Building bind 9.19.24 on Openwrt w/ MUSL
Finally got it done. Sorry for taking so long. Had a lot of travel. > On Jun 2, 2024, at 2:37 AM, Ondřej Surý wrote: > > Hi Philip, > > we'll need more. Ideally fill an issue, follow the bug template and attach > config.log as a bare minimum. > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 1. 6. 2024, at 23:19, Philip Prindeville via bind-users >> wrote: >> >> Hi, >> >> Having some more issues building 9.19.24 on MUSL. configure.ac isn't >> correctly detecting the following: >> >> ac_cv_func_setresuid=yes >> ac_cv_type_size_t=yes >> ac_cv_type_ssize_t=yes >> ac_cv_type_uintptr_t=yes >> >> And even passing this manually via ./configure's environment isn't causing >> it to work... it's showing as the wrong value and not "(cached)". >> >> I wouldn't have noticed except that the included replacement for setresuid() >> dies in compilation with a warning about it being declared as static and >> then later defined as non-static or some such. >> >> Anyone else had problems with autoconf and cross-compilation w/ MUSL? >> >> I wanted to do a bump on bind to pick up this fix: >> >> https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 >> >> Thanks, >> >> -Philip >> >> -- >> 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 > -- 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: strange reply dumped URGENT
I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP
have bind9):
dig A ore.org.bo @199.38.247.210
With on 199.38.247.210 (work):
zone ore.org.bo {
type master;
file "/etc/bind/ore.org.bo.db";
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
;; QUESTION SECTION:
;ore.org.bo. IN A
;; ANSWER SECTION:
ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 99 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:53:38 UTC 2024
;; MSG SIZE rcvd: 83
With on 199.38.247.210 (not work):
zone ore.org.bo {
type secondary;
file “/etc/bind/ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
;; QUESTION SECTION:
;ore.org.bo. IN A
;; Query time: 87 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:56:01 UTC 2024
;; MSG SIZE rcvd: 67
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/14/24 20:00, Mark Andrews wrote:
On 13 Jul 2024, at 12:44, Herman Brule wrote:
Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
correctly to all my dig query)
2) I have to provide a way to my customer can resolve query on their DNS server
on their IPv6 VPS, their need be able to just put their vps dns or at least
common server dns (where I had to put their zone, then I dislike this idea)
For now your method fail, include I try:
zone "ore.org.bo" {
type master;
file "/etc/bind/ore.org.bo.db";
};
But failed too.
Well I didn’t say to do that. You have they wrong type of zone. Make it a
secondary (slave) zone
like I told you to do.
zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
Now that should work as I can AXFR the zone from that server. You should also
note the difference in
the flags in the responses for smtp.ore.org.bo. The one from 2803:1920::c:1963
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.
It also looks like someone tried to comment out *.ore.org.bo but used the wrong
comment character ‘#'
rather than ‘;’.
[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN 2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN 2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47
Re: strange reply dumped URGENT
Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but
reply correctly to all my dig query)
2) I have to provide a way to my customer can resolve query on their DNS
server on their IPv6 VPS, their need be able to just put their vps dns
or at least common server dns (where I had to put their zone, then I
dislike this idea)
For now your method fail, include I try:
zone "ore.org.bo" {
type master;
file "/etc/bind/ore.org.bo.db";
};
But failed too.
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/12/24 19:01, Mark Andrews wrote:
On 13 Jul 2024, at 04:38, Herman Brule via bind-users
wrote:
Because the customer are into IPv6 zone
Well all zones should be served by both IPv4 servers and IPv6 servers. IPv6 is
nearly 30 years old now. There are
sites that are IPv6 only because they would prefer to not have to run
everything through 2 or 3 layers of NAT when
they don’t need it at all for IPv6 and would really like to not have to send
all there DNS queries though NAT64 boxes.
And the EDGE router connecting IPv4 and IPv6 is internal to the data center
company, not accessible for the customer.
Forward zone to edge will be more complex, it's more simple just forward the
query.
Thanks for you observation, but I know, I doing this quickly, I will keep like
this for now, this will produce only problem for availability if the server is
down.
Except you are wrong. You are writing here because it *is* causing you and
everyone else a problem. The correct way to
fix this is to transfer the zone contents to the listed primary servers if you
are using nameservers. Alternatively
don’t run nameservers at all but use IP level proxies. Either the whole address
or port forward 53/TCP and 53/UDP.
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/12/24 14:28, Marco Moock wrote:
Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users:
bind to my proxy from IPv4 to IPv6 zone
Why don't you simply run multiple authoritative servers, some only
accessible by IPv6, some dual-stack?
They are independent of each other and only the zone transfer need to
work.
I also see some strange things:
m@ryz:~$ host 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$ host 811b.vps.confiared.com.
811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com.
811.vps.CONFIARED.com has address 45.225.75.8
811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963
m@ryz:~$
You should have redundant servers and not 2 NS records that point to
the same machine.
Please fix that first and update your glue records.
--
Visithttps://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 athttps://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users$TTL 60
@ IN SOA 811.vps.confiared.com 811b.vps.confiared.com. confiared.com.
(2020102000 86400 3600 360 300)
3600 IN NS 811.vps.confiared.com.
3600 IN MX 1 smtp.testadmin.ovh.
3600 IN A 45.225.75.8
3600 IN 2803:1920::c:1963
aIN A 45.225.75.8
IN 2803:1920::c:1963
smtpIN CNAME ore.org.bo.
wwwIN CNAME ore.org.bo.
* IN CNAME ore.org.bo.
--
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: strange reply dumped URGENT
I see https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage Loop detected! We were referred back to '45.225.75.8' dns check <https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage#> mx lookup <https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage#> dmarc lookup <https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage#> spf lookup <https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage#> dns propagation <https://mxtoolbox.com/SuperTool.aspx?action=a%3aore.org.bo=toolpage#> Reported by *mxtoolbox.com* on 7/12/2024 at *2:40:49 PM*, just for you <https://mxtoolbox.com/whatismyip/?justforyou=1>. bind run on 45.225.75.8 with is the edge The hostname is speedykvm All query related to ore.org.bo have to be forwarded to 2803:1920::c:1963 (811.vps.confiared.com) final customer VPS Note dig report me: ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ; EDE: 0 (Other): ([45.225.75.8] Lame delegation at ore.org.bo for ore.org.bo/a) ; EDE: 22 (No Reachable Authority): (At delegation ore.org.bo for ore.org.bo/a) ;; QUESTION SECTION: ;ore.org.bo. alpha_one_x86/BRULE Herman Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management IT, OS, technologies, research & development, security and business department On 7/12/24 15:00, Marco Moock wrote: Am 12.07.2024 um 14:56:28 Uhr schrieb Herman Brule via bind-users: The edge router receive the query, should just forward to the IP into the named.conf.rproxy (then IPv6 master) So bind runs on this router? What is the hostname of this router? To which IP addresses does it point? -- 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: strange reply dumped URGENT
The edge router receive the query, should just forward to the IP into the named.conf.rproxy (then IPv6 master) alpha_one_x86/BRULE Herman Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management IT, OS, technologies, research & development, security and business department On 7/12/24 14:46, Marco Moock wrote: Am 12.07.2024 um 14:38:58 Uhr schrieb Herman Brule: Because the customer are into IPv6 zone So the master DNS is IPv6 only? No problem for the zone transfer. And the EDGE router connecting IPv4 and IPv6 is internal to the data center company, not accessible for the customer. In which way is this router involved in DNS resolution? -- 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: strange reply dumped URGENT
Because the customer are into IPv6 zone And the EDGE router connecting IPv4 and IPv6 is internal to the data center company, not accessible for the customer. Forward zone to edge will be more complex, it's more simple just forward the query. Thanks for you observation, but I know, I doing this quickly, I will keep like this for now, this will produce only problem for availability if the server is down. alpha_one_x86/BRULE Herman Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management IT, OS, technologies, research & development, security and business department On 7/12/24 14:28, Marco Moock wrote: Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users: bind to my proxy from IPv4 to IPv6 zone Why don't you simply run multiple authoritative servers, some only accessible by IPv6, some dual-stack? They are independent of each other and only the zone transfer need to work. I also see some strange things: m@ryz:~$ host 811.vps.confiared.com. 811.vps.CONFIARED.com has address 45.225.75.8 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963 m@ryz:~$ host 811b.vps.confiared.com. 811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com. 811.vps.CONFIARED.com has address 45.225.75.8 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963 m@ryz:~$ You should have redundant servers and not 2 NS records that point to the same machine. Please fix that first and update your glue records. -- 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
strange reply dumped URGENT
Hi,
I have dns problem, mostly show by dig A smtp.ore.org.bo @8.8.8.8
Then I have dump the connection by dumpcap, the raw reply by bind is wrong.
As attached file:
- dump of ethernet interface
I have into /etc/bind/named.conf.rproxy:
zone "ore.org.bo" {
type forward;
forward only;
forwarders { 2803:1920::c:1963; };
};
/etc/bind/named.conf have:
include "/etc/bind/named.conf.rproxy";
bind to my proxy from IPv4 to IPv6 zone
dig A smtp.ore.org.bo @45.225.75.8
show me correct reply
dig A smtp.ore.org.bo @2803:1920::c:1963
show me correct reply
--
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
dns.pcapng
Description: application/pcapng
--
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: netstat showing multiple lines for each listening socket
On 10.07.24 14:20, Tom Marcoen (EXT) wrote: My server has four (virtual; it runs on vSphere) CPUs and also shows four lines in `ss` output. The `ps` command shows the `-U` which - I assume - is set automatically triggered by the number of CPUs. # ps -elf | grep named 5 S named23769 1 9 80 0 - 251941 do_sig 07:12 ? 00:39:02 /usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf The manpage says: -U #listeners This option tells named the number of #listeners worker threads to listen on, for incoming UDP packets on each address. If not specified, named calculates a default value based on the number of detected CPUs: 1 for 1 CPU, and the number of detected CPUs minus one for machines with more than 1 CPU. So if not specified, the value of "-U" should be set to 3 with four CPUs. Also, the parameter "-U" usually does not show up in the ps output if not specified. So in your case it looks more like named is specifically started with "-U4"? - Thomas -- 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: netstat showing multiple lines for each listening socket
My server has four (virtual; it runs on vSphere) CPUs and also shows four lines in `ss` output. The `ps` command shows the `-U` which - I assume - is set automatically triggered by the number of CPUs. # ps -elf | grep named 5 S named23769 1 9 80 0 - 251941 do_sig 07:12 ? 00:39:02 /usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf I am still in the process of figuring out my predecessor's custom setup... -Oorspronkelijk bericht- Van: Thomas Hungenberg Verzonden: dinsdag 9 juli 2024 14:52 Aan: Lee ; Tom Marcoen (EXT) ; bind-users@lists.isc.org Onderwerp: Re: netstat showing multiple lines for each listening socket On 08.07.24 15:59, Lee wrote: > How many cpus does your machine have? > I'm running bind at home; not a whole lot of traffic to named so it > seemed like all those threads were a waste. So pretend there's only > one cpu: > $ grep bind /etc/default/named > # OPTIONS="-u bind " >OPTIONS="-u bind -n 1" Thanks! I can confirm netstat and ss show only one line per socket when starting named with option "-n 1". However, according to the manpage there should be "*two* threads per each CPU present": = -n #cpus This option controls the number of CPUs that named assumes the presence of. If not specified, named tries to determine the number of CPUs present automatically; if it fails, a single CPU is assumed to be present. named creates two threads per each CPU present (one thread for receiving and sending client traffic and another thread for sending and receiving resolver traffic) and then on top of that a single thread for handling time-based events. = When running named without setting "-n" on a test VM with a single CPU assigned, I see two threads per socket which matches what the manpage says. When starting named with "-n 1" I would expect to see two threads as well but there is only one in the netstat / ss output. And on a small embedded system with a single CPU, it creates *four* threads per socket. Hmmm... - Thomas Disclaimer High Tech Campus Eindhoven: The information contained in this message and attachments may be confidential and legally protected under applicable law. The message and attachments are intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message and attachments is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. Please visit: http://www.hightechcampus.com/go/pages/disclaimer for the most recent disclaimer. -- 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: netstat showing multiple lines for each listening socket
On 08.07.24 15:59, Lee wrote:
How many cpus does your machine have?
I'm running bind at home; not a whole lot of traffic to named so it
seemed like all those threads were a waste. So pretend there's only
one cpu:
$ grep bind /etc/default/named
# OPTIONS="-u bind "
OPTIONS="-u bind -n 1"
Thanks!
I can confirm netstat and ss show only one line per socket when starting
named with option "-n 1".
However, according to the manpage there should be "*two* threads per each CPU
present":
=
-n #cpus
This option controls the number of CPUs that named assumes the
presence of.
If not specified, named tries to determine the number of CPUs
present automatically; if it fails, a single CPU is assumed to be
present.
named creates two threads per each CPU present (one thread for
receiving
and sending client traffic and another thread for sending and
receiving resolver traffic) and then on top of that a single
thread for
handling time-based events.
=
When running named without setting "-n" on a test VM with a single CPU assigned,
I see two threads per socket which matches what the manpage says.
When starting named with "-n 1" I would expect to see two threads as well
but there is only one in the netstat / ss output.
And on a small embedded system with a single CPU, it creates *four* threads
per socket.
Hmmm...
- Thomas
--
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: zone_journal_compact: could not get zone size: not found
Indeed the LDAP plugin does not provide the getsize method. Until now it
never has.
I'll notify the maintainer.
I have a question that you may be able to answer. Is the getsize method
a required method or an optional one?
If the latter then the zone_journal_compact function needs to become a
bit more friendly with its logging, because journalctl colors the
message in red (meaning: something is wrong here).
-- Kees
On 08-07-2024 17:17, Ondřej Surý wrote:
You need to ask FreeIPA people and your vendor (but my guess is that
the dyndb plugin provided by RH doesn’t provide this method).
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do
not feel obligated to reply outside your normal working hours.
On 8. 7. 2024, at 16:48, Kees Bakker via bind-users
wrote:
Running gdb showed that the "not found" comes from this piece of code
isc_result_t
dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records,
uint64_t*bytes) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE(dns_db_iszone(db));
if(db->methods->getsize!= NULL) {
return((db->methods->getsize)(db, version, records, bytes));
}
return(ISC_R_NOTFOUND);
} That db->methods-getsize is NULL. Here is a piece of the gdb
session 08-Jul-2024 16:39:29.587 dump_done: zone
29.16.172.in-addr.arpa/IN: enter Thread 2 "isc-net-" hit
Breakpoint 2, zone_journal_compact (zone=0x7062ffd0,
db=0x76151268, serial=1720448567) at
../../../lib/dns/zone.c:11654 11654 dns_db_currentversion(db, );
(gdb) n 11655 result = dns_db_getsize(db, ver, NULL, ); (gdb)
s dns_db_getsize (db=0x76151268, version=0x7fffdba86640,
records=0x0, bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955 955
uint64_t *bytes) { (gdb) n 956 REQUIRE(DNS_DB_VALID(db)); (gdb) 957
REQUIRE(dns_db_iszone(db)); (gdb) 959 if (db->methods->getsize !=
NULL) { (gdb) p db->methods->getsize $3 = (isc_result_t (*)(dns_db_t
*, dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0 The question now
is: why is that getsize method NULL? Or, should it never have gotten
here?
-- Kees
On 08-07-2024 13:42, Greg Choules wrote:
EXTERNAL E-MAIL ****
Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where
BIND keeps its files?
- How much RAM does the server have and how much of that is BIND using?
I would recommend reading the ARM section on the journal. The log
message itself comes from "zone.c"
Cheers, Greg
On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users
wrote:
Hi,
At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.
Jul 03 07:50:44 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:03 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:34 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:52:12 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:03:51 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:06:30 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:18:42 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:26:23 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.a
Re: zone_journal_compact: could not get zone size: not found
Running gdb showed that the "not found" comes from this piece of code
isc_result_t
dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records,
uint64_t*bytes) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE(dns_db_iszone(db));
if(db->methods->getsize!= NULL) {
return((db->methods->getsize)(db, version, records, bytes));
}
return(ISC_R_NOTFOUND);
} That db->methods-getsize is NULL. Here is a piece of the gdb session
08-Jul-2024 16:39:29.587 dump_done: zone 29.16.172.in-addr.arpa/IN:
enter Thread 2 "isc-net-" hit Breakpoint 2, zone_journal_compact
(zone=0x7062ffd0, db=0x76151268, serial=1720448567) at
../../../lib/dns/zone.c:11654 11654 dns_db_currentversion(db, );
(gdb) n 11655 result = dns_db_getsize(db, ver, NULL, ); (gdb) s
dns_db_getsize (db=0x76151268, version=0x7fffdba86640, records=0x0,
bytes=0x75fcc4b8) at ../../../lib/dns/db.c:955 955 uint64_t *bytes)
{ (gdb) n 956 REQUIRE(DNS_DB_VALID(db)); (gdb) 957
REQUIRE(dns_db_iszone(db)); (gdb) 959 if (db->methods->getsize != NULL)
{ (gdb) p db->methods->getsize $3 = (isc_result_t (*)(dns_db_t *,
dns_dbversion_t *, uint64_t *, uint64_t *)) 0x0 The question now is: why
is that getsize method NULL? Or, should it never have gotten here?
-- Kees
On 08-07-2024 13:42, Greg Choules wrote:
EXTERNAL E-MAIL ****
Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where
BIND keeps its files?
- How much RAM does the server have and how much of that is BIND using?
I would recommend reading the ARM section on the journal. The log
message itself comes from "zone.c"
Cheers, Greg
On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users
wrote:
Hi,
At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.
Jul 03 07:50:44 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:03 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:51:34 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 07:52:12 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:03:51 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:06:30 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:18:42 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:26:23 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
Jul 03 08:34:12 iparep5.example.com <http://iparep5.example.com>
named[541]: zone example.com/IN <http://example.com/IN>:
zone_journal_compact: could not get zone size: not found
Jul 03 08:34:50 iparep5.example.com <http://iparep5.example.com>
named[541]: zone
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
size: not found
I have been running FreeIPA (including the bind nameserver) for
several
years now and I have never seen this message before.
I still have one FreeIPA system running CentOS 8-Stream.
Does anyone have a clue what it can be? Or how to find out? There are
close to zero hits when I searched for this on the internet.
How to debug this? (How to d
Re: zone_journal_compact: could not get zone size: not found
On 08-07-2024 13:42, Greg Choules wrote: Hi Kees. Hi Greg, thanks for the quick reply. A few questions: - What version of BIND are you running? 9.16.23 (in centos that is 32:9.16.23-15.el9) - How large (number of RRs) are your zones? My main zone (renamed to example.com) is about 800 RRs (if I interpret RR correctly). The in-addr.arpa zones have 150-200 entrie. What you need to know is that this is a FreeIPA environment. The zones are stored in LDAP. The DHCP sends its updates to one of the bind servers. These updates are then replicated in LDAP. - What is the peak rate of dynamic updates? Don't know. Is there is simple command to show this. - Do you have "max-journal-size" configured to anything? That should be the default. I haven't specifically changed it. - Are you perhaps getting short on disc storage in the place where BIND keeps its files? No. Many GBs free disk space. The jnl files that I see are just a few kbs in size. - How much RAM does the server have and how much of that is BIND using? One has 8GB. Two others have 128GB (because they run in an LXC/Incus container). I would recommend reading the ARM section on the journal. The log message itself comes from "zone.c" OK. I have a global understanding what the journal is doing. I went through the zone.c code before posting this here. But so far I could not figure out how this message can be triggered. And also, the systems didn't show this message before upgrading CentOS. One system is still at CentOS 8-Stream. The message isn't shown on that one. Cheers, Greg -- Kees On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users wrote: Hi, At the moment I have three FreeIPA systems (replicas), recently installed with CentOS 9-Stream. All three of these show this message at irregular intervals. Jul 03 07:50:44 iparep5.example.com <http://iparep5.example.com> named[541]: zone example.com/IN <http://example.com/IN>: zone_journal_compact: could not get zone size: not found Jul 03 07:50:51 iparep5.example.com <http://iparep5.example.com> named[541]: zone 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:03 iparep5.example.com <http://iparep5.example.com> named[541]: zone 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:34 iparep5.example.com <http://iparep5.example.com> named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:52:12 iparep5.example.com <http://iparep5.example.com> named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:03:51 iparep5.example.com <http://iparep5.example.com> named[541]: zone example.com/IN <http://example.com/IN>: zone_journal_compact: could not get zone size: not found Jul 03 08:04:52 iparep5.example.com <http://iparep5.example.com> named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:06:30 iparep5.example.com <http://iparep5.example.com> named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:18:42 iparep5.example.com <http://iparep5.example.com> named[541]: zone example.com/IN <http://example.com/IN>: zone_journal_compact: could not get zone size: not found Jul 03 08:20:19 iparep5.example.com <http://iparep5.example.com> named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:26:23 iparep5.example.com <http://iparep5.example.com> named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:34:12 iparep5.example.com <http://iparep5.example.com> named[541]: zone example.com/IN <http://example.com/IN>: zone_journal_compact: could not get zone size: not found Jul 03 08:34:50 iparep5.example.com <http://iparep5.example.com> named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found I have been running FreeIPA (including the bind nameserver) for several years now and I have never seen this message before. I still have one FreeIPA system running CentOS 8-Stream. Does anyone have a clue what it can be? Or how to find out? There are close to zero hits when I searched for this on the internet. How to debug this? (How to debug this in a production environment, ha ha) -- Kees -- 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. Conta
RE: netstat showing multiple lines for each listening socket
I observe the same behaviour. I have similar output for TCP/53 on the loopback
and public IP addresses. The IP addresses and port numbers are the same, but
the fd (file descriptors?) are different. I assumed different threads of the
same process.
# named -V | grep ^BIND
BIND 9.18.26 (Extended Support Version)
# ss -lntp | grep 953
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=64))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=61))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=63))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=62))
-----Oorspronkelijk bericht-
Van: bind-users Namens Thomas Hungenberg via
bind-users
Verzonden: maandag 8 juli 2024 13:13
Aan: Robert Wagner ; bind-users@lists.isc.org
Onderwerp: Re: netstat showing multiple lines for each listening socket
Hi Robert,
it's the same PID for all lines, parent process is systemd.
The lines in the netstat output are exact duplicates (same IP, port and PID).
Other tools like ss show the same, so it's not a problem with netstat.
It's the same bahaviour on different machines, some upgraded from Debian < 11
and others installed from scratch with Debian 11 or 12.
I also set up a test VM and started BIND with the default configuration shipped
with Debian.
Same behaviour: All lines are shown twice.
It looks like on machines with only two interfaces (lo / eth0) the lines are
shown twice
while on machines with more interfaces (active or not) there are up to 20
duplicate lines.
- Thomas
On 08.07.24 12:10, Robert Wagner wrote:
> Some diagnostics is needed. When you reboot, does it show it up multiple
> binds to the same port? Can your run netstat -tP to identify the process ID
> (are they the same or different). There may also be other options to provide
> more diagnostics.
>
> -Trying to determine if you are really binding the service four times to the
> same port or this is just a ghost in the netstat program... Most systems are
> designed to prevent binding multiple applications to the same ip/port, but a
> service can spawn multiple threads on the same ip/port. You may be seeing
> the threads and not unique service instances.
>
> Looking at the process ID, you may be able to track back to the root process
> and determine if these are just service threads.
>
>
> Robert Wagner
>
>
> From: bind-users on behalf of Thomas
> Hungenberg via bind-users
> Sent: Monday, July 8, 2024 4:52 AM
> To: bind-users@lists.isc.org
> Subject: netstat showing multiple lines for each listening socket
>
> This email originated from outside of TESLA
>
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Hello,
>
> we have been running some BIND nameservers on Debian-based systems for many
> years.
>
> Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one
> line
> per listening socket, e.g.
>
> tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN
> 1234/named
> tcp0 0 127.0.0.1:530.0.0.0:* LISTEN
> 1234/named
> udp0 0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0 0 127.0.0.1:530.0.0.0:*
> 1234/named
>
>
> We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat
> instead
> shows multiple (on some systems four, on others up to 20) completely
> identical lines
> for each listening socket, like this:
>
> tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN
> 1234/named
> tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN
> 1234/named
> tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN
> 1234/named
> tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN
> 1234/named
> tcp0 0 127.0.0.1:530.0.0.0:* LISTEN
> 1234/named
> tcp0 0 127.0.0.1:530.0.0.0:* LISTEN
> 1234/named
> tcp0 0 127.0.0.1:530.0.0.0:* LISTEN
> 1234/named
> tcp0 0 127.0.0.1:530.0.0.0:* LISTEN
> 1234/named
> udp0 0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0 0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0 0 10.x.x.x:53 0.0.0.0:*
> 1234/named
> udp0 0 10.x.x.x:53 0.
Re: zone_journal_compact: could not get zone size: not found
Hi Kees. A few questions: - What version of BIND are you running? - How large (number of RRs) are your zones? - What is the peak rate of dynamic updates? - Do you have "max-journal-size" configured to anything? - Are you perhaps getting short on disc storage in the place where BIND keeps its files? - How much RAM does the server have and how much of that is BIND using? I would recommend reading the ARM section on the journal. The log message itself comes from "zone.c" Cheers, Greg On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users < bind-users@lists.isc.org> wrote: > Hi, > > At the moment I have three FreeIPA systems (replicas), recently > installed with CentOS 9-Stream. > All three of these show this message at irregular intervals. > > Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: > zone_journal_compact: could not get zone size: not found > Jul 03 07:50:51 iparep5.example.com named[541]: zone > 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 07:51:03 iparep5.example.com named[541]: zone > 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 07:51:34 iparep5.example.com named[541]: zone > 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 07:52:12 iparep5.example.com named[541]: zone > 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: > zone_journal_compact: could not get zone size: not found > Jul 03 08:04:52 iparep5.example.com named[541]: zone > 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 08:06:30 iparep5.example.com named[541]: zone > 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: > zone_journal_compact: could not get zone size: not found > Jul 03 08:20:19 iparep5.example.com named[541]: zone > 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 08:26:23 iparep5.example.com named[541]: zone > 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN: > zone_journal_compact: could not get zone size: not found > Jul 03 08:34:50 iparep5.example.com named[541]: zone > 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone > size: not found > > I have been running FreeIPA (including the bind nameserver) for several > years now and I have never seen this message before. > I still have one FreeIPA system running CentOS 8-Stream. > > Does anyone have a clue what it can be? Or how to find out? There are > close to zero hits when I searched for this on the internet. > How to debug this? (How to debug this in a production environment, ha ha) > -- > Kees > -- > 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 > -- 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
zone_journal_compact: could not get zone size: not found
Hi, At the moment I have three FreeIPA systems (replicas), recently installed with CentOS 9-Stream. All three of these show this message at irregular intervals. Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:50:51 iparep5.example.com named[541]: zone 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:03 iparep5.example.com named[541]: zone 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:34 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:52:12 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:04:52 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:06:30 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:20:19 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:26:23 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:34:50 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found I have been running FreeIPA (including the bind nameserver) for several years now and I have never seen this message before. I still have one FreeIPA system running CentOS 8-Stream. Does anyone have a clue what it can be? Or how to find out? There are close to zero hits when I searched for this on the internet. How to debug this? (How to debug this in a production environment, ha ha) -- Kees -- 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: netstat showing multiple lines for each listening socket
Hi Robert, it's the same PID for all lines, parent process is systemd. The lines in the netstat output are exact duplicates (same IP, port and PID). Other tools like ss show the same, so it's not a problem with netstat. It's the same bahaviour on different machines, some upgraded from Debian < 11 and others installed from scratch with Debian 11 or 12. I also set up a test VM and started BIND with the default configuration shipped with Debian. Same behaviour: All lines are shown twice. It looks like on machines with only two interfaces (lo / eth0) the lines are shown twice while on machines with more interfaces (active or not) there are up to 20 duplicate lines. - Thomas On 08.07.24 12:10, Robert Wagner wrote: Some diagnostics is needed. When you reboot, does it show it up multiple binds to the same port? Can your run netstat -tP to identify the process ID (are they the same or different). There may also be other options to provide more diagnostics. -Trying to determine if you are really binding the service four times to the same port or this is just a ghost in the netstat program... Most systems are designed to prevent binding multiple applications to the same ip/port, but a service can spawn multiple threads on the same ip/port. You may be seeing the threads and not unique service instances. Looking at the process ID, you may be able to track back to the root process and determine if these are just service threads. Robert Wagner From: bind-users on behalf of Thomas Hungenberg via bind-users Sent: Monday, July 8, 2024 4:52 AM To: bind-users@lists.isc.org Subject: netstat showing multiple lines for each listening socket This email originated from outside of TESLA Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, we have been running some BIND nameservers on Debian-based systems for many years. Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one line per listening socket, e.g. tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead shows multiple (on some systems four, on others up to 20) completely identical lines for each listening socket, like this: tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named We wonder what is causing this and if this is intended behaviour? - Thomas  -- 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 -- 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
netstat showing multiple lines for each listening socket
Hello, we have been running some BIND nameservers on Debian-based systems for many years. Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one line per listening socket, e.g. tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead shows multiple (on some systems four, on others up to 20) completely identical lines for each listening socket, like this: tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 10.x.x.x:53 0.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named udp0 0 127.0.0.1:530.0.0.0:* 1234/named We wonder what is causing this and if this is intended behaviour? - Thomas  -- 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: rolling my own hints file
Hi Brian. You need the NS record(s) in hints because this is what a resolver wants first; the name(s) of the NS for a given zone. Regarding "@" or ".", they amount to the same thing in my example, though perhaps I was being a bit lazy and minimal. @ represents the name of the zone (or the most recent $ORIGIN declaration), so in this case "", or the root zone. The names of the NS are specified with this, so they have no explicit names and that's what the A records are tied to. For the NS record it says that it belongs to the zone with name "@", or root (the "owner" field, on the left hand side), and the name of the NS for that zone is also @, which from above is what owns the A records. It might be easier to understand if you give the NS a name, such as: myroots.mydomain. A X.Y.Z.7 myroots.mydomain. A X.Y.Z.8 NOTE: The dot after "...mydomain" terminates the name (like "." in a sentence) and prevents it from inheriting the name of the zone. In this zone it doesn't matter because the zone is "", so there is nothing to inherit. In any other zone, it matters. Then the NS record would become either: . IN NS myroots.mydomain. or @ IN NS myroots.mydomain. "." is more conventional and is an absolute representation of the root. "@" works too, but is a relative reference to 'this zone we are in', which just happens to be the root zone. Compare this with how it's done in the Internet hints file: .360 IN NSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 A 198.41.0.4 A.ROOT-SERVERS.NET. 360 2001:503:BA3E::2:30 Hope that helps. Greg On Mon, 1 Jul 2024 at 16:05, Cuttler, Brian R (HEALTH) < brian.cutt...@health.ny.gov> wrote: > Greg, David, > > > > Another questions or two before I commit the changes to my hints file. > > > I have only the two servers, this last line isn’t necessary? Or for that > matter, possibly detrimental? > If it is, its “dot” rather than “at”? > > @ 518400 IN A xx.yy.zz..7 > > @ 518400 IN A xx.yy.zz..8 > > . 518400IN NS @ > > > > Thank you. > > Brian > > > > *From:* bind-users * On Behalf Of *Cuttler, > Brian R (HEALTH) via bind-users > *Sent:* Wednesday, June 26, 2024 12:56 PM > *To:* Greg Choules ; David Farje < > davidabelfa...@gmail.com> > *Cc:* bind-users ; Hefner, Joseph (HEALTH) < > joseph.hef...@health.ny.gov> > *Subject:* RE: rolling my own hints file > > > > *ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails.* > > > > > > Greg, David, > > > > Thanks, much easier than what I thought it would be. > > I have two “root” servers so I went with this format, allowing a round > robin selection. > > Essentially this, sorry trying to be vague on the IPs. > > > > @ 518400 IN A xx.yy.zz..7 > > @ 518400 IN A xx.yy.zz..8 > > . 518400IN NS @ > > > > Server reloaded fine and I am able to resolve non-domain information. > Is there a flag someplace in dig or nslookup to show what root server I’m > hitting? I don’t see that in any of the named log files, I may need to add > an ACL to log the traffic in a router to verify. > Then again – my FW is not seeing queries to any of the normal root > servers, so that is in fact a good sign. > > > > New root servers are managed by my parent organization and my manager > asked me to send these queries through them. Wouldn’t be performing this > exercise otherwise. > > > > Thank you – I think you’ve given me exactly what was needed. > > > > Brian > > > > *From:* Greg Choules > *Sent:* Wednesday, June 26, 2024 12:29 PM > *To:* Cuttler, Brian R (HEALTH) > *Cc:* bind-users > *Subject:* Re: rolling my own hints file > > > > You don't often get email from gregchoules+bindus...@googlemail.com. Learn > why this is important <https://aka.ms/LearnAboutSenderIdentification> > > *ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails.* > > > > Hi Brian. > > Yes, you can define your own hint zone and tell BIND to use it. The > contents (I called the file "db.root" but the name is your choice) could be > as simple as: > > > > @ 300 IN A 127.0.0.3 > @ 300 IN NS @ > > > > which says for this zone (which will be called ".", coming next) the NS is > the same name and its IP is 127.0.0.3, which happens to be another instance > of BIND I have running. Your file would contain the names and IPs
RE: rolling my own hints file
Greg, David,
Another questions or two before I commit the changes to my hints file.
I have only the two servers, this last line isn't necessary? Or for that
matter, possibly detrimental?
If it is, its "dot" rather than "at"?
@ 518400 IN A xx.yy.zz..7
@ 518400 IN A xx.yy.zz..8
. 518400IN NS @
Thank you.
Brian
From: bind-users On Behalf Of Cuttler, Brian
R (HEALTH) via bind-users
Sent: Wednesday, June 26, 2024 12:56 PM
To: Greg Choules ; David Farje
Cc: bind-users ; Hefner, Joseph (HEALTH)
Subject: RE: rolling my own hints file
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Greg, David,
Thanks, much easier than what I thought it would be.
I have two "root" servers so I went with this format, allowing a round robin
selection.
Essentially this, sorry trying to be vague on the IPs.
@ 518400 IN A xx.yy.zz..7
@ 518400 IN A xx.yy.zz..8
. 518400IN NS @
Server reloaded fine and I am able to resolve non-domain information.
Is there a flag someplace in dig or nslookup to show what root server I'm
hitting? I don't see that in any of the named log files, I may need to add an
ACL to log the traffic in a router to verify.
Then again - my FW is not seeing queries to any of the normal root servers, so
that is in fact a good sign.
New root servers are managed by my parent organization and my manager asked me
to send these queries through them. Wouldn't be performing this exercise
otherwise.
Thank you - I think you've given me exactly what was needed.
Brian
From: Greg Choules
mailto:gregchoules+bindus...@googlemail.com>>
Sent: Wednesday, June 26, 2024 12:29 PM
To: Cuttler, Brian R (HEALTH)
mailto:brian.cutt...@health.ny.gov>>
Cc: bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: rolling my own hints file
You don't often get email from
gregchoules+bindus...@googlemail.com<mailto:gregchoules+bindus...@googlemail.com>.
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The contents (I
called the file "db.root" but the name is your choice) could be as simple as:
@ 300 IN A 127.0.0.3
@ 300 IN NS @
which says for this zone (which will be called ".", coming next) the NS is the
same name and its IP is 127.0.0.3, which happens to be another instance of BIND
I have running. Your file would contain the names and IPs of your internal
roots.
In the config, define the hint zone like this:
zone "." {
type hint;
file "db.root";
};
That should be all you need.
Cheers, Greg
On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users
mailto:bind-users@lists.isc.org>> wrote:
Running Bind 9.18.18 on Ubuntu 22.04
We would like to use root servers within our organization rather than the
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to
still access the official root servers.
Wondering how I ignore the internal/build-in hints and have my own file.
Wondering if replacing the IP addresses in the db.cache file with a round-robin
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?
Is there a supported way to do what I want to do - we do not want an forwarding
only server, we do serve a good number of internal statis and dynamic zones but
also want to resolve non-domain addresses or addresses we lack forwarder zones
for from a 'root' source.
;; ADDITIONAL SECTION:
a.root-servers.net<http://a.root-servers.net/>. 518400 IN A
198.41.0.4
b.root-servers.net<http://b.root-servers.net/>. 518400 IN A
170.247.170.2
c.root-servers.net<http://c.root-servers.net/>. 518400 IN A
192.33.4.12
Thanks for your help and suggestions,
Brian
Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov<mailto:brian.cutt...@health.ny.gov>
518 486-1697
--
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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
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: forward option in dns server
Correct.
On Fri, 28 Jun 2024, 12:54 Renzo Marengo, wrote:
> Ok very veri interesting,and about this doubt?
>
> etc/resolv.conf in bind server is used only from client services ? E.g.
> ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
> Thanks again
>
> Il giorno ven 28 giu 2024 alle ore 13:10 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi again Renzo.
>>
>> In general, BIND (and other resolvers) make non-recursives (aka
>> iterative) queries to authoritative servers, such as the roots and others.
>>
>> - Clients (laptops etc.) make recursive queries to the DCs. If the DCs
>> know the answer they respond immediately; no forwarding needed.
>> - If the DCs don't (currently) know the answer, they make recursive
>> queries to BIND because that's what you have told them to do, using either
>> global or conditional forwarding. If BIND knows the answer it responds
>> immediately; no need to make queries into the Internet.
>> - If BIND doesn't (currently) know the answer it makes non-recursive
>> queries to anywhere it needs, to gather information to construct a response.
>> It is important to note that each of these is a separate DNS conversation.
>>
>> Does that help?
>>
>> Please get another server (and a test server) and upgrade them all to
>> current software.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 11:58, Renzo Marengo
>> wrote:
>>
>>> Hi Greg again! :)
>>>
>>> > 1) This should help you understand the difference between recursive
>>> and non-recursive queries.
>>> I read about recursive and iterative query but I think A.B.C.D server
>>> should be as recursive server for domain controllers, I ask myself the same
>>> question to root servers? Or Bind9 server should have to make iterative
>>> queries to root servers ?
>>>
>>> > I hope this server is behind a good firewall?
>>> Yes
>>>
>>> >Do you only have one BIND server?
>>> >I would recommend two at least, in case you need to take one down for
>>> maintenance or it fails for some reason.
>>> Yes only one server
>>>
>>> >> Your "allow-..." statements should look like this, with IP addresses,
>>> not domain names.
>>> Oh yes, this one was to explain you what servers I inserted into this
>>> list.
>>>
>>>
>>> I have another doubt, /etc/resolv.conf in bind server is used only from
>>> client services ? E.g. ping tool
>>> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>>>
>>>
>>>
>>>
>>>
>>> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
>>>> Hi Renzo.
>>>> You're welcome.
>>>> 1) Correct. You don't need forwarding for a simple resolver. Take a
>>>> look at the meaning of the RD flag in the BIND protocol header. This should
>>>> help you understand the difference between recursive and non-recursive
>>>> queries.
>>>> 2) No. See 1)
>>>> 3) Yes. For a standard resolver facing the Internet you do not need a
>>>> hint zone.
>>>>
>>>> Some more thoughts occurred to me:
>>>> - I hope this server is behind a good firewall?
>>>> - Do you only have one BIND server? I would recommend two at least, in
>>>> case you need to take one down for maintenance or it fails for some reason.
>>>> - Your "allow-..." statements should look like this, with IP addresses,
>>>> not domain names.
>>>>allow-... {127.0.0.1; ;
>>>> ; ;}; You do
>>>> not need to include this server in the list.
>>>>
>>>> Any changes you make should be done on a test server first, so you can
>>>> be comfortable understanding what effect those changes have and only move
>>>> them to production when you are certain.
>>>>
>>>> Cheers, Greg
>>>>
>>>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo
>>>> wrote:
>>>>
>>>>> Hi greg,
>>>>> I thank you again for your suggestions.
>>>>>
>>>>> >A.B.C.D is the address of this server?
>>>>> yes, It's the Bind server
>>>>>
>>>>> I read several documents about DNS architecture
>>>>> My questions is about this configuratio
Re: forward option in dns server
Hi again Renzo.
In general, BIND (and other resolvers) make non-recursives (aka iterative)
queries to authoritative servers, such as the roots and others.
- Clients (laptops etc.) make recursive queries to the DCs. If the DCs know
the answer they respond immediately; no forwarding needed.
- If the DCs don't (currently) know the answer, they make recursive queries
to BIND because that's what you have told them to do, using either global
or conditional forwarding. If BIND knows the answer it responds
immediately; no need to make queries into the Internet.
- If BIND doesn't (currently) know the answer it makes non-recursive
queries to anywhere it needs, to gather information to construct a response.
It is important to note that each of these is a separate DNS conversation.
Does that help?
Please get another server (and a test server) and upgrade them all to
current software.
Cheers, Greg
On Fri, 28 Jun 2024 at 11:58, Renzo Marengo wrote:
> Hi Greg again! :)
>
> > 1) This should help you understand the difference between recursive and
> non-recursive queries.
> I read about recursive and iterative query but I think A.B.C.D server
> should be as recursive server for domain controllers, I ask myself the same
> question to root servers? Or Bind9 server should have to make iterative
> queries to root servers ?
>
> > I hope this server is behind a good firewall?
> Yes
>
> >Do you only have one BIND server?
> >I would recommend two at least, in case you need to take one down for
> maintenance or it fails for some reason.
> Yes only one server
>
> >> Your "allow-..." statements should look like this, with IP addresses,
> not domain names.
> Oh yes, this one was to explain you what servers I inserted into this
> list.
>
>
> I have another doubt, /etc/resolv.conf in bind server is used only from
> client services ? E.g. ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
>
>
>
>
> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> You're welcome.
>> 1) Correct. You don't need forwarding for a simple resolver. Take a look
>> at the meaning of the RD flag in the BIND protocol header. This should help
>> you understand the difference between recursive and non-recursive queries.
>> 2) No. See 1)
>> 3) Yes. For a standard resolver facing the Internet you do not need a
>> hint zone.
>>
>> Some more thoughts occurred to me:
>> - I hope this server is behind a good firewall?
>> - Do you only have one BIND server? I would recommend two at least, in
>> case you need to take one down for maintenance or it fails for some reason.
>> - Your "allow-..." statements should look like this, with IP addresses,
>> not domain names.
>>allow-... {127.0.0.1; ;
>> ; ;}; You do
>> not need to include this server in the list.
>>
>> Any changes you make should be done on a test server first, so you can be
>> comfortable understanding what effect those changes have and only move them
>> to production when you are certain.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo
>> wrote:
>>
>>> Hi greg,
>>> I thank you again for your suggestions.
>>>
>>> >A.B.C.D is the address of this server?
>>> yes, It's the Bind server
>>>
>>> I read several documents about DNS architecture
>>> My questions is about this configuration of bind:
>>>
>>> 1- according to your opinion my bind makes queries ro root server if is
>>> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
>>> 2- Do you suggest to set some "forwarders" ?
>>> 3-- This bind version has root server built-in? If I removed 'named.ca'
>>> reference, Bind would use root server built-in?
>>>
>>> thanks
>>>
>>> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
>>>> Hi Renzo.
>>>>
>>>> Thank you for that. The hints look OK. A bit old, but they will work.
>>>>
>>>> The first thing I would advise you to do as a matter of priority is to
>>>> upgrade BIND.
>>>> 9.11 has been end-of-life for a few years and there have been many
>>>> security fixes since then. 9.18.27 is the current version.
>>>> You could install that directly, or upgrade RHEL and obtain a more
>>>> recent packaged version.
>>>>
>>>>
>>>> You can check what BIND is doi
Re: forward option in dns server
Hi Renzo.
You're welcome.
1) Correct. You don't need forwarding for a simple resolver. Take a look at
the meaning of the RD flag in the BIND protocol header. This should help
you understand the difference between recursive and non-recursive queries.
2) No. See 1)
3) Yes. For a standard resolver facing the Internet you do not need a hint
zone.
Some more thoughts occurred to me:
- I hope this server is behind a good firewall?
- Do you only have one BIND server? I would recommend two at least, in case
you need to take one down for maintenance or it fails for some reason.
- Your "allow-..." statements should look like this, with IP addresses, not
domain names.
allow-... {127.0.0.1; ;
; ;}; You do
not need to include this server in the list.
Any changes you make should be done on a test server first, so you can be
comfortable understanding what effect those changes have and only move them
to production when you are certain.
Cheers, Greg
On Fri, 28 Jun 2024 at 07:14, Renzo Marengo wrote:
> Hi greg,
> I thank you again for your suggestions.
>
> >A.B.C.D is the address of this server?
> yes, It's the Bind server
>
> I read several documents about DNS architecture
> My questions is about this configuration of bind:
>
> 1- according to your opinion my bind makes queries ro root server if is
> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
> 2- Do you suggest to set some "forwarders" ?
> 3-- This bind version has root server built-in? If I removed 'named.ca'
> reference, Bind would use root server built-in?
>
> thanks
>
> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>>
>> Thank you for that. The hints look OK. A bit old, but they will work.
>>
>> The first thing I would advise you to do as a matter of priority is to
>> upgrade BIND.
>> 9.11 has been end-of-life for a few years and there have been many
>> security fixes since then. 9.18.27 is the current version.
>> You could install that directly, or upgrade RHEL and obtain a more recent
>> packaged version.
>>
>>
>> You can check what BIND is doing by using "tcpdump". For example:
>> sudo tcpdump -n -i -c 1000 port 53 and host A.B.C.D
>>
>> I am making some assumptions:
>> A.B.C.D is the address of this server?
>> is the name of the interface the server will use for outbound
>> queries, according to its routeing table. I am guessing this is the
>> interface with address A.B.C.D?
>> -c stops the capture after 1000 packets. This is just a safety precaution.
>> port 53 and host A.B.C.D limits the capture to only packets with port 53
>> (DNS) AND with the address of this interface, so you don't capture any SSH
>> or HTTPS etc.
>>
>> A fresh (recently restarted) DNS resolver - any one, not just BIND - will
>> make queries to the root to start with. It does this to learn where to go
>> next. It stores the results of those queries in its cache so that it
>> doesn't have to make them again for some time.
>>
>> There are many good books and articles available online to explain the
>> basics of DNS. The BIND ARM (distributed with BIND and also available
>> online) is the reference manual for BIND itself.
>>
>> I hope that helps.
>> Greg
>>
>> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo
>> wrote:
>>
>>> Hi Greg,
>>> he info you required:
>>>
>>> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
>>> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
>>> 2) named.ca if file which contains root servers
>>> named.ca
>>>
>>> . 518400 IN NS a.root-servers.net.
>>> . 518400 IN NS b.root-servers.net.
>>> . 518400 IN NS c.root-servers.net.
>>> . 518400 IN NS d.root-servers.net.
>>> . 518400 IN NS e.root-servers.net.
>>> . 518400 IN NS f.root-servers.net.
>>> . 518400 IN NS g.root-servers.net.
>>> . 518400 IN NS h.root-servers.net.
>>> . 518400 IN NS i.root-servers.net.
>>> . 518400 IN NS j.root-servers.net.
>>> . 518400 IN NS k.root-servers.net.
>>> . 518400 IN NS l.root-servers.net.
>>> . 518400 IN NS
Re: forward option in dns server
Hi Renzo. Thank you for that. The hints look OK. A bit old, but they will work. The first thing I would advise you to do as a matter of priority is to upgrade BIND. 9.11 has been end-of-life for a few years and there have been many security fixes since then. 9.18.27 is the current version. You could install that directly, or upgrade RHEL and obtain a more recent packaged version. You can check what BIND is doing by using "tcpdump". For example: sudo tcpdump -n -i -c 1000 port 53 and host A.B.C.D I am making some assumptions: A.B.C.D is the address of this server? is the name of the interface the server will use for outbound queries, according to its routeing table. I am guessing this is the interface with address A.B.C.D? -c stops the capture after 1000 packets. This is just a safety precaution. port 53 and host A.B.C.D limits the capture to only packets with port 53 (DNS) AND with the address of this interface, so you don't capture any SSH or HTTPS etc. A fresh (recently restarted) DNS resolver - any one, not just BIND - will make queries to the root to start with. It does this to learn where to go next. It stores the results of those queries in its cache so that it doesn't have to make them again for some time. There are many good books and articles available online to explain the basics of DNS. The BIND ARM (distributed with BIND and also available online) is the reference manual for BIND itself. I hope that helps. Greg On Fri, 28 Jun 2024 at 05:57, Renzo Marengo wrote: > Hi Greg, > he info you required: > > 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version) > on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64 > 2) named.ca if file which contains root servers > named.ca > > . 518400 IN NS a.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS d.root-servers.net. > . 518400 IN NS e.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS g.root-servers.net. > . 518400 IN NS h.root-servers.net. > . 518400 IN NS i.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS m.root-servers.net. > > ;; ADDITIONAL SECTION: > a.root-servers.net. 518400 IN A 198.41.0.4 > b.root-servers.net. 518400 IN A 199.9.14.201 > c.root-servers.net. 518400 IN A 192.33.4.12 > d.root-servers.net. 518400 IN A 199.7.91.13 > e.root-servers.net. 518400 IN A 192.203.230.10 > f.root-servers.net. 518400 IN A 192.5.5.241 > g.root-servers.net. 518400 IN A 192.112.36.4 > h.root-servers.net. 518400 IN A 198.97.190.53 > i.root-servers.net. 518400 IN A 192.36.148.17 > j.root-servers.net. 518400 IN A 192.58.128.30 > k.root-servers.net. 518400 IN A 193.0.14.129 > l.root-servers.net. 518400 IN A 199.7.83.42 > m.root-servers.net. 518400 IN A 202.12.27.33 > a.root-servers.net. 518400 IN 2001:503:ba3e::2:30 > b.root-servers.net. 518400 IN 2001:500:200::b > c.root-servers.net. 518400 IN 2001:500:2::c > d.root-servers.net. 518400 IN 2001:500:2d::d > e.root-servers.net. 518400 IN 2001:500:a8::e > f.root-servers.net. 518400 IN 2001:500:2f::f > g.root-servers.net. 518400 IN 2001:500:12::d0d > h.root-servers.net. 518400 IN 2001:500:1::53 > i.root-servers.net. 518400 IN 2001:7fe::53 > j.root-servers.net. 518400 IN 2001:503:c27::2:30 > k.root-servers.net. 518400 IN 2001:7fd::1 > l.root-servers.net. 518400 IN 2001:500:9f::42 > m.root-servers.net. 518400 IN 2001:dc3::35 > > > I didn't know some Bind versions had the Internet root hints built-in. > About my configuration I understand that bind makes always queries to root > servers ? Right? > I'd like to re-check configuration of bind > > > Il giorno gio 27 giu 2024 alle ore 22:15 Greg Choules < > gregchoules+bindus...@googlemail.com> ha scritto: > >> Hi Renzo. >> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the &
Re: forward option in dns server
Hi Renzo.
Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
Internet on behalf of its clients, so it forwards to BIND.
In that case, two questions:
1) What version of BIND are you running? You can get this with "named -V"
2) What is in the file "named.ca"?
For a long time (which is why I need to know the version) BIND has had the
Internet root hints built in, so you don't need a hint zone anymore. Unless
you are defining different roots for some reason. Hence why I need to know
the contents of that file.
Thanks, Greg
On Thu, 27 Jun 2024 at 18:06, Renzo Marengo wrote:
>
> Hi Greg,
>
> thank you very much for your explanation.
>
> Let’s supposte AD domain was ‘my domain.it’ and I have 6000 computers of
> government institute.
>
> Here my bind configuration:
>
>
> named.conf
>
> ———
>
> include “…. named.conf.options" ;
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
> include “…. named.rfc1912.zones";
>
> include “…. named.root.key";
>
> ———
>
>
>
> named.conf.options
>
> ———
>
> logging {
>
> channel named_debug {
>
> syslog local6;
>
> severity debug 1;
>
> print-category yes;
>
> print-severity yes;
>
> print-time yes;
>
> };
>
> category default { named_debug; };
>
> };
>
>
> options {
>
> auth-nxdomain no;# conform to RFC1035
>
> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> allow-query {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> recursive-clients 3000;
>
> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ; ;
>
>
> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>
> directory “….. named";
>
> dump-file “….. cache_dump.db";
>
> statistics-file “….. named_stats.txt";
>
> memstatistics-file “…. named_mem_stats.txt";
>
> recursing-file “… named.recursing";
>
> secroots-file “… named.secroots";
>
> recursion yes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
>
> bindkeys-file "….. named.iscdlv.key";
>
> managed-keys-directory "….. dynamic";
>
> pid-file "….. named.pid";
>
> session-keyfile "….. session.key";
>
> ———
>
>
>
> >Thirdly, I would not forward to AD DNS, unless the AD servers also
> recurse and can provide >resolution for delegated names below the AD domain
>
> >that are not hosted on the AD servers themselves.
>
>
> There is no forward option to AD DNS. Forward is enable from AD DNS to
> A.B.C.D. bind9 server.
>
>
>
>
> All clients are using AD DNS infact every query, about name of ‘
> mydomain.it,’ is resolved from AD DNS.
>
> When client asks an external domain, e.g. www.google.it, AD server
> forward query to A.B.C.D. server. (Forward option is set on every domain
> controller)
>
> Only AD DNS make queries to A.B.C.D server and it’s necessary only to
> solve external domains.
>
> A.B.C.D. server never makes queries to AD server. A.B.C.D. is next dns
> server which partecipates when it’s necessary to resolve an external domain
>
>
> I hope to have explained right.
>
> I thought A.B.C.D server made query to root server because into
> configuration there is no reference to forward option, because I thought to
> set as DNS forward a government dns of my country. What do you think?
>
> I have doubts about recursive and iterative queries options too.
>
> Thanks
>
>
> Il giorno gio 27 giu 2024 alle ore 13:24 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> Firstly, please can we see your BIND configuration and have the actual AD
>> domain name.
>>
>> Secondly, BIND, or any other recursive DNS server, does not 'forward' to
>> the root servers, unless you have configured it explicitly to do so, which
>> would be a bad idea and not work anyway. It will recurse (paradoxically,
>> perform non-recursive aka iterative queries) to the roots and other
>> authoritative servers. It is an important distinction to be aware of.
>>
>> Thirdly, I would not forward to AD DNS, unless the AD servers also
>> recurse and can provide resolution for delegated names below the AD domain
>> that are not hosted on the AD servers themselves. Personally I would use a
>> stub or static-stub zone in BIND to refer to the AD domain.
>>
>>
Re: forward option in dns server
Hi Renzo. Firstly, please can we see your BIND configuration and have the actual AD domain name. Secondly, BIND, or any other recursive DNS server, does not 'forward' to the root servers, unless you have configured it explicitly to do so, which would be a bad idea and not work anyway. It will recurse (paradoxically, perform non-recursive aka iterative queries) to the roots and other authoritative servers. It is an important distinction to be aware of. Thirdly, I would not forward to AD DNS, unless the AD servers also recurse and can provide resolution for delegated names below the AD domain that are not hosted on the AD servers themselves. Personally I would use a stub or static-stub zone in BIND to refer to the AD domain. In general, decide which DNS is going to do the resolving and make that the control point, fetching data from wherever it needs to (e.g. AD DNS) - using non-recursive queries - and using that data to construct answers for its clients. I hope that helps. Cheers, Greg On Thu, 27 Jun 2024 at 12:02, Renzo Marengo wrote: > I have Active Directory domain ( 'mydomain.it' ) with 8 domain > controllers to manage 8000 computers. Every Domain controller acts as dns > service and resolve internal domain names while forward queries about > external domains to another server, which Bind9 dns server (It's inside my > company) > I'm checking this Bind9 configuration (Centos server) and I see no forward > servers so I think It makes bind9 forward queries directly to root servers. > What do you think ? > According your opinion this Bind9 server should have to forward requests > to one or more dns server by forward option? > > -- > 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 > -- 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: rolling my own hints file
Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup)
information about where the answer came from, if 'minimal-responses' is set
to "no". Usually clients don't need to know that, so please take a look at
how m-r works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses
Cheers, Greg
On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:
>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400 IN A xx.yy.zz..7
>
> @ 518400 IN A xx.yy.zz..8
>
> . 518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH)
> *Cc:* bind-users
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would contain the names and IPs of your
> internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400 IN A 198.41.0.4
>
> b.root-servers.net. 518400 IN A 170.247.170.2
>
> c.root-servers.net. 518400 IN A 192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
>
> --
> 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
>
>
--
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: rolling my own hints file
Greg, David,
Thanks, much easier than what I thought it would be.
I have two "root" servers so I went with this format, allowing a round robin
selection.
Essentially this, sorry trying to be vague on the IPs.
@ 518400 IN A xx.yy.zz..7
@ 518400 IN A xx.yy.zz..8
. 518400IN NS @
Server reloaded fine and I am able to resolve non-domain information.
Is there a flag someplace in dig or nslookup to show what root server I'm
hitting? I don't see that in any of the named log files, I may need to add an
ACL to log the traffic in a router to verify.
Then again - my FW is not seeing queries to any of the normal root servers, so
that is in fact a good sign.
New root servers are managed by my parent organization and my manager asked me
to send these queries through them. Wouldn't be performing this exercise
otherwise.
Thank you - I think you've given me exactly what was needed.
Brian
From: Greg Choules
Sent: Wednesday, June 26, 2024 12:29 PM
To: Cuttler, Brian R (HEALTH)
Cc: bind-users
Subject: Re: rolling my own hints file
You don't often get email from
gregchoules+bindus...@googlemail.com<mailto:gregchoules+bindus...@googlemail.com>.
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The contents (I
called the file "db.root" but the name is your choice) could be as simple as:
@ 300 IN A 127.0.0.3
@ 300 IN NS @
which says for this zone (which will be called ".", coming next) the NS is the
same name and its IP is 127.0.0.3, which happens to be another instance of BIND
I have running. Your file would contain the names and IPs of your internal
roots.
In the config, define the hint zone like this:
zone "." {
type hint;
file "db.root";
};
That should be all you need.
Cheers, Greg
On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users
mailto:bind-users@lists.isc.org>> wrote:
Running Bind 9.18.18 on Ubuntu 22.04
We would like to use root servers within our organization rather than the
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to
still access the official root servers.
Wondering how I ignore the internal/build-in hints and have my own file.
Wondering if replacing the IP addresses in the db.cache file with a round-robin
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?
Is there a supported way to do what I want to do - we do not want an forwarding
only server, we do serve a good number of internal statis and dynamic zones but
also want to resolve non-domain addresses or addresses we lack forwarder zones
for from a 'root' source.
;; ADDITIONAL SECTION:
a.root-servers.net<http://a.root-servers.net/>. 518400 IN A
198.41.0.4
b.root-servers.net<http://b.root-servers.net/>. 518400 IN A
170.247.170.2
c.root-servers.net<http://c.root-servers.net/>. 518400 IN A
192.33.4.12
Thanks for your help and suggestions,
Brian
Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov<mailto:brian.cutt...@health.ny.gov>
518 486-1697
--
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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
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: rolling my own hints file
Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The
contents (I called the file "db.root" but the name is your choice) could be
as simple as:
@ 300 IN A 127.0.0.3
@ 300 IN NS @
which says for this zone (which will be called ".", coming next) the NS is
the same name and its IP is 127.0.0.3, which happens to be another instance
of BIND I have running. Your file would contain the names and IPs of your
internal roots.
In the config, define the hint zone like this:
zone "." {
type hint;
file "db.root";
};
That should be all you need.
Cheers, Greg
On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400 IN A 198.41.0.4
>
> b.root-servers.net. 518400 IN A 170.247.170.2
>
> c.root-servers.net. 518400 IN A 192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> 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
>
--
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
rolling my own hints file
Running Bind 9.18.18 on Ubuntu 22.04 We would like to use root servers within our organization rather than the actual root servers. I updated the hints file with the names and IPs of our servers, but we seem to still access the official root servers. Wondering how I ignore the internal/build-in hints and have my own file. Wondering if replacing the IP addresses in the db.cache file with a round-robin of my internal IP addresses isn't the answer. Not elegant but perhaps would work? Is there a supported way to do what I want to do - we do not want an forwarding only server, we do serve a good number of internal statis and dynamic zones but also want to resolve non-domain addresses or addresses we lack forwarder zones for from a 'root' source. ;; ADDITIONAL SECTION: a.root-servers.net. 518400 IN A 198.41.0.4 b.root-servers.net. 518400 IN A 170.247.170.2 c.root-servers.net. 518400 IN A 192.33.4.12 Thanks for your help and suggestions, Brian Brian Cuttler, System and Network Administration Wadsworth Center, NYS Department of Health Albany, NY 12201 POB 509 brian.cutt...@health.ny.gov<mailto:brian.cutt...@health.ny.gov> 518 486-1697 -- 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: SERVFAIL error during the evening
Hi Sami. If you can, I would set up a new BIND (test) server running the current code - 9.18.27 - next to your current production system and compare how they behave: current code uses NS queries for qmin rather than _... A queries. There may still be failures, but this would allow you to pinpoint better which domains are the problematic ones. Packet captures are always good for showing exactly what servers send and what they get back. There's no hiding in Wireshark! Cheers, Greg On Wed, 26 Jun 2024 at 07:45, wrote: > Hello > Thank you for your response. I have configured qname to disabled for now. > Once the issue is resolved, I will set it to relaxed. I have provided a > download link for the log files and a dig +trace test for more details on > this issue, which I do not think is related to BIND or its configuration. I > suspected that a firewall was blocking the DNS traffic, so I bypassed the > firewall, but the result is the same. How can we ensure that this is a > network-level issue? > > download link: > > https://we.tl/t-M77os84duE > > Regards > > Sami > > -Message d'origine- > De : bind-users De la part de > bind-users-requ...@lists.isc.org > Envoyé : mardi 25 juin 2024 13:00 > À : bind-users@lists.isc.org > Objet : bind-users Digest, Vol 4495, Issue 2 > > > -- > CAUTION : This email originated outside the company. Do not click on any > links or open attachments unless you are expecting them from the sender. > > ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez > pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre > l'expéditeur. > > ------ > > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of bind-users digest..." > > > Today's Topics: > >1. Re: SERVFAIL error during the evening (Michael Batchelder) >2. Re: qname minimization: me too :( (Stephane Bortzmeyer) >3. Re: can I provide invalid HTTPS values for testing? > (Stephane Bortzmeyer) > > > -- > > Message: 1 > Date: Tue, 25 Jun 2024 06:34:42 + (UTC) > From: Michael Batchelder > To: bind-users > Cc: sami rahal > Subject: Re: SERVFAIL error during the evening > Message-ID: <646819319.2383375.1719297282567.javamail.zim...@isc.org> > Content-Type: text/plain; charset=utf-8 > > >> Hello Michael > >> Thank you for your response. Here is a pcap file and some logs. > > > > Hello Sami, > > > > Your pcap shows your resolver making thousands of queries that get no > > responses (or at least the pcap does not contain them). There's not > > much I can say, beyond that this does not appear to be a > problem > > related to BIND. > > Sami, > > My co-worker helpfully pointed out something I missed when reviewing your > packet capture. A large number of your resolution failures are because your > BIND is configured to use QNAME minimization (a.k.a. "qmin") and the > queries are to zones whose configuration is done incorrectly and breaks > qmin. > > The pcap indicates you have the 'qname-minimization strict' setting in > your BIND configuration file. See the "qname-minimization" statement in the > Options section of the BIND ARM ( > https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage). > For the general background on qmin, read RFCs 7816 and 9156. > > I don't know of a reason why you would experience more qmin failures in > the evening, other than the requests that fail are only made at that time. > Regardless, if you want to stop the failures completely, you can change the > 'qname-minimization strict' setting to 'qname-minimization disabled'. The > drawback is that your queries will no longer be minimized, so all > authoritative servers will see the full query name during recursion. > > As a compromise between doing nothing and fully disabling qmin, you can > use the 'qname-minimization relaxed' setting which will try qmin and if > BIND encounters a z
Re: qname minimization: me too :(
On Tue, Jun 25, 2024 at 10:42 AM Stephane Bortzmeyer wrote:
> > Jun 25 16:18:31 conr named[4725]: lame-servers:
> >info: success resolving 'bar.foo.isc.org/A' after disabling
> >qname minimization due to 'ncache nxdomain'
>
> I do not see how this is possible ("success resolving") since the name
> does not exist and all ISC name servers reply it does not exist.
>
> And all the resolvers I tried (through RIPE Atlas) say the same. No
> "success resolving".
Admittedly "success" can be ambiguous, and in this case it means
successfully got an answer for the question that was originally being
pursued. In this context, a negative answer is still a successful
resolution, unlike timeout or servfail from auths or various other
failures.
--
tale
--
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 ISC BIND COPR repositories for 9.16->9.18 ESV transition
No, I haven’t run BIND on Solaris in years – this question is regarding the EPEL repos that ISC provides that can be used by CentOS and RHEL. I just mentioned Solaris because there were no binary releases back then, and to thank ISC since it’s a lot easier to install BIND from the EPEL packages rather than building from source. Brian -- Brian Sebby (he/him/his) | Lead Systems Engineer Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology Infrastructure Phone: +1 630.252.9935| Business Information Services Cell: +1 630.921.4305| Argonne National Laboratory From: Stacey Marshall Date: Friday, June 14, 2024 at 4:09 AM To: Sebby, Brian A. Cc: bind-users@lists.isc.org Subject: Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition On 14 Jun 2024, at 0: 32, Sebby, Brian A. via bind-users wrote: > I spent years having to compile BIND myself on Solaris Curious, Solaris 11. 4 provides a recent 9. 18 ESV release. Though not the monthly drops that ISC have been providing for ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd On 14 Jun 2024, at 0:32, Sebby, Brian A. via bind-users wrote: > I spent years having to compile BIND myself on Solaris Curious, Solaris 11.4 provides a recent 9.18 ESV release. Though not the monthly drops that ISC have been providing for a while, is that what you wanted? Mr. Stacey Marshall - Principal Software Engineer Oracle Global Services Limited -- 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 ISC BIND COPR repositories for 9.16->9.18 ESV transition
We’ve been using the ISC BIND 9 COPR repositories at https://copr.fedorainfracloud.org/coprs/isc/ for a few years now, but I had a question – is there a planned date to update the “bind-esv” channel to provide BIND 9.18 rather than BIND 9.16? Since 9.16 is now EOL we’ve switched to using the stable channel to get 9.18, but I just want to make sure that we switch back to the ESV channel once it provides 9.18 so we don’t accidentally switch to a new version once 9.20 becomes the new stable release. (And I do want to say thanks to ISC for providing that repo – I spent years having to compile BIND myself on Solaris, and it’s so much nicer to just install it from packages on Linux. ) Thanks, Brian -- Brian Sebby (he/him/his) | Lead Systems Engineer Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology Infrastructure Phone: +1 630.252.9935| Business Information Services Cell: +1 630.921.4305| Argonne National Laboratory -- 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
named -C, ...: Re: dnssec-policy default - where/how to determine what all its settings are?
Excellent, thanks, looks like that very well covers it (and also the "insecure" policy too). And https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs looks good ... including Suzanne Goldlust's additional suggestions too. Thanks! On Fri, Jun 7, 2024 at 1:08 AM Petr Špaček wrote: > > Hello, > > and thank you for reaching out. I agree this was poorly documented. > > In recent versions you can use command `named -C` which prints out > default configuration, including the default DNSSEC policy. > > I'm going to update documentation to reflect that: > https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs > > Petr Špaček > Internet Systems Consortium > > On 06. 06. 24 21:01, Michael Paoli via bind-users wrote: > > Ah, thanks! > > > > Yeah, that's what I was looking to find: > > https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf > > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf > > Alas, not in the ISC distribution tarballs, > > and the documentation refers to > > doc/misc/dnssec-policy.default.conf > > without indicating where to find that. > > > > On Thu, Jun 6, 2024 at 8:31 AM Andrew Latham wrote: > >> > >> I took a quick look > >> > >> * > >> https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf > >> * > >> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf > >> > >> On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users > >> wrote: > >>> > >>> dnssec-policy default - where/how to determine what all its settings are? > >>> Documentation > >>> doc/bind9-doc/arm/reference.html#dnssec-policy-default > >>> https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default > >>> says: > >>> A verbose copy of this policy may be found in the source tree, in the > >>> file doc/misc/dnssec-policy.default.conf > >>> But I'm not finding that in source nor elsewhere. > >>> There doesn't even seem to be an rndc command that can list > >>> defined dnssec-policy sets that are in place, nor that > >>> can list how they're configured. This information should be much more > >>> visible/findable, so ... where is it? I'm sure it must be present > >>> somewhere in the source, but haven't easily located it by searching. > >>> Shouldn't be necessary to run debugging to track down where this is > >>> and where in the source it comes from. So ... where does one find it? > >>> > >>> I've been looking at Debian BIND9 packages: > >>> bind9 1:9.18.24-1 > >>> bind9-doc 1:9.18.24-1 > >>> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation. > > -- > 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 -- 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: MDLZ user activation
Thanks everyone for your responses. Obviously I overlooked the most simple explanation, which turned out to be what actually occurred. In hindsight, I should have checked the mailing list archive before assuming that there was something more sinister going on. FYI Here is the original email on the mailing list archive: https://www.mail-archive.com/bind-users@lists.isc.org/msg34359.html Ged, I'll forward the email headers to you privately, but I trust you'll find that they support the explanation offered below. Thanks again everyone who took the time to respond. :-) Nick. On 07/06/2024 22:10, Marco Moock wrote: Am 07.06.2024 um 10:58:27 Uhr schrieb G.W. Haywood: On the face of your description, this sounds like a spammer who has slightly more skill than usual. The spammer simply used the name in From: after the Nick posted tothe list) (Nick Tait via bind-users) and the mail address (bind-users@lists.isc.org) as the recipient. I assume this was accidentally sent to the list and not Nick himself, but this is just a guess. I'd like to see the headers, or better the entire mail. Please feel free to send privately. They are publicly posted on the list. Message-ID: <6661e181d6fce_20e3f8fc856fcec65140...@sidekiq-frequent-fd-poduseast1-free-blue-fc47b6fff-n44lb.mail> If you need it, I can forward it to you. -- 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: Problem with a certain domain
Am 2024-06-06 18:35, schrieb Matus UHLAR - fantomas: if the problem happens again, you can call 'rndc dumpdb' to dump named's cache and see all records your named remembers about mallorcazeitung.es and epi.es perhaps they can help to explain why named can't resolve anything. Yes, it always happens when the mail is checked against the DNS block list. In the journal I can read: Jun 07 14:30:26 mx1 named[118262]: success resolving 'mallorcazeitung.es.multi.uribl.com/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:26 mx1 named[118262]: success resolving '212.132.135.159.dnsbl.sorbs.net/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving 'www-cdn-lb-tf.gslb.prensaiberica.net/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving 'caching.c354.edge2befaster.net/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving 'aec01.euc.edgetcdn.net/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving 'aec01.eug.edgetcdn.net/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving '161.237.127.79.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving '129.211.127.79.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:28 mx1 named[118262]: success resolving '209.44.199.138.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain' Jun 07 14:30:40 mx1 named[118262]: shut down hung fetch while resolving 's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/TXT' Jun 07 14:30:43 mx1 named[118262]: shut down hung fetch while resolving '_adsp._domainkey.newsletter.mallorcazeitung.es/TXT' [...] Jun 07 14:32:05 mx1 postfix/smtpd[193761]: warning: timeout talking to proxy localhost:10024 Jun 07 14:32:05 mx1 postfix/smtpd[193761]: proxy-reject: END-OF-MESSAGE: 451 4.3.0 Error: queue file write error; from= [...] Jun 07 14:32:05 mx1 postfix/cleanup[193820]: 77BB2202612: message-id= Jun 07 14:32:05 mx1 opendkim[691]: 77BB2202612: no signing table match for 'schlagzei...@newsletter.mallorcazeitung.es' Jun 07 14:32:10 mx1 opendkim[691]: 77BB2202612: key retrieval failed (s=s1, d=mg-esp-prod-eu-eu.mallorcazeitung.es): 's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es' query timed out A found an explanation for "shut down hung fetch" in your list archiv "This usually means there's a circular dependency somewhere in the resolution or validation process. For example, we can't resolve a name without looking up the address of a name server, but that lookup can't succeed until the original name is resolved. The two lookups will wait on each other for ten seconds, and then the whole query times out and issues that log message." I'm trying to work around the problem by whitelisting the address in Spamassassin so it doesn't check against the DNS blocklists. But unfortunately that doesn't work at the moment. nano /etc/spamassassin/local.cf whitelist_from_rcvd schlagzei...@newsletter.mallorcazeitung.es piano.io Spamassassin Doc "Use this (whitelist_from_rcvd) to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS. " In the header of the mail I find Received: from mgptr-132-188.piano.io (mgptr-132-188.piano.io [159.135.132.188]) [...] From: Mallorca Zeitung -- 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: MDLZ user activation
Hi list. I received the email below, which on the face of it looks pretty bogus (especially since this supposed 'list' email is personalised with my name). But the message headers show that this email was relayed to my MX server from the same MTA that relays legitimate emails from the bind-users list: Received: from lists.isc.org (lists.isc.org [149.20.2.23]) by mx.tait.net.nz (Postfix) with ESMTPS id E42DBA08D5 for; Fri, 7 Jun 2024 04:20:02 +1200 (NZST) So either the email below is valid, but if so I have no idea what it is for (and hence haven't clicked the link), or the email below is bogus and they have exploited the list MTA to distribute spam? Can anyone shed any light on this? Happy to share all the mail headers if that helps? Thanks, Nick. On 07/06/2024 04:19, gustavojavi...@gmail.com wrote: Hi Nick Tait via bind-users, A new MDLZ account has been created for you. Click the url below to activate your account and select a password! If the above URL does not work try copying and pasting it into your browser. If you continue to have problems, please feel free to contact us. Regards, MDLZ -- 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 default - where/how to determine what all its settings are?
Ah, thanks! Yeah, that's what I was looking to find: https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf Alas, not in the ISC distribution tarballs, and the documentation refers to doc/misc/dnssec-policy.default.conf without indicating where to find that. On Thu, Jun 6, 2024 at 8:31 AM Andrew Latham wrote: > > I took a quick look > > * > https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf > * > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf > > On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users > wrote: >> >> dnssec-policy default - where/how to determine what all its settings are? >> Documentation >> doc/bind9-doc/arm/reference.html#dnssec-policy-default >> https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default >> says: >> A verbose copy of this policy may be found in the source tree, in the >> file doc/misc/dnssec-policy.default.conf >> But I'm not finding that in source nor elsewhere. >> There doesn't even seem to be an rndc command that can list >> defined dnssec-policy sets that are in place, nor that >> can list how they're configured. This information should be much more >> visible/findable, so ... where is it? I'm sure it must be present >> somewhere in the source, but haven't easily located it by searching. >> Shouldn't be necessary to run debugging to track down where this is >> and where in the source it comes from. So ... where does one find it? >> >> I've been looking at Debian BIND9 packages: >> bind9 1:9.18.24-1 >> bind9-doc 1:9.18.24-1 >> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation. >> -- >> 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 > > > > -- > - Andrew "lathama" Latham - -- 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 default - where/how to determine what all its settings are?
dnssec-policy default - where/how to determine what all its settings are? Documentation doc/bind9-doc/arm/reference.html#dnssec-policy-default https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default says: A verbose copy of this policy may be found in the source tree, in the file doc/misc/dnssec-policy.default.conf But I'm not finding that in source nor elsewhere. There doesn't even seem to be an rndc command that can list defined dnssec-policy sets that are in place, nor that can list how they're configured. This information should be much more visible/findable, so ... where is it? I'm sure it must be present somewhere in the source, but haven't easily located it by searching. Shouldn't be necessary to run debugging to track down where this is and where in the source it comes from. So ... where does one find it? I've been looking at Debian BIND9 packages: bind9 1:9.18.24-1 bind9-doc 1:9.18.24-1 and also ISC BIND 9.18.24 source and 9.18.27 source and documentation. -- 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: Problem with a certain domain
Hello! Am 2024-06-04 15:28, schrieb Greg Choules: Hi Thomas. Firstly, I doubt you actually need to kill and restart `named`. Flushing the cache would probably work, either all of it or just selected names. Secondly, take a packet capture of this happening and analyse what BIND is really doing, in Wireshark. - If it shows up that certain NS are causing the problem you can avoid them, in config. - If it's a DNSSEC issue, you can get around that on a per-domain basis, if needed. - If it turns out that qname minimization is the issue, you can play with settings for that, too. In short, there are plenty of tools in the kit bag. But understand what the problem is first and to do that, gather data (pcaps and logs) that can be used to paint a picture of what's really happening. Cheers, Greg The newsletter is only sent out once a day, so I would have to wait until tomorrow. I'll record it then. I have already experimented with tshark and recorded port 53. What I noticed as a network layman is that a certain response takes much longer on server 1 with the problems than on server 2. It's the message: No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is a part of the recording of server 1 with the problem, almost a delay of 2 seconds! (tshark -w dns-mx1-l5.pcap -i eth0 -f "src port 53") [...] 6 18:35:38,719369034 216.239.32.106 213.136.83.xxx DNS 141 Standard query response 0x69ac A ns3.prensaiberica.net A 34.175.122.60 OPT 7 18:35:40,333128992 34.175.122.60 213.136.83.xxx DNS 162 Standard query response 0xf393 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:35:40,370838540 194.69.254.1 213.136.83.xxx DNS 1219 Standard query response 0xaadc DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 9 18:35:40,402465454 34.175.171.102 213.136.83.xxx DNS 165 Standard query response 0x7bfa A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is the part of the recording of server 2 (tshark -w dns-mx2-l5.pcap -i eth0 -f "src port 53") 5 18:32:03,019743724 213.4.119.2 167.86.126.xxx DNS 139 Standard query response 0x36bf A ns4.prensaiberica.net A 34.175.171.102 NS ns1.epi.es NS ns2.epi.es 6 18:32:03,052680383 194.69.254.1 167.86.126.xxx DNS 1219 Standard query response 0x5643 DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 7 18:32:03,087003657 34.175.122.60 167.86.126.xxx DNS 162 Standard query response 0x3d78 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:32:03,120746561 34.175.171.102 167.86.126.xxx DNS 165 Standard query response 0x3a41 A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es I therefore suspect that the delay will be even greater tomorrow again when the newsletter arrives, so that the "communication error" will occur again. -- 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: Problem with a certain domain
Hi Thomas. Firstly, I doubt you actually need to kill and restart `named`. Flushing the cache would probably work, either all of it or just selected names. Secondly, take a packet capture of this happening and analyse what BIND is really doing, in Wireshark. - If it shows up that certain NS are causing the problem you can avoid them, in config. - If it's a DNSSEC issue, you can get around that on a per-domain basis, if needed. - If it turns out that qname minimization is the issue, you can play with settings for that, too. In short, there are plenty of tools in the kit bag. But understand what the problem is first and to do that, gather data (pcaps and logs) that can be used to paint a picture of what's really happening. Cheers, Greg On Tue, 4 Jun 2024 at 13:01, Thomas Barth via bind-users < bind-users@lists.isc.org> wrote: > Am 2024-06-04 09:50, schrieb Matus UHLAR - fantomas: > > On 03.06.24 18:46, Thomas Barth via bind-users wrote: > >> Should I perhaps ask the mail user to unsubscribe from this website > >> due to troubles of bad configuration? > > > > > > yeah I guess you should, their DNS servers are pretty much messed up: > > A temporary solution :-) > > /etc/postfix/access-sender > newsletter.mallorcazeitung.es 550 Please configure your ns correctly > [...] > > So, what I still don't understand is why it works on one server and not > on the other. And this depends on which network the server is on? Bind > is configured the same on all my servers. Shouldn't Bind then be > confronted with the problem on all servers? How do I get a really > uniform configuration? > > > > -- > 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 > -- 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: Problem with a certain domain
Am 2024-06-04 09:50, schrieb Matus UHLAR - fantomas: On 03.06.24 18:46, Thomas Barth via bind-users wrote: Should I perhaps ask the mail user to unsubscribe from this website due to troubles of bad configuration? yeah I guess you should, their DNS servers are pretty much messed up: A temporary solution :-) /etc/postfix/access-sender newsletter.mallorcazeitung.es 550 Please configure your ns correctly [...] So, what I still don't understand is why it works on one server and not on the other. And this depends on which network the server is on? Bind is configured the same on all my servers. Shouldn't Bind then be confronted with the problem on all servers? How do I get a really uniform configuration? -- 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: Problem with a certain domain
On 4/06/2024 12:44 am, Thomas Barth via bind-users wrote: unfortunately, today I had to restart bind9 for the third time in an attempt to send a newsletter to get rid the communication error, although with a query response of 1800 msecs. Is it possible to configure bind9 so that a public DNS service (e.g. 9.9.9.9) is used for the particular domain and bind9 for everything else? Because dig @9.9.9.9 s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es always works with a good response. Hi Thomas. Yes a zone with type=forward will allow you to forward requests for a single zone to a specific recursive resolver. See: https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-type%20forward Nick. -- 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: Problem with a certain domain
Could you send the email from another account (which doesn't use your DNS server)? It's not too hard to set up a free account with services like Outlook, Yahoo or (if desperate) Gmail. On Mon, 03 Jun 2024 18:46:40 +0200 Thomas Barth via bind-users wrote: > Hello, > > I cannot send them an email to inform about a dns problem. The mail gets > stuck in the queue. > > postqueue -p > (Host or domain name not found. Name service error for name=mx.renr.es > type=A: Host not found, try again) > r...@mallorcazeitung.es > > > Bind reports a communication error. > > dig mx.renr.es > ;; communications error to 127.0.0.1#53: timed out > > I could enable the bind logging: > > 03-Jun-2024 18:34:22.681 client @0x7f014c88ed68 127.0.0.1#54496 > (mallorcazeitung.es): query: mallorcazeitung.es IN MX +E(0)K (127.0.0.1) > 03-Jun-2024 18:34:36.098 client @0x7f014ef48168 127.0.0.1#59706 > (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) > 03-Jun-2024 18:34:41.106 client @0x7f014dd71768 127.0.0.1#56423 > (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) > > Should I perhaps ask the mail user to unsubscribe from this website due > to troubles of bad configuration? -- 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: Problem with a certain domain
Hello, I cannot send them an email to inform about a dns problem. The mail gets stuck in the queue. postqueue -p (Host or domain name not found. Name service error for name=mx.renr.es type=A: Host not found, try again) r...@mallorcazeitung.es Bind reports a communication error. dig mx.renr.es ;; communications error to 127.0.0.1#53: timed out I could enable the bind logging: 03-Jun-2024 18:34:22.681 client @0x7f014c88ed68 127.0.0.1#54496 (mallorcazeitung.es): query: mallorcazeitung.es IN MX +E(0)K (127.0.0.1) 03-Jun-2024 18:34:36.098 client @0x7f014ef48168 127.0.0.1#59706 (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) 03-Jun-2024 18:34:41.106 client @0x7f014dd71768 127.0.0.1#56423 (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) Should I perhaps ask the mail user to unsubscribe from this website due to troubles of bad configuration? -- 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: Problem with a certain domain
Hello, unfortunately, today I had to restart bind9 for the third time in an attempt to send a newsletter to get rid the communication error, although with a query response of 1800 msecs. Is it possible to configure bind9 so that a public DNS service (e.g. 9.9.9.9) is used for the particular domain and bind9 for everything else? Because dig @9.9.9.9 s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es always works with a good response. -- 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
Building bind 9.19.24 on Openwrt w/ MUSL
Hi, Having some more issues building 9.19.24 on MUSL. configure.ac isn't correctly detecting the following: ac_cv_func_setresuid=yes ac_cv_type_size_t=yes ac_cv_type_ssize_t=yes ac_cv_type_uintptr_t=yes And even passing this manually via ./configure's environment isn't causing it to work... it's showing as the wrong value and not "(cached)". I wouldn't have noticed except that the included replacement for setresuid() dies in compilation with a warning about it being declared as static and then later defined as non-static or some such. Anyone else had problems with autoconf and cross-compilation w/ MUSL? I wanted to do a bump on bind to pick up this fix: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Thanks, -Philip -- 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: Problem with a certain domain
Am 2024-06-01 12:18, schrieb Rainer Duffner: intodns.com [1] [1] They have to fix this first, IMHO. And that doesn’t take into account the problems found by zonemaster. Zonemaster [2] zonemaster.net [2] [2] I wrote to the website, drew their attention to the problem and asked them to forward my request to the responsible administrators. Let's see if they will change anything. Surprisingly, the uncached queries suddenly no longer take so long. The response has now been around 100 ms several times. I am curious to see how long this will last. -- 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: Problem with a certain domain
Am 2024-06-01 04:34, schrieb Michael Batchelder:
Thomas, can you clarify whether all queries to 127.0.0.1/53 result in:
;; communications error to 127.0.0.1#53: timed out
when this problem occurs, or do just queries for
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es fail (or some level
of failure in between all queries and the ones for that one domain)?
And at that time, can you successfully query from the same system
using a public resolver (e.g. "dig @9.9.9.9
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es TXT")? And do you
have BIND's logging for the queries that fail?
I have only observed this with this mallorcazeitung domain so far.
Perhaps it has something to do with my server or the network environment
of my server host. I have another identical server, but in a different
network / on a different host system. And on the second server, the
duration of the uncached query for this domain is normal (128 msec).
Problem server 1
;; Query time: 3348 msec
Server 2
;; Query time: 128 msec
I restarted server 1, but this did not bring any improvement. But so far
it only takes so long with this mallorcazeitung domain.
I tried to activate logging (found it on a website), but the first
attempt resulted in an error. I'm a bit too exhausted now, as I've been
sitting in front of the PC all week and now need to take a break.
mkdir /var/log/named
chown bind:root /var/log/named
chmod 0750 /var/log/named
nano /etc/bind/named.conf.local
logging {
channel my_syslog {
syslog daemon;
severity notice;
};
channel my_file {
file "/var/log/named/messages";
severity info;
print-time yes;
};
category default { my_file; };
}
--
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: Problem with a certain domain
> I use bind9 on my mail server so that Spamassassin can perform the > necessary DNS blocklist queries. Since it has already happened several > times that I have to restart bind9 so that a certain domain can still > be resolved, I wanted to ask if anyone knows where I have to set > something. > > A mail user regularly receives a newsletter from Spain. But the query > to check the DKIM signature sometimes leads to a communication error, > timeout and a write error. I am then informed of these errors by > e-mail so that I can restart bind9 promptly. Because then it works > smoothly again until this problem occurs again at some point. > > Domain of DKIM-request (duration when the problem occurs 4992 msec!) > > dig s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es My go-to DNS debugging site at https://dnsviz.net/d/s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/dnssec/ appears to indicte there is more than one problem, but the most serious one is probably this one: It might look like one or more of the publishing name servers responds incorrectly when queried for an "empty non-terminal" name (e.g. _domainkey...), which probably itself doesn't have any data on that node, but has data on "names below". The correct response code is then NOERROR with answer count=0 (aka. "NODATA"), not NXDOMAIN. When a recursor gets NXDOMAIN back, it is free to assume that the queried-for name does not exist (which is obvious), and nothing exists below that node either. See RFC 8020. Regards, - Håvard -- 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: Problem with a certain domain
Sorry did not spend too much time thinking about this but if you are checking
DKIM should that be a TXT query instead of an A record?
John
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Thomas
Barth via bind-users
Sent: Friday, May 31, 2024 12:14 PM
To: bind-users@lists.isc.org
Subject: Problem with a certain domain
Hello,
I use bind9 on my mail server so that Spamassassin can perform the necessary
DNS blocklist queries. Since it has already happened several times that I have
to restart bind9 so that a certain domain can still be resolved, I wanted to
ask if anyone knows where I have to set something.
A mail user regularly receives a newsletter from Spain. But the query to check
the DKIM signature sometimes leads to a communication error, timeout and a
write error. I am then informed of these errors by e-mail so that I can restart
bind9 promptly. Because then it works smoothly again until this problem occurs
again at some point.
Domain of DKIM-request (duration when the problem occurs 4992 msec!)
dig s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; communications error to 127.0.0.1#53: timed out
; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35945 ;; flags: qr rd ra;
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 69cb0f9615955ad701006659b7dd9477fff265ac63f6 (good) ;; QUESTION
SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A
;; Query time: 4992 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri May 31 13:43:25 CEST 2024
;; MSG SIZE rcvd: 107
Then after restarting bind9 (1800 msec)
; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33426 ;; flags: qr rd ra;
QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1ce3693ff4b0e24a01006659b802511c16009f2773b0 (good) ;; QUESTION
SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A
;; AUTHORITY SECTION:
mallorcazeitung.es. 2560IN SOA ns1.epi.es.
hostmaster.mallorcazeitung.es. 1717151222 16384 2048 1048576 2560
;; Query time: 1800 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri May 31 13:44:02 CEST 2024
;; MSG SIZE rcvd: 182
1.8 seconds seems usual for this domain, no idea why, a query from the Bank of
China is faster \o/
In the Postfix journal I can read:
May 30 13:40:50 mx1 postfix/smtpd[257112]: warning: timeout talking to proxy
localhost:10024 May 30 13:40:50 mx1 postfix/smtpd[257112]: proxy-reject:
END-OF-MESSAGE:
451 4.3.0 Error: queue file write error; ...
My settings in /etc/bind/named.conf.options (Debian 12.5) are:
acl goodclients {
127.0.0.0/8;
localhost;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
//forwarders {
// 9.9.9.9;
// 149.112.112.112;
//};
//====
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//
dnssec-validation auto;
listen-on { any; };
listen-on-v6 { none; };
};
Any idea for improving the config?
And this "after disabling qname minimization due to" thing seems to slow down
the requests?
named[287800]: success resolving
's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/A' after disabling qname
minimization due to 'ncache nxdomain'
--
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
--
Visit https://lists.i
Problem with a certain domain
Hello,
I use bind9 on my mail server so that Spamassassin can perform the
necessary DNS blocklist queries. Since it has already happened several
times that I have to restart bind9 so that a certain domain can still be
resolved, I wanted to ask if anyone knows where I have to set something.
A mail user regularly receives a newsletter from Spain. But the query to
check the DKIM signature sometimes leads to a communication error,
timeout and a write error. I am then informed of these errors by e-mail
so that I can restart bind9 promptly. Because then it works smoothly
again until this problem occurs again at some point.
Domain of DKIM-request (duration when the problem occurs 4992 msec!)
dig s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; communications error to 127.0.0.1#53: timed out
; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35945
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 69cb0f9615955ad701006659b7dd9477fff265ac63f6 (good)
;; QUESTION SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A
;; Query time: 4992 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri May 31 13:43:25 CEST 2024
;; MSG SIZE rcvd: 107
Then after restarting bind9 (1800 msec)
; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33426
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1ce3693ff4b0e24a01006659b802511c16009f2773b0 (good)
;; QUESTION SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A
;; AUTHORITY SECTION:
mallorcazeitung.es. 2560 IN SOA ns1.epi.es.
hostmaster.mallorcazeitung.es. 1717151222 16384 2048 1048576 2560
;; Query time: 1800 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri May 31 13:44:02 CEST 2024
;; MSG SIZE rcvd: 182
1.8 seconds seems usual for this domain, no idea why, a query from the
Bank of China is faster \o/
In the Postfix journal I can read:
May 30 13:40:50 mx1 postfix/smtpd[257112]: warning: timeout talking to
proxy localhost:10024
May 30 13:40:50 mx1 postfix/smtpd[257112]: proxy-reject: END-OF-MESSAGE:
451 4.3.0 Error: queue file write error; ...
My settings in /etc/bind/named.conf.options (Debian 12.5) are:
acl goodclients {
127.0.0.0/8;
localhost;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
//forwarders {
// 9.9.9.9;
// 149.112.112.112;
//};
//====
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
https://www.isc.org/bind-keys
//
dnssec-validation auto;
listen-on { any; };
listen-on-v6 { none; };
};
Any idea for improving the config?
And this "after disabling qname minimization due to" thing seems to slow
down the requests?
named[287800]: success resolving
's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/A' after disabling
qname minimization due to 'ncache nxdomain'
--
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: issue with forwarder zones
Hi Brian. We're going to need some details please, like for starters: - What's the domain being queried? - A network diagram showing where your BIND server is and what it's forwarding to. - IP addresses of everything. - A packet capture (binary pcap format, not a snippet or a screenshot) from your BIND server showing both client->server and server->forwarder DNS traffic, crucially capturing the moment this issue occurs. - dig results from your making test queries. It may sound like a lot of detail, but the devil... as they say. Cheers, Greg On Wed, 29 May 2024 at 21:48, Cuttler, Brian R (HEALTH) via bind-users < bind-users@lists.isc.org> wrote: > My bad - I'd mailed this mistakenly to an individual and not the list. > > --- > > I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu. > > I am sometimes seeing that I don't have resolution for some FQDN in > forwarder zones. > > Usually it works, sometimes I don't get resolution. Interesting I failed > resolution for an FQDN yesterday and while relieved to see that I failed to > get resolution on the authoritative server I later was able to resolve on > the authoritative server but still failed on the local forwarding server. > > Wondering what is going on there. > > Conjecture - caching the failed response for some period of time? > If so, disable caching for the problematic forwarder zone? > > Some other issue? If so what might it be, how can I test for it and how do > I resolve/work-around it? > > Thanks in advance, > Brian > > > Brian R Cuttler > System and Network Administrator > Wadsworth Center, New York State Department of Health > Empire State Plaza > Corning Tower, Sublevel D-280, Albany NY 12237 > 518 486-1697 (O) > 518 redacted (C) > brian.cutt...@health.ny.gov > https://www.wadsworth.org > > > -- > 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 > -- 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
issue with forwarder zones
My bad - I'd mailed this mistakenly to an individual and not the list. --- I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu. I am sometimes seeing that I don't have resolution for some FQDN in forwarder zones. Usually it works, sometimes I don't get resolution. Interesting I failed resolution for an FQDN yesterday and while relieved to see that I failed to get resolution on the authoritative server I later was able to resolve on the authoritative server but still failed on the local forwarding server. Wondering what is going on there. Conjecture - caching the failed response for some period of time? If so, disable caching for the problematic forwarder zone? Some other issue? If so what might it be, how can I test for it and how do I resolve/work-around it? Thanks in advance, Brian Brian R Cuttler System and Network Administrator Wadsworth Center, New York State Department of Health Empire State Plaza Corning Tower, Sublevel D-280, Albany NY 12237 518 486-1697 (O) 518 redacted (C) brian.cutt...@health.ny.gov https://www.wadsworth.org -- 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: Debugging TSIG signed nsupdate problems - Specifically a logging question
In the dnssec.log file I only found references to normal key rotation. Adding the section for update_security and running at trace 99 didn't provide _any_ update_security log output, nor did it provide any extra output to the update log. even when running in single combined log format I couldn't find any messages beyond "REFUSED" It looks like the logging in the update section requires some directive I have been unable to figure out. I did find the issue with the updates, it was a typo in the object that was allowed to be updated. Not the A nor the AAA part, but the named object in the had a typo in the domain portion. my entries in the update-policy section are in the form: grant ... ; No clue why It appeared to be working before. Would be really nice to have some kind of log message, perhaps like "named object not listed in policy for ". -Erik On 5/28/24 12:48 AM, Crist Clark wrote: Have you looked in the "dnssec" logs? That may contain info about TSIG processing. Also, I didn't see the "update-security" category in your shared configuration. Not sure those have what you are looking for. You did look at the descriptions of all of the categories? https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-category OpenPGP_signature.asc 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
Re: Debugging TSIG signed nsupdate problems - Specifically a logging question
Please allow me to refocus this thread to the original question. I'm asking about the logging facility with respect to the "update" section of code in ISC's bind9 product. Yes, I understand update-policy choices/errors will generate the REFUSED response. _I'm only asking about the logging function itself._ Should the trace level of 99 generate more information in the logs for the update function than I am observing? -Erik OpenPGP_signature.asc 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
To the last windows Bind
Eagle-Eye Cherry - Save Tonight (youtube.com) <https://www.youtube.com/watch?v=Nntd2fgMUYw> -- 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: Debugging TSIG signed nsupdate problems
Hello Mark & List,
Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and
using nsupdate 9.16.27-Debian to send the updates, using rndc Version:
9.18.26.
I'm issuing commands through rndc to set the trace level to 99 -> "rndc
trace 99". rndc seems to work correctly in all other commands I've employed.
My question is limited to the proper method for turning on the debugging
logs for the "update" section of the code.
My specific question is: Will or should this turn on more verbose logs
for the update section of the code.
I'm quite willing to find my own errors in the configuration. Getting
the verbose logs to provide more than just "REFUSED" would be most
helpful and save a gdb session.
I'm not a paying customer and not expecting detailed help from ISC, only
wondering if the "rndc trace 99" should have activated the more verbose
logs.
Please pardon the reference to Fedora.
My configuration files have significant private, related, information
beyond the keys, and I would rather not post them here. I'm willing to
send them directly if you would prefer.
Here is the logging excerpt from the configuration:
logging {
channel default_file {
file "/var/log/named/single.log" versions 3 size 5m;
severity dynamic;
print-time local;
print-severity yes;
};
category default { default_file; };
};
With this single file logging configuration, all the other sections of
code produce what I expect to see from rndc trace 99.
When I use separate logs via:
logging {
channel default_file {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel general_file {
file "/var/log/named/general.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel database_file {
file "/var/log/named/database.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel security_file {
file "/var/log/named/security.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel config_file {
file "/var/log/named/config.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel resolver_file {
file "/var/log/named/resolver.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel xfer-in_file {
file "/var/log/named/xfer-in.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel xfer-out_file {
file "/var/log/named/xfer-out.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel notify_file {
file "/var/log/named/notify.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel client_file {
file "/var/log/named/client.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel unmatched_file {
file "/var/log/named/unmatched.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel queries_file {
file "/var/log/named/queries.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel network_file {
file "/var/log/named/network.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel update_file {
file "/var/log/named/update.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel dispatch_file {
file "/var/log/named/dispatch.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel dnssec_file {
file "/var/log/named/dnssec.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel lame-servers_file {
file "/var/log/named/lame-servers.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
category default { default_file; };
category general { general_file; };
category database { database_file; };
category security { security_file; };
category config { config_file; };
category resolver { resolver_file; };
category xfer-in { xfer-in_file; };
category xfer-out { xfer-out_file; };
category notify { notify_file; };
category client { client_file; };
category unmatched { unmatched_file; };
category queries { queries_file; };
category network { network_file; };
category update { update_file; };
category dispatch { dispatch_file; };
category dnssec { dnssec_file; };
category lame-servers { lame-servers_file; };
};
with 'rndc trace 9
Re: Debugging TSIG signed nsupdate problems
algorithm hmac-sha256; named-checkconf -p shows the key with the matching name, algo, and secret. When I mis-configure, change, or typo the secret it returns "BAD SECRET" The error I'm seeing is "REFUSED" on a config that worked until the upgrade. It worked on F36-F39, upgrades were seamless. Really wondering how to get debug level logs on this module. On 5/24/24 11:31 AM, John Thurston wrote: named-conf -px OpenPGP_signature.asc 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
Debugging TSIG signed nsupdate problems
How can I set debug level log for update events? I've tried "rndc trace 99" which gives *lots* of information expect for UPDATE REFUSED issues even thought the channel is set to dynamic severity. Is there a different way to get named to generate debug level logs for UPDATE events? I'm running BIND 9.18.26 (Extended Support Version) from Fedora 40. The updates and keys had been working correctly until the update to Fedora 40/BIND 9.18.26 The issues I'm experiencing are only applying to a single key & update-policy line, other TSIG's are working correctly. -Erik OpenPGP_signature.asc 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
Re: Counters for DNS transports?
> this has been planned, but unfortunately other stuff got into the way. > > It is still on our roadmap though. OK, thanks, it's reassuring that I hadn't overlooked something this time around, and it's good to see it's already thought about and on your roadmap. It's also on my wishlist, FWIW. :) Best regards, - Håvard -- 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: Counters for DNS transports?
> I frontend DoH and DoT traffic with nginx and use that for > analytics/statistics. Thanks, but I think that violates the KISS principle. Regards, - Håvard -- 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: Make dig and nslookup DNSSEC aware?
> Doesn't dig already offer DoT using +tls and DoH using +https? You're right, it does. I need to sort out my $PATH... Regards, - Håvard -- 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: Make dig and nslookup DNSSEC aware?
Doesn't dig already offer DoT using +tls and DoH using +https ? Don Friesen -Original Message- From: bind-users On Behalf Of Ondrej Surý Sent: Wednesday, May 22, 2024 8:09 AM To: Havard Eidnes Cc: bind-users@lists.isc.org Subject: Re: Make dig and nslookup DNSSEC aware? [EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender. > On 22. 5. 2024, at 17:02, Havard Eidnes via bind-users > wrote: > > And, no, I'm not aware of any such plans to incorporate a DNSSEC > validator in any of those tools. Not sure it makes technical sense, > as it's a fairly large task. That's what a validating recursive > resolver does; watch for the 'ad' flag from one such instead? delv does that: $ delv http://www.isc.org/ ; fully validated http://www.isc.org/. 300 IN CNAME isc.map.fastlydns.net. http://www.isc.org/. 300 IN RRSIG CNAME 13 3 300 20240605025251 20240522021818 27566 isc.org. SG32Y38XgzScNzN4mw0ow6mHx2Su5t8sX5jvFzbsct9obDbfnidNaOXq CuJqBDwVfg/M0 9CXJ9f2MYdI1SzYPQ== ; unsigned answer isc.map.fastlydns.net. 60 IN A 151.101.2.217 isc.map.fastlydns.net. 60 IN A 151.101.66.217 isc.map.fastlydns.net. 60 IN A 151.101.130.217 isc.map.fastlydns.net. 60 IN A 151.101.194.217 But then only dig has support for DoT and DoH. Nobody has asked for the combination yet - those are debugging tools and not something you should incorporate "as library" into other products after all. We should probably add DoT, DoH and in future DoQ to both of the tools, not just dig. And forget that nslookup ever existed, just used dig (or delv). Ondřej -- 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. -- 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 <>-- 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
Counters for DNS transports?
Hi,
I recently had reason to enable BIND 9.18.27 to do DoT and DoH
(done via unbound earlier), and it all appears to work well so
far.
I have configured
statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
inet port 8053 allow { blah; };
};
The former for collection of monitoring data using collectd, the
latter for interactive inspection.
However, I was somewhat surprised that there does not appear to
exist any stats counter couting the number of queries received
per transport, to make it possible to monitor and distinguish
between "via UDP/53", "via TCP/53" and "via TLS" or "via HTTPS".
Is this a missing feature?
I've not checked, but does perhaps BIND 9.19.x have an
improvement over 9.18 in this aspect?
Regards,
- Håvard
--
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: Make dig and nslookup DNSSEC aware?
>> Sorry if this has already been hashed through, but I cannot >> find anything in the archive. Is there any chance someone can >> make dig and nslookup DNSSEC aware and force it to use DoT or >> DoH ports - TCP 443 or 853 only? > > Not sure about that. However, the "kdig" utility from the "knot" > name server is able to do DoT and DoH (the latter only if > configured to use libnghttp2), and in my case that was the > shorter path to the goal of having a CLI tool to do DoT and DoH > testing. I should perhaps make it clear that this only answers half of the question; "kdig" isn't any more "DNSSEC aware" than "dig". And, no, I'm not aware of any such plans to incorporate a DNSSEC validator in any of those tools. Not sure it makes technical sense, as it's a fairly large task. That's what a validating recursive resolver does; watch for the 'ad' flag from one such instead? Regards, - Håvard -- 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: Make dig and nslookup DNSSEC aware?
> Sorry if this has already been hashed through, but I cannot > find anything in the archive. Is there any chance someone can > make dig and nslookup DNSSEC aware and force it to use DoT or > DoH ports - TCP 443 or 853 only? Not sure about that. However, the "kdig" utility from the "knot" name server is able to do DoT and DoH (the latter only if configured to use libnghttp2), and in my case that was the shorter path to the goal of having a CLI tool to do DoT and DoH testing. Regards, - Håvard -- 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: named fails to start with bind-9.18.0
No idea what OS or product. This is a compile, as in build the binary, or a daemon run issue? For myself I have an Ubuntu base and am running IND 9.18.x. Not locally compiled. I have found journalctl, systemctl, bind logs and /usr/bin/named-checkconf and named-checkzone to be very useful. From: bind-users On Behalf Of John Thurston Sent: Tuesday, May 21, 2024 2:15 PM To: bind-users@lists.isc.org Subject: Re: named fails to start with bind-9.18.0 ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Assurance you are actually trying to compile current code. A statement of what your operating system is. Actual output of your compile steps. Actual logged output of your attempt to launch. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov<mailto:john.thurs...@alaska.gov> Department of Administration State of Alaska On 5/20/2024 8:10 PM, avijeet gupta wrote: Please let me know if more information is needed. -- 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
RHEL, Centos, Rocky, Fedora rpm 9.18.27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZkjq8RUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsGcdACfW7MPuExfZza+zn/jNlBlDQSXg7UA nigu6WsOkIztjyHDY/KuJmx6TCEf =z8Wr -END PGP 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
Re: CIDR notation for RPZ rpz-ip ?
On 18/05/2024 09:11, J Doe wrote: Hello, When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used or must they be either: /8, /16, /24, /32 for IPv4 ? For example, if I want to block records with an A address of 192.168.10.1, I know I can write: 32.1.10.168.192.rpz-ip IN CNAME . ... and records like A, MX, etc. that have an A value of: 192.168.10.1 will receive a NXDOMAIN response. But am I able to block any CIDR ? For instance, if I wanted to block records like A, MX, etc. that have A values in: 192.168.10.1/22 can I use the following: 22.1.10.168.192.rpz-ip IN CNAME . Thanks, - J Hi J. Yes you can specify a CIDR network length that isn't on an 8-bit boundary. In your example the /22 network address for 192.168.10.1 is actually 192.168.8.0, so you'd specify: 22.0.8.168.192.rpz-ip IN CNAME . Nick. -- 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: SRV on multiple subdomains
Adding my 2p, I would take that principle a step further. Create a generic, unique SRV record that represents what you want to happen. Then create specific CNAME records for each server. The reasons for the extra, generic record are that it represents the service you want to offer and all "server.." records you want to use that service are identical in structure. e.g. imap-tcp-service.example.com. SRV _imap._tcp.server1.example.com. CNAME imap-tcp-service.example.com. _imap._tcp.server2.example.com. CNAME imap-tcp-service.example.com. ... _imap._tcp.server999.example.com. CNAME imap-tcp-service.example.com. and so on. Cheers, Greg On Thu, 16 May 2024 at 11:43, Niall O'Reilly wrote: > On 14 May 2024, at 15:20, DEMBLANS Mathieu wrote: > > A part of the subdomains are managed by us, others subdomains by an other > entity. > So we can't configure a generic target for all subdomains as each entity > has its own target for SRV entries. > > -----Message d'origine- > > De : bind-users bind-users-boun...@lists.isc.org De la part de Matus > UHLAR - fantoms > Envoyé : mardi 14 mai 2024 15:58 > À : bind-users@lists.isc.org > Objet : Re: SRV on multiple subdomains > On 14.05.24 13:08, DEMBLANS Mathieu wrote: > > I have a question about configuration simplification for SRV configuration > (maybe it can be applyed for other entries). > > We manage multiple subdomain of a main one (server1.example.com, > server2.example.com,...). > For A and MX entries, we use a general domain definitions with wildcard > but is there a way to do so for SRV without having to define all subdomains > (we have several dizains of it) ? > > We have to define some SRV entries with the same target like : > _imap._tcp.server1.example.com IN SRV main.exemple.com > _imap._tcp.server2.example.com IN SRV main.exemple.com > > Since a record is needed for each host, I think I would use something like > this: > > imap._tcp.server1.example.com. IN SRV main.example.com. > imap._tcp.server2.example.com. IN CNAME imap._tcp.server1.example.com. > ... > imap._tcp.servern.example.com. IN CNAME imap._tcp.server1.example.com. > > The advantage here is that, if ever the target of the SRV record had to > be changed, only one record would have to be updated. > > /Niall > -- > 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 > -- 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
Switching from rhel base 9.16 to 9.18 copr
Hello, I use bind (stock from alma 9.3) as a nameserver for a webhosting server with webmin/virtualmin. If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of 9.18 - I want to experiment with DoT for opportunistic TLS between nameservers, upcoming standard <https://datatracker.ietf.org/doc/rfc9539/> RFC 9539 - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (ietf.org) ) what are the necessary steps to make isc-bind read the existing config files? named.conf in /etc and zones in /var/named? will the daemon only listen to /etc/opt/isc/scls/isc-bind/named.conf? should I edit the systemctl .service file to adjust the config path? Thanks, Luca -- 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-analyzer.verisignlabs.com aaaa lookup fail
On 01.05.2024 01:33, Mark Andrews wrote: On 1 May 2024, at 03:32, Lee wrote: On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554 5.7.1 : Client host rejected: Use IPv4 For explanation: this is MY mail server, which blocks IPv6 connections from Outlook.com Gmail.com ... as these are the biggest SPAM senders Which is fine .. your server, your rules. But maybe what isn't so fine is me replying only to the list and still getting a 'rejected: Use IPv4' msg. I don't know how the mailing list works; I'm a bit surprised that I can reply only to the list, get the Client host rejected msg and somehow you can still get the msg?? there are 2 pair of shoes, mails from the list are not from Outlook.com or Gmail.com but if you put my mail address to "To: ", then its from Gmail.com ;-) This is what happens when you put something into the rejection rules which has zero relationship whether something is spam or ham. depends ... I just find it interesting that someone using mx01.ipv6help.de as a MX would be so interested in punishing IPv6 use. you are mixing up 2 independent things ... IPv6 clients aren't blocked at all, just Outlook.com, Gmail.com, ... that is the difference; just for Outlook.com the following fact is true but bullshit # host -t MX outlook.com outlook.com mail is handled by 5 outlook-com.olc.protection.outlook.com. # host outlook-com.olc.protection.outlook.com outlook-com.olc.protection.outlook.com has address 52.101.8.47 outlook-com.olc.protection.outlook.com has address 52.101.9.15 outlook-com.olc.protection.outlook.com has address 52.101.40.30 outlook-com.olc.protection.outlook.com has address 52.101.194.14 # as you see no IPv6 at all; why then the need of accepting their SPAM on IPv6 transport? smime.p7s Description: S/MIME Cryptographic 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
Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554 5.7.1 : Client host rejected: Use IPv4 For explanation: this is MY mail server, which blocks IPv6 connections from Outlook.com Gmail.com ... as these are the biggest SPAM senders smime.p7s Description: S/MIME Cryptographic 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
Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail
|Try these four | | | |fail01.dnssec.works| |fail02.dnssec.works| |fail03.dnssec.works| |fail04.dnssec.works| and then with +cd and note the difference; On 28.04.2024 08:17, Walter H. via bind-users wrote: On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 Right, the IPv4 address lookup works. Now try looking up the IPv6 address. if there was one it would be presented there see here for full answer # host one.one.one.one one.one.one.one has address 1.1.1.1 one.one.one.one has address 1.0.0.1 one.one.one.one has IPv6 address 2606:4700:4700::1001 one.one.one.one has IPv6 address 2606:4700:4700:: I get a status: SERVFAIL instead of a status: NOERROR $ dig dnssec-analyzer.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 Lee this can't be a matter of DNSSEC, as there are only signed whole zones and not just single DNS-records ... would it be a problem with just this DNS zone, why are only problems getting the IPv6? smime.p7s Description: S/MIME Cryptographic 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
[help]how to configure ecs subnet for bind-9.18-21
dear admin: now, i use bind-9.18-21, i want to use ecs client subnet function; but i don't know how to configure it, and i don't get method from google please give me some example,or document , or google links to learn about it ; thanks! Yang 395096...@qq.com-- 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-analyzer.verisignlabs.com aaaa lookup fail
On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 Right, the IPv4 address lookup works. Now try looking up the IPv6 address. if there was one it would be presented there see here for full answer # host one.one.one.one one.one.one.one has address 1.1.1.1 one.one.one.one has address 1.0.0.1 one.one.one.one has IPv6 address 2606:4700:4700::1001 one.one.one.one has IPv6 address 2606:4700:4700:: I get a status: SERVFAIL instead of a status: NOERROR $ dig dnssec-analyzer.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 Lee this can't be a matter of DNSSEC, as there are only signed whole zones and not just single DNS-records ... would it be a problem with just this DNS zone, why are only problems getting the IPv6? smime.p7s Description: S/MIME Cryptographic 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
Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail
# host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 On 27.04.2024 01:35, Lee wrote: dig dnssec-analyzer.verisignlabs.com gives me a SERVFAIL & this in the bind errors_log file: $ grep dnssec-analyzer.verisignlabs.com named-errors.log | tail -1 26-Apr-2024 19:28:37.600 query-errors: info: client @0x7f384488e3c0 127.0.0.1#47121 (dnssec-analyzer.verisignlabs.com): query failed (failure) for dnssec-analyzer.verisignlabs.com/IN/ at query.c:7471 Is that because of the insecure delegation shown at https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec/ and me having "dnssec-validation auto;" in named.conf? Thanks Lee (still struggling to understand this stuff) smime.p7s Description: S/MIME Cryptographic 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
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
> The facts are: > > * 191.131.in-addr.arpa is served from awsdns Correct. And it's delegated to from the 131.in-addr.arpa zone, maintained by ARIN. > * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com > and ns102.click-network.com above the zone cut. Correct. > * Below the zone cut the nameserver claims to be authoritative for its > parent's zone (191.131.in-addr.arpa) instead of > 85.191.131.in-addr.arpa. (In other words it's lame.) Well, yes. When queried for the NS set for 85.191.131.in-addr.arpa it returns "NOERROR" with the 191.131.in-addr.arpa SOA record in the authority section. This is what is called an "upward referral", and indicates that the delegation structure and/or child name server setup is inconsistent with the delegation structure. Were I less charitable I would say "messed up". Basically what you say above -- it doesn't serve the delegated zone so is "lame". > * (Below the zone cut it also erroneously advertises one of its > nameservers as simply ns102. instead of ns102.click-network.com) Yep. > * There is no server which actually advertises itself as authoritative > for 85.191.131.in-addr.arpa Yep. Both of the resolveable NSes ns102.click-network.com and fs838.click-network.com claim authority over 191.131.in-addr.arpa, which they don't have according to the parent zone DNS delegations. Regards, - Håvard -- 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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. couldn't get address for 'fs838.click-network.com': not found couldn't get address for 'ns102.click-network.com': not found -- 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: RFC8482: Implementation
Hi. In BIND, since 9.11, there is an option/view statement called "minimal-any", which defaults to "no". That might be what you're after. Cheers, Greg On Sat, 20 Apr 2024 at 17:29, Amaury Van Pevenaeyge < avanpevenae...@outlook.fr> wrote: > Hello everyone, > > I've been looking for days and days for a way to implement the principle > documented in RFC8482 (Providing Minimal-Sized Responses to DNS Queries > That Have QTYPE=ANY) as Cloudflare is currently doing. I can't find the > solution to do this. Can anyone help me with this? > > Thanks in advance > -- > 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 > -- 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
RHEL, Centos, Rocky, Fedora rpm 9.18.26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZiAhLBUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsH/TwCfRECCzSbMwWY4o32rzDT1X3b8kxMA nj9AgWAaoXYHW7AtfK7Ii57mrHkp =iSyg -END PGP 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
Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
On 17/04/2024 11:41, John Thurston wrote:
I'm seeing strange behavior with a BIND 9.18.24 resolver and
dnssec-failed.org.
With no dnssec-validation line (or with "dnssec-validation auto") in
the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as
expected . . until it doesn't. After several seconds of answering
SERVFAIL, I start getting NOERROR responses, and IP addresses in the
ANSWER. It isn't a predictable number of seconds; sometimes 9,
sometimes 20.
Is this supposed to be happening?
When I examine the process with delv and my eyeballs, I can't see why
it is succeeding with dig and my validating resolver.
Maybe I'm not looking for the right things with my eyeballs? I'm
stumped, and looking for advice for nest-steps in understanding what's
going on.
The following one-liner:
# rndc flush && while true; do dig -4 www.dnssec-failed.org. A
@localhost; sleep 1; done
Hi John.
FYI I tried running your command myself and didn't see the same problem.
The first thing you'd want to rule out is the possibility that you have
more than one resolver running? E.g.
sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u
The last column in the output from the command above should show a
number followed by a slash then a process name, which should be the same
on every line (e.g. "1804/named"). If it isn't, then see if you can stop
the other service(s) and then rerun your test?
If you have just a single process listening on port 53, then I'd suggest
using "tail -f" to watch your BIND logs (or syslog?) while you are
running your test, to see what is going on from the recursive resolver's
point of view? Hopefully you'll see something interesting when the
problem happens?
Nick.
--
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: Some Authoritative-Only BCPs
Hi Crist. Firstly, DNS servers do not make recursive queries, unless they have been configured to forward. Secondly, please start a packet capture on your server (save to disc, so you can analyse it later in Wireshark) then start BIND and make some test queries to your server. Look at what your server is doing as it starts and as you make queries to it. It *will* need Internet access and you should permit this in your firewall - port 53, both UDP and TCP. As for the question of DNSSEC validation - yes or no? There is more DNSSEC around these days than there used to be and choosing to NOT do validation will hurt you in future, or maybe even right now. My advice would be to enable it, look at packet captures, ask questions and understand it, rather than disable it because you don't think you need it. Cheers, Greg. On Sun, 31 Mar 2024 at 08:07, Crist Clark wrote: > Thanks so much for the response. > > This machine does not have any reasons to do recursive queries to > the Internet, and it is not allowed in the firewall. > > Looks like the article quoted is the guidance I was looking for. This > server has "notify no", AND all of the name servers are in the > authoritative > zones anyway. And it has no need to ever do DNSSEC validation. I wonder > if > the traffic I was seeing was solely due to trust anchor maintenance. If > I > turn off dnssec-validation, will that traffic go away without having to > become master for root? I'll give that a try. > > None of the other cases in the article apply. All zones are "secondary" > (except the fake root if I need to keep that). The DNSSEC arguments seem > kind of circular. You need to allow recursive behavior to support > DNSSEC, > and DNSSEC is needed to support recursive behavior. > > Interesting that you bring up the case of non-Internet root. We do have > networks like that too. The authoritative-only DNS servers there should > have analogous configuration. We shouldn't need to put that network's > root in the authoritative-only servers or enable DNSSEC... > > Although this did remind me of one reason to enable dnssec-validation > for totally non-technical reasons. Compliance. For when the auditors > come > around. It's easier to just have dnssec-validation enabled rather than > deal > with getting security exceptions or adverse findings. It's > (unfortunately) > a _really_ good reason to enable it even if it is technically > unnecessary. > > > On 2024-03-28 01:04, Greg Choules wrote: > > Hi cjc. > > My answers would be: > > > > - Leave `dnssec-validation` alone (auto) and ensure your server has a > > path > > to the Internet to make queries. > > > > - Don't mess with root hints. The only time anyone should need to do > > this > > is when running a completely captive server living in a custom > > namespace > > that is NOT the Internet. > > > > - I don't know if "none" and "!all" work out to be the same thing in > > code > > terms, but my preference would be "none" anyway because 1) that's > > what's in > > the documentation and would be the obvious choice, and 2) why > > deliberately > > create a negated expression that is harder to parse, mentally? Glancing > > through a config and seeing "...!all..." you may not notice the "!" and > > just see the "all". Even if you do see the pling, a statement > > containing it > > reads something like "I would like to permit not all", which requires > > some > > thinking about the intent. Whereas "I would like to permit none" (for > > me > > anyway) is clearer and less ambiguous. > > > > As for why authoritative servers need to make queries at all, please > > take a > > look at this article. > > > https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries > > > > Hope that helps. > > Greg > > > > On Thu, 28 Mar 2024 at 06:15, Crist Clark > > wrote: > > > >> I am upgrading and redeploying some authoritative-only BIND servers. > >> Two > >> questions about some fine points: > >> > >> What to set 'dnssec-validation'? Just let it default to 'auto?' There > >> is > >> no need or opportunity for an authoritative-only server to validate > >> (right?). Should we actively switch it off, set it to 'no?' For > >> example, > >> does setting it to 'no' reduce any resource use or reduce the security > >> vulnerability space? > >> > >> This is bordering on aesthetic (maybe the first one is too), but what > >> to > >> do abou
Re: Some Authoritative-Only BCPs
Hi cjc.
My answers would be:
- Leave `dnssec-validation` alone (auto) and ensure your server has a path
to the Internet to make queries.
- Don't mess with root hints. The only time anyone should need to do this
is when running a completely captive server living in a custom namespace
that is NOT the Internet.
- I don't know if "none" and "!all" work out to be the same thing in code
terms, but my preference would be "none" anyway because 1) that's what's in
the documentation and would be the obvious choice, and 2) why deliberately
create a negated expression that is harder to parse, mentally? Glancing
through a config and seeing "...!all..." you may not notice the "!" and
just see the "all". Even if you do see the pling, a statement containing it
reads something like "I would like to permit not all", which requires some
thinking about the intent. Whereas "I would like to permit none" (for me
anyway) is clearer and less ambiguous.
As for why authoritative servers need to make queries at all, please take a
look at this article.
https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries
Hope that helps.
Greg
On Thu, 28 Mar 2024 at 06:15, Crist Clark wrote:
> I am upgrading and redeploying some authoritative-only BIND servers. Two
> questions about some fine points:
>
> What to set 'dnssec-validation'? Just let it default to 'auto?' There is
> no need or opportunity for an authoritative-only server to validate
> (right?). Should we actively switch it off, set it to 'no?' For example,
> does setting it to 'no' reduce any resource use or reduce the security
> vulnerability space?
>
> This is bordering on aesthetic (maybe the first one is too), but what to
> do about the compiled-in root hints? Even on my authoritative-only server
> with "recursion no," every forty-five minutes or so, it's trying to go to
> the root servers and retrieve the NS and DNSKEY RRs for the root. It's
> blocked since there is no reason for this server to do outbound DNS, except
> to its hidden masters, so it just keeps trying and cluttering the firewall
> logs. What's the best way to stop this behavior? Is there a configuration
> option? I did this,
>
> zone "." {
> type primary;
> file "primary/empty-zone.db";
> allow-query { none; };
> };
>
> Which seems to do the trick, but is that the cleanest way? Any problems
> with that approach that I haven't considered?
>
> Oh, one final bonus question, is there any difference between specifying
> 'none' and '!all' in a server list, ACL, etc.? I prefer 'none', but the old
> configurations used '!all'. Can I change those without worrying?
> --
> 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
>
--
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
AW: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Jan > Schaumann via bind-users > Gesendet: Dienstag, 26. März 2024 14:44 > An: bind-users@lists.isc.org > Betreff: Re: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records > > Karl Auer wrote: > > I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone > > knows how it is handled "under the hood"? > > Many DNS service providers have some sort of variation > of this, since "aliases at the apex" is a feature many > customers need: > > Akamai uses "Zone apex mapping": > https://techdocs.akamai.com/edge-dns/docs/features#zone-apex-mapping > > Cloudflare uses "CNAME flattening": > https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames- > at-a-domains-root/ > > AWS uses "alias records": > https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record- > sets-choosing-alias-non-alias.html > ... Some more info can be found in the deprecated draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ This is for example very similar how ALIAS is implemented in PowerDNS Auth. But as there is no standard for the "CNAME-like at apex" there is no definition on how TTLs should be implemented. Regards Klaus -- 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: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records
Karl Auer wrote: > I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone > knows how it is handled "under the hood"? Many DNS service providers have some sort of variation of this, since "aliases at the apex" is a feature many customers need: Akamai uses "Zone apex mapping": https://techdocs.akamai.com/edge-dns/docs/features#zone-apex-mapping Cloudflare uses "CNAME flattening": https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ AWS uses "alias records": https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html Simplified, the authoritative performs the "CNAME" chain resolution (because it controls the zones in question) and returns the final result so the client doesn't have to chase CNAMEs. Fortunately, nowadays we have a proper solution for this problem (which -- bringing it back on-topic :-) -- bind supports): SVCB / HTTPS records (RFC9460). However, adoption of those records is still lacking, with clients behaving inconsistently and services not offering them widely yet. -Jan -- 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: transfert master slave
Hi Sami.
"allow-..." statements are to restrict from which sources *this* server
will accept messages, of whichever type.
On the secondary (slave), "allow-notify {192.168.56.154;};" will permit it
to process NOTIFY messages sent to it from the primary (master), but ignore
any others. Actually, this is not necessary because it would do that
anyway. See the ARM description for this statement -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify
NOTIFY messages from the primary will reach the secondary server and be
processed because the primary is listed in an NS record in the zone. As
Mark says, you cannot stop this. You could test sending NOTIFY from a third
server that is *not* listed as an NS for the zone.
On the primary you do not need allow-transfer {192.168.56.157;}; as the
primary is not transferring *from* the secondary.
You probably also don't need also-notify {192.168.56.157;}; if the
secondary has an NS record in the zones it will be transferring, which it
should.
Hope that helps.
Greg
On Mon, 25 Mar 2024 at 11:34, wrote:
> Hello community,
>
> I'm trying to configure a DNS slave server (192.168.56.157) . I want to
> allow notifications only from the master (192.168.56.154). I added the
> directive "allow-notify {192.168.56.154;};" and it works. However, when I
> try to test the prohibition of notification by adding "allow-notify
> {none;};" at the slave, it still receives updates from the master. The
> transfer on the master is as follows:
>
> allow-transfer {192.168.56.157;};
>
> also-notify {192.168.56.157;};
>
> notify explicit;"
>
>
>
> PS. BIND version : 9.16.48
>
>
>
> Regards Sami
>
> Orange Restricted
>
>
> --
> 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
>
--
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
RHEL, Centos, Rocky, Fedora rpm 9.18.25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZf3WuxUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsHr2gCfYw4U1U1itN4N0USVhyfg1325YjMA nRpCW3TjF6RFMPWZgReI3QC9W2pt =LxDT -END PGP 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
AW: Crafting a NOTIFY message from the command line?
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Arsen > STASIC > Gesendet: Donnerstag, 21. März 2024 08:47 > An: Petr Špaček > Cc: bind-users@lists.isc.org > Betreff: Re: Crafting a NOTIFY message from the command line? > > * Petr Špaček [2024-03-20 09:32 (+0100)]: > > On 19. 03. 24 23:10, Anand Buddhdev wrote: > > > You can try something like: > > > > > > dig +norec +opcode=notify soa @server > > > > As an alternative, script > > > https://github.com/rthalley/dnspython/blob/main/examples/send_notify.py > > allows you to specify SOA serial in the NOTIFY message as well. > > As an further alternative written in perl: > https://github.com/gbxyz/pnotify One more: $ pdns_notify Syntax: pdns_notify IP_ADDRESS/HOSTNAME[:PORT] DOMAIN (from package pdns-tools) Regards Klaus -- 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 deployement in an isolated virtual environment
Hi Amaury. You should be able to do this by defining your own trust anchors. This should explain what you need: https://bind9.readthedocs.io/en/latest/dnssec-guide.html#trusted-keys-and-managed-keys Have fun. Greg On Sat, 16 Mar 2024 at 13:38, Amaury Van Pevenaeyge < avanpevenae...@outlook.fr> wrote: > Hello I'm a student in my last year of the Master in Cybersecurity at ULB. > As part of my thesis, I'm doing research to develop a DNS Amplification > scenario that will eventually be deployed within a Cyber Range. I have to > carry out various measurements and develop different attacks in a virtual > environment. I've already been able to set up my entire environment in > VirtualBox for DNS (i.e. without DNSSEC). Now I need to deploy DNSSEC on my > server. I've managed to generate my key pairs and sign my DNS zones. > However, when I try to do a dig from my client VM, I get a SERVFAIL. I > think this is because the chain of trust can't be established, which in my > case is perfectly normal as I'm in an isolated test environment. So how can > I deploy DNSSEC correctly so that the chain of trust is not taken into > account and it works in my virtual environment? I think I know how DNSSEC > works, but if you also have any clarification to offer, I'd be delighted to > hear from you. My BIND server runs on an Ubuntu22.04 Jammy Jellyfish VM. > > Thanks in advance for your help. > -- > 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 > -- 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: opendnssec -> inline-signing
On 08/03/2024 12:54, Randy Bush wrote: but WHY NOT? same key sets with opendnssec and inline-signing, we think. The most obvious possibility is that this is referring to a different directory to where you put the keys that you wanted to use: |key-directory "/usr/home/dns/dkeys"| I couldn't help noticing that when you ran dnssec-dsfromkey you referenced this directory: /usr/home/dns/Fixed Nick. -- 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: Bind9 "split zones"
Hi
Thanks for the quick response!
Answering the last question. There are two different systems where DNS names are generated from. One is actually phpipam where we generate entries from
and the second one is a virtualization platform, where we also dig in the DB to generate entries for VM-s
As I don't think we have had issues with PTR records so not having a "fix" is
not an issue.
In the end the solution is not use one IP range for both use cases.
Taavi Ansper
taavi.ans...@cyber.ee
On 04.03.24 19:06, Greg Choules wrote:
Hi.
If I understand you correctly, you are trying to get your resolver to go to two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a single response to the client, which contains PTR records for both names?
If I got that correct, then it won't. If you want multiple PTR records to be associated with different names then they have to be in the same zone/zone
file.
A few comments:
- The statement "forward first' means, try forwarding first and only if that
fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for names delegated from that zone. e.g. if the zone is "example.com
<http://example.com>" and it contains "sub NS another.server.somewhere.else." then a query to it for "name.sub.example.com
<http://name.sub.example.com>" will follow the "forwarders" statement because "sub.example.com <http://sub.example.com>" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.
Hope that helps.
Greg
On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users mailto:bind-users@lists.isc.org>> wrote:
Hi
I am trying to understand bind9 more thorughly.
Backstory: We have been using bind9 for a long time and overhauling it
for more "usage".
We have been using a "hidden master dns" logic with views for different
usages.
E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
Hidden Master.
We had two views "external" and "internal" and now we added a new view
"dmz" aswell.
In one of those zones we had an interesting DNS "thingy" where for
example a CIDR 192.168.100.0/24 <http://192.168.100.0/24> was generating
entries to the main
"hidden dns" server via includes. It uses a domain called example.com
<http://example.com>.
Now another DNS server created DNS entries for the same CIDR
192.168.100.0/24 <http://192.168.100.0/24> but it had a different domain
"subdomain.example.com <http://subdomain.example.com>".
Including that info was easy.
In the Slave DNS
zone "example.com <http://example.com>" {
file blaah
type slave
masters { main_hidden_dns_server }
}
zone "subdomain.example.com <http://subdomain.example.com>" {
file blaah
type slave;
masters { other_dns_server }
}
But now comes the problem. When generating a PTR record
100.168.192.in-addr.arpa, I wish to combine both of these "results" into
one lookup. How can I do that? I tried to add:
zone "100.168.192.in-addr.arpa" {
file blaah
type slave;
masters { other_dns_server }
forward first;
forwarders { main_hidden_dns_server }
}
But this forwarding logic doesnt work. I have a feeling the forwarding
only works specific zones. and you can't combine two of the same
"names" into one. Am I correct and in order for PTR records to work I
need to get them into a single file?
--
Taavi Ansper
taavi.ans...@cyber.ee <mailto:taavi.ans...@cyber.ee>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users <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/
<https://www.isc.org/contact/> for more information.
bind-users mailing list
bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>
--
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: Bind9 "split zones"
Hi.
If I understand you correctly, you are trying to get your resolver to go to
two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a
single response to the client, which contains PTR records for both names?
If I got that correct, then it won't. If you want multiple PTR records to
be associated with different names then they have to be in the same
zone/zone file.
A few comments:
- The statement "forward first' means, try forwarding first and only if
that fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for
names delegated from that zone. e.g. if the zone is "example.com" and it
contains "sub NS another.server.somewhere.else." then a query to it for "
name.sub.example.com" will follow the "forwarders" statement because "
sub.example.com" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.
Hope that helps.
Greg
On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users <
bind-users@lists.isc.org> wrote:
> Hi
>
> I am trying to understand bind9 more thorughly.
>
> Backstory: We have been using bind9 for a long time and overhauling it
> for more "usage".
>
> We have been using a "hidden master dns" logic with views for different
> usages.
>
> E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
> Hidden Master.
>
> We had two views "external" and "internal" and now we added a new view
> "dmz" aswell.
>
> In one of those zones we had an interesting DNS "thingy" where for
> example a CIDR 192.168.100.0/24 was generating entries to the main
> "hidden dns" server via includes. It uses a domain called example.com.
> Now another DNS server created DNS entries for the same CIDR
> 192.168.100.0/24 but it had a different domain "subdomain.example.com".
> Including that info was easy.
>
> In the Slave DNS
>
> zone "example.com" {
> file blaah
> type slave
> masters { main_hidden_dns_server }
> }
>
> zone "subdomain.example.com" {
> file blaah
> type slave;
> masters { other_dns_server }
> }
>
> But now comes the problem. When generating a PTR record
> 100.168.192.in-addr.arpa, I wish to combine both of these "results" into
> one lookup. How can I do that? I tried to add:
>
> zone "100.168.192.in-addr.arpa" {
> file blaah
> type slave;
> masters { other_dns_server }
> forward first;
> forwarders { main_hidden_dns_server }
> }
>
> But this forwarding logic doesnt work. I have a feeling the forwarding
> only works specific zones. and you can't combine two of the same
> "names" into one. Am I correct and in order for PTR records to work I
> need to get them into a single file?
>
> --
>
> Taavi Ansper
> taavi.ans...@cyber.ee
>
> --
> 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
>
--
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
