Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1…--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 17. 4. 2024, at 19:02, John Thurston wrote:
A fresh day, and a fresh idea - I just spun up a completely new
instance of named, listening on its own port, with a stripped down
config. Now the behavior is even stranger.
I can see the "no valid signature found" line in the server log,
but my 'dig' still gets an answer. What I can see in the logs
tells me that named has determined the answer is invalid, but then
it proceeds to deliver that answer to my client. I can't figure
out why.
I feel like I am too far down into the weeds, and there is
something basic I'm overlooking. Can anyone help re-orient me?
The .conf is pretty small, and looks like:
controls {
inet 127.0.0.1 port 1953 allow {
127.0.0.1/32;
} keys {
"ns88-testPrimary-key";
};
};
options {
directory "/var/opt/testPrimary/named/data";
dump-file "cache_dump.db";
listen-on port 1053 {
127.0.0.1/32;
};
querylog yes;
dnssec-validation auto;
empty-zones-enable no;
recursion yes;
};
key "ns88-testPrimary-key" {
algorithm "hmac-sha256";
secret "";
};
When I launch it in the foreground, the output looks like:
17-Apr-2024
08:17:46.934 starting BIND 9.18.24 (Extended Support Version)
17-Apr-2024 08:17:46.934 running on Linux x86_64
5.14.0-362.18.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 29
07:05:48 EST 2024
17-Apr-2024 08:17:46.934 built with
'--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking'
'--prefix=/opt/isc/isc-bind/root/usr'
'--exec-prefix=/opt/isc/isc-bind/root/usr'
'--bindir=/opt/isc/isc-bind/root/usr/bin'
'--sbindir=/opt/isc/isc-bind/root/usr/sbin'
'--sysconfdir=/etc/opt/isc/scls/isc-bind'
'--datadir=/opt/isc/isc-bind/root/usr/share'
'--includedir=/opt/isc/isc-bind/root/usr/include'
'--libdir=/opt/isc/isc-bind/root/usr/lib64'
'--libexecdir=/opt/isc/isc-bind/root/usr/libexec'
'--localstatedir=/var/opt/isc/scls/isc-bind'
'--sharedstatedir=/var/opt/isc/scls/isc-bind/lib'
'--mandir=/opt/isc/isc-bind/root/usr/share/man'
'--infodir=/opt/isc/isc-bind/root/usr/share/info'
'--enable-warn-error' '--disable-static' '--enable-dnstap'
'--with-pic' '--with-gssapi' '--with-json-c' '--with-libxml2'
'--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS=-O2
-flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-L/opt/isc/isc-bind/root/usr/lib64' 'CPPFLAGS=
-I/opt/isc/isc-bind/root/usr/include'
'LT_SYS_LIBRARY_PATH=/usr/lib64'
'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
'SPHINX_BUILD=/builddir/build/BUILD/bind-9.18.24/sphinx/bin/sphinx-build'
17-Apr-2024 08:17:46.934 running as: named -g -4 -D testPrimary
-n 1 -u named -c /etc/opt/testPrimary/named.conf
17-Apr-2024 08:17:46.934 compiled by GCC 11.4.1 20230605 (Red
Hat 11.4.1-2)
17-Apr-2024 08:17:46.934 compiled with OpenSSL version: OpenSSL
3.0.7 1 Nov 2022
17-Apr-2024 08:17:46.934 linked to OpenSSL version: OpenSSL
3.0.7 1 Nov 2022
17-Apr-2024 08:17:46.934 compiled with libuv version: 1.44.2
17-Apr-2024 08:17:46.934 linked to libuv version: 1.44.2
17-Apr-2024 08:17:46.934 compiled with libxml2 version: 2.9.13
17-Apr-2024 08:17:46.934 linked to libxml2 version: 20913
17-Apr-2024 08:17:46.934 compiled with json-c version: 0.14
17-Ap
Re: XFR killed by security
> On 4. 3. 2024, at 14:55, Peter wrote: > > I don't find it really surprizing that XFR would contain "multiple > RRSIG entries". Unfortunately, this is obviously surprising to the vendor of the security device. This needs to be fixed there, not here. As for the CVE, you have the number that can be used, but here’s the blogpost for reference: https://www.isc.org/blogs/2024-bind-security-release/ Ondrej -- 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.-- 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: occasional SERVFAIL error
This is usually a symptom of child NS being broken. It works with empty cache because of the NS records in parent work, but then child NS take over and boom! -- 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 29. 2. 2024, at 15:20, Ludovit Koren wrote: > > I can get rid of it only after issuing: > > rndc flush -- 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
Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "sortlist" options and a value "fixed" for "rrset-order" option. These options allow to specify a on order of the resource records in the responses. The "fixed" value for "rrset-order" option will make named to record the order the records are defined in the zone file and it's disabled at the compile time because it blows up memory use. Relying on the order of the resource records in the DNS responses has been always wrong, but we are still keeping the "rrset-order" option, but please don't use it. The "sortlist" option allows to define a complicated rules when and how to reorder the resource records in the responses. The same caveats as with the "rrset-order" apply - relying on any specific order of resource records in the DNS responses is wrong. We are not aware of any other (major) DNS server that would have similar behaviour as this was never specified in the DNS protocol. If you know of any software or hardware relying on any specific order of the resource records in the DNS messages, it needs to be reported as a bug to the respective vendor. They will be deprecated as of BIND 9.20 and removed in BIND 9.22. Cheers, -- 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
Re: Problem upgrading to 9.18 - important feature being removed
> On 26. 2. 2024, at 22:41, Al Whaley wrote: > > A lot of pain and suffering in this world comes from people being sure they > have a 'better idea' and everybody needs to do whatever. This feels a bit > like that. A command that gives choice and real certainty would be great. Hi, I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. A maintainable software can't look like Katamari[1]. Yes, sometimes we have better ideas (without the quotes) and we implement them, because they make things simpler, better, more stable, faster, ... add your own. Sometimes we even break things. But ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement either in or out of BIND 9. Giving a choice is great, but then **who** will carry the costs of giving the choice? Maintaining all kind of knobs and options does come with burden and that burden might ultimately lead to a situation where all the time and resources are spent on maintaining those old features, and there's not enough left to add new improvements. For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications it has on the users, on the developers, and on the world as a whole. And it is kind of hurtful to imply that we do things just because "we know better" (paraphrasing). 1. https://en.wikipedia.org/wiki/Katamari_Damacy 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
fixed rrset ordering - is this still a thing?
Hey, BIND 9 supports a fixed rrset ordering (that is keeping the order of the RRSets from the zone file). It has to be configured at the compile time, it takes more memory (to record that order) and it's a #ifdef all over the places. So, henceforth, my question - does anyone still uses that? And if yes, what are the use cases? I think BIND is the only server that actually supports this, so it doesn't feel like the DNS can't function without it. Thanks, 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
Re: Deprecated DSCP support
How does that actually help with anything? The DNS traffic is not one way, but two way and unless everyone is setting DSCP on the DNS messages the incoming DNS messages will have same priority as incoming FTP traffic (to use your example).Ondrej--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 29. 2. 2024, at 10:00, Wolfgang Riedel via bind-users wrote:Hi Folks,OK let me help you a bit as it’s really essential for DNS traffic which need to be go through in all situations!!!Within the OS networking stack as also within the network there is always a prioritisation of packets within the queues to serialise the packets of an application to go on the wire. This prioritisation is being done based on DSCP within a L3 domain and on COS when in a L2 domain.It’s not easy for the network to guess the requirements of an application, therefore best case the application is setting the DSCP itself and the network is just trusting the DSCP or if smart enough the checking and in case of violation doing reclassification.In my case it’s dscp 24 in named.conf options but the value may be different based on deployment scenarios and therefore needs to be a configureable option.If you don't set it, it will default to 0 and all other traffic will get higher priority. Saying if you do an ftp download with large frames, your DNS request which will be running in parallel will not be making it through and either get delayed or typically drooped.Maybe have a look at the following classification scheme:<640px-IETF_Logo.svg.png>RFC 4594-Based 12-Class QoS Modelf1-consult.com —Hope that helps,Wolfgang__Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 On 28. Feb 2024, at 22:01, Petr Menšík wrote:We may want to help fixing DSCP features, but I personally do not know any usage, where this feature would be used and what for exactly. Recent bind9 uses libuv to back its network core, instead of custom networking core maintained by ISC. But I haven't found any trace of DSCP support at libuv docs [1]. I haven't found a way to set at least type of service on UDP [2].I think that would be the first place to support DSCP values for connections or sockets. Then, once libuv can use it, its support could be added back into named.It would help though if you were more verbose about why iptables cannot replace it and what is use-case, when it is useful. Without simple alternatives present. If you would describe it, it might motivate more people to work on DSCP support. I haven't seen important reason, why it needs to be done by the daemon itself. Perhaps we can find alternative way to set DSCP tags for you, if you are more verbose about how you use it?Regards,Petr1. https://docs.libuv.org/en/v1.x/search.html?q=dscp_keywords=yes=default2. https://docs.libuv.org/en/v1.x/udp.htmlOn 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:Hi,I am working on a product in Nokia, and we currently use BIND provided by Rocky Linux 8 with security patches. Recently the requirement came that we should upgrade to at least 9.16. During the testing of this version we realized that a feature we used, DSCP, has stopped working. Reading about the topic, we found the article about it non-operational in 9.16, and removal in 9.18. We also saw the email on this mailing list, stating that "so far, nobody has noticed" it is missing. Well, we noticed it just now, and I would like to state that our product and most probably other telecom equipments using BIND would miss it greatly. As I read in that mail, there was an alternative plan which would re-implement this functionality. If it is feasible, please consider doing it. The alternative options, e.g. setting it via iptables cannot work in our use-case. Best regards,Balazs Hinel-- Petr MenšíkSoftware Engineer, RHELRed Hat, http://www.redhat.com/PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Re: Problem upgrading to 9.18 - important feature being removed
Carsten, could you please fill a feature request in the GitLab? Thanks, -- 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 27. 2. 2024, at 16:06, Carsten Strotmann via bind-users > wrote: > > Hi Matthijs, > >> On 27 Feb 2024, at 15:54, Matthijs Mekking wrote: >> >> - When migrating to dnssec-policy, make sure the configuration matches your >> existing keys. > > the most problems I've seen so far have to do with this step: admins "think" > they have created a configuration that matches the current keys, but they > haven't (for one reason or other, it happens for me, despite working a lot > with DNSSEC and BIND 9). > > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would > report steps it would do because of "dnssec-policy", but will not execute the > changes. > > That way, admins can create a configuration with "dry-run" mode enabled, > check the logfiles, and if the actions in the log-file match the > expectations, the "dry-run" mode can be removed and the new configuration > will become active. > > Greetings > > Carsten > -- > 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: id.server on 9.18.24
Hey, could you run the other server manually with same configuration but on a different port and enable -d 99 on a command line? That could give some hints. -- 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 14. 2. 2024, at 10:24, Marco Davids (SIDN) via bind-users > wrote: > > I have upgraded two servers to 9.18.24 and the funny thing is that on one > server id.servers works well: > > ;; ANSWER SECTION: > id.server.0CHTXT"one" > > And on the other it does not: > > ;; AUTHORITY SECTION: > id.server.86400CHSOAid.server. hostmaster.id.server. 0 > 28800 7200 604800 86400 > > Also, the NSID-output is missing. > > I'm not sure where to look for clues as to what is actually happening, hence > I'm dropping it here to check if it is just me. > > ANY queries give: > > ;; ANSWER SECTION: > id.server.0CHTXT"xsauth" > id.server.86400CHSOAid.server. hostmaster.id.server. 0 > 28800 7200 604800 86400 > id.server.0CHNSid.server. > > and > > ;; ANSWER SECTION: > id.server.86400CHSOAid.server. hostmaster.id.server. 0 > 28800 7200 604800 86400 > id.server.0CHNSid.server. > > Other queries, like authors.bind, hostname.bind, version.bind, seem to work > fine. > > -- > Marco Davids > Research Engineer > > SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM > T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids > https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl > Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34 > -- > 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: Answers from subzone even when superzone has a delegation elsewhere
Yes, that's normal and expected. The server would not know if the zone is delegated to it or not, so it responds to queries for zones that are hosted (configured) on that server. 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. > On 13. 2. 2024, at 15:23, Andy Smith wrote: > > Hi, > > I'm running: > > 9.16.44-Debian (Extended Support Version) > > If I have zones example.com and sub.example.com both loaded, but > example.com contains a record: > > sub.example.com. NS elsewhere.example.com. > > (i.e. the subzone is delegated to some other server) > > is it normal and expected that a query for foo.sub.example.com > should be answered NXDOMAIN from the auth servers for example.com > because the zone sub.example.com is also loaded there (and has no > "foo" RR), rather than the delegation to elsewhere.example.com be > followed? > > If that is expected, is there configuration that can alter that > behaviour, or is that RFC required behaviour that should not be > altered? > > Thanks, > Andy > -- > 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
Ole Almot - banned from the list
Folks, Ole Almot has been removed from the list and banned from re-subscribing. Sorry it took so long, I wanted to give this a benefit of the doubt. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: WikiDNS 2.2.2 (Re: WikiDNS 2.1.2 (Re: Tonight I saved DNS - WikiDNS (version 1.0.0) - available with JSON records))
You both need to stop now.Ondrej--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 11. 2. 2024, at 4:44, Ole Aamot wrote: On Sun, 2024-02-11 at 01:28 +, Ole Aamot wrote: > Thanks for your insightful comments and suggestions for WikiDNS > 1.0.0. > I welcome feedback and invite you to test WikiDNS 2.1.2 The improvements are certainly comprehensive. The GPL3 licence is a very welcome choice. Excellent, I am glad you liked it. WikiDNS 2.2.2 for Python 3.12.1 with #!/usr/bin/python3, Copyright and GPL3 license included: https://folk.ntnu.no/olekaam/wikidns-client.py https://folk.ntnu.no/olekaam/wikidns-server.py https://folk.ntnu.no/olekaam/wikidns-update.py Under the circumstances, and anticipating a surge in people using it instead of BIND, perhaps it is time for you to set up a mailing list for WikiDNS? I contacted mail...@lists.isc.org with the intention to create wikidns-annou...@lists.isc.org. Sincerely, Ole Kristian Aamot Sole proprietor Aamot Engineering ole@aamot.engineering -- 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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
9.16.1 has bugs that have been fixed in more recent releases. There’s no point in trying to even start thinking what could be wrong in something old as this. It would be just a waste of time on both sides. You can do the upgrades in lockstep - first upgrade to latest 9.16 and then to latest 9.18 if that helps. Alternatively, you can bug Ubuntu to provide you with fixed packages ;). This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled. Ondrej -- 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. 2. 2024, at 21:12, Jordan Larson wrote: > > > This is/was the plan when I move to 22.04. > > I did a quick test of this (inplace upgrade to 22.04) but the slaves blew up > because I didn’t have inline-signing set to yes on the zones. I rolled my > snapshots back and figured I should sort this first. > > Is this issue easier to sort out on 9.18.x? If so I can do that but I was > attempting to sort my issues before I attempt an upgrade. > > Thanks! > Jordan > > > From: Ondřej Surý > Date: Thursday, February 8, 2024 at 2:03 PM > To: Jordan Larson > Cc: bind-users@lists.isc.org > Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - > Multiple DS keys? > > I would recommend to start with upgrading BIND (9.16.1) to a version: > - that's not 4 years old > - that's not going to be EOL in just couple of weeks > > e.g. latest 9.18.x version. > > ISC provides PPA for BIND 9.18 here: > > https://launchpad.net/~isc/+archive/ubuntu/bind > > 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. > > > On 8. 2. 2024, at 20:56, Jordan Larson via bind-users > > wrote: > > > > Greetings! > > I have what is hopefully a simple question regarding proper setup around > > DNS. I feel somewhat comfortable navigating around BIND but possibly am > > getting confused around the DNSSEC portion. > > This is for an internally facing DNS, not exposed to the internet. > > High level setup is as follows: > > We have 1 master/primary and 4 slaves/secondaries. These are running > > Ubuntu 20.04 with OS installed BIND (9.16.1). > > Any DNS updates/changes are made on the stealth master and the zones are > > propagated to the slaves and entries are added and removed. Slaves handle > > all DNS requests and forward out to google for any externally facing DNS > > requests. > > I have the dnssec-policy set to default on the master AND slaves at the > > global level via the named.conf.options. > > While reviewing the following doc > > https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it > > appeared that perhaps I was missing a critical settings for inline-signing > > set to yes for all of the zones on the slaves/secondaries. This is a recent > > addition as of a few days ago. I now have that set. > > While watching the key state and waiting for all them to go to omnipresent > > I noticed that DSState has been sitting at rumored for over 48+ hours. > > I saw this very helpful mailing list thread: > > https://lists.isc.org/pipermail/bind-users/2022-May/106182.html > > I was hopeful that after 26 hours (default settings) that this would > > eventually roll over to omnipresent. However upon reading further down in > > the first link it makes mention of the following: > > “DSState stuck in rumoured? > > If you see the DSState stuck in rumoured after the migration, you need to > > run rndc dnssec -checkds published example.com to tell BIND that the DS is > > already published in the parent zone. Be sure and confirm that the DS has > > actually been published before performing the command (see KSK rollover for > > details about checking the DS state).” > > On my hidden master: > > root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state > > ; This is the state of key 64370, for example.com. > > Algorithm: 13 > > Length: 256 > > Lifetime: 0 > > KSK: yes > > ZSK: yes > > Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) > > Published: 20231117041456 (Fri Nov 17 04:14:56 2023) > > Active: 20231117041456 (Fri Nov 17 04:14:56 2023) > > DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > > ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) > > KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > > DSChange:
Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
I would recommend to start with upgrading BIND (9.16.1) to a version: - that's not 4 years old - that's not going to be EOL in just couple of weeks e.g. latest 9.18.x version. ISC provides PPA for BIND 9.18 here: https://launchpad.net/~isc/+archive/ubuntu/bind 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. > On 8. 2. 2024, at 20:56, Jordan Larson via bind-users > wrote: > > Greetings! > I have what is hopefully a simple question regarding proper setup around > DNS. I feel somewhat comfortable navigating around BIND but possibly am > getting confused around the DNSSEC portion. > This is for an internally facing DNS, not exposed to the internet. > High level setup is as follows: > We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu > 20.04 with OS installed BIND (9.16.1). > Any DNS updates/changes are made on the stealth master and the zones are > propagated to the slaves and entries are added and removed. Slaves handle all > DNS requests and forward out to google for any externally facing DNS requests. > I have the dnssec-policy set to default on the master AND slaves at the > global level via the named.conf.options. > While reviewing the following doc > https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it > appeared that perhaps I was missing a critical settings for inline-signing > set to yes for all of the zones on the slaves/secondaries. This is a recent > addition as of a few days ago. I now have that set. > While watching the key state and waiting for all them to go to omnipresent I > noticed that DSState has been sitting at rumored for over 48+ hours. > I saw this very helpful mailing list thread: > https://lists.isc.org/pipermail/bind-users/2022-May/106182.html > I was hopeful that after 26 hours (default settings) that this would > eventually roll over to omnipresent. However upon reading further down in the > first link it makes mention of the following: > “DSState stuck in rumoured? > If you see the DSState stuck in rumoured after the migration, you need to run > rndc dnssec -checkds published example.com to tell BIND that the DS is > already published in the parent zone. Be sure and confirm that the DS has > actually been published before performing the command (see KSK rollover for > details about checking the DS state).” > On my hidden master: > root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state > ; This is the state of key 64370, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 > KSK: yes > ZSK: yes > Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) > Published: 20231117041456 (Fri Nov 17 04:14:56 2023) > Active: 20231117041456 (Fri Nov 17 04:14:56 2023) > DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) > KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) > DNSKEYState: omnipresent > ZRRSIGState: omnipresent > KRRSIGState: omnipresent > DSState: omnipresent > GoalState: omnipresent > Slaves can query the master (nothing else can and recursion is also off). If > I do a check for the key, I can see it here: > root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline > ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018 > ;; 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: 4096 > ; COOKIE: 766c81fa38f5d458010065c52a97cbca37018dd97375 (good) > ;; QUESTION SECTION: > ;example.com. IN DNSKEY > ;; ANSWER SECTION: > example.com.3600 IN DNSKEY 257 3 13 ( > > rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy > > MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg== > ) ; KSK; alg > = ECDSAP256SHA256 ; key id = 64370 > ;; Query time: 0 msec > ;; SERVER: 10.0.0.20#53(10.4.2.36) > ;; WHEN: Thu Feb 08 19:25:11 UTC 2024 > ;; MSG SIZE rcvd: 152 > Since I enabled inline-signing on my slaves I also have a key there now: > root@slave1:~# cat /var/cache/bind/Kexample.com.+013+12698.state > ; This is the state of key 12698, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 &
Re: Non-improving referral
You gave us no details, so we can’t really help you unless you give us more details about what you are trying to achieve and what’s the current architecture.If you want community help you need to be as descriptive as possible, so we don’t have to guess.Ondrej--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 4. 2. 2024, at 12:13, Gabi Nakibly wrote:Thanks for the response. However, I strongly prefer not to update the parent zone as this is only a temporary nameserver for testing purposes. Is there anyway to add a new name server (with a new name) without updating the parent zone?On Sun, Feb 4, 2024, 12:01 Mark Andrews <ma...@isc.org> wrote:You have your answer. Update the parent zone. -- Mark AndrewsOn 4 Feb 2024, at 18:27, Gabi Nakibly <gabin...@gmail.com> wrote:Hi,I would like to set up a new temporary nameserver for my zone (say 'example.com'), however for various reasons I prefer not to change the delegation of my parent zone ('.com'). So I need the current name server ('ns.example.com') to refer resolvers to my new temporary name server ('ns-temp.example.com'). However, when I tried to test this set-up with a BIND resolver, when the resolver got the delegation to the temporary name server it failed with 'non-improving referral'. How can I resolve this so the delegation will work for a BIND resolver having default config (or with any other resolver for that matter)? I know that I can simply update delegation at the parent zone to point directly to the new name server, but I prefer not to do this right now and I am looking for ways to do this without changing the parent delegation.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: Support for clang atomic and gcc __sync builtins
Hi Sharada, To answer your question: Because C11 that includes stdatomic is 13 years old now, and we want the BIND 9 code base to be modernized. You can’t expect the C codebases to be stuck in the past. You can always provide your own stdatomic.h shims or even stdatomic.h implementation, you know your legacy platforms better than us. Nothing is stopping you. But it’s you (the legacy platform backed up by large corporation) who should carry the costs, not us (the open source with limited resources). Ondrej -- 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 31. 1. 2024, at 19:15, Sharada N Allimatti wrote: > > We would like to know why only the _atomic builtins for GCC >=4 are supported > from bind 9.18 onwards. -- 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: secure statistics page
Hi, put a real webserver in front of it. Both Apache and Nginx can work as proxy. Ondrej -- 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 18. 1. 2024, at 15:12, Eric Dewitte wrote: > > > Hello, > I'm looking for help here because I haven't found any information in the > documentation (or I haven't). > > I've activated Bind's statistics, to test I've set port 8080. > So I can make http requests on port 8080, it works. > > but i'd like to secure the page, is it possible to switch to https and > therefore use an SSL certificate? > > Thank you for your help. > > OS: Debian 12, BIND: 9.18 > -- > 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: [Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
No, 9.16 is already in the “security or critical bugfixes only” for two years (or so). This is a very minor issue on platform that’s being obsoleted. Sorry. Ondrej -- 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. 1. 2024, at 18:42, Gentry Deng via bind-users > wrote: > > I noticed that version 9.16 is about to be EOL. I wonder if this BUG can be > fixed before EOL? After all, this is the only version of BIND 9 that still > supports the Windows platform. -- 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: Unable to Query DoH with `tls none` and Plain HTTP
> On 2. 1. 2024, at 10:38, Jakob Bohm via bind-users > wrote: > > Funny, given that HTTP/2 (the spec) had a CVE against it last October, > while HTTP/0.9 and HTTP/1.x did not. I’ve said that a single modern HTTP/2 implementation (backed by maintained library) is much better than having two different implementations of HTTP protocol that need to cooperate on a single port. You came with vulnerability in the HTTP/2 specification. So, what’s your point? Or you were just trying to be “funny”? > Having the DoH server as a standalone process talking to DNS/TCP would > be a solid implementation given the constant flow of changes made to > HTTP(S) by the Big 5. Sure, but most people don’t want to integrate different programs to talk to each other and having an all-in-one solution works for most people. For the rest, there’s always something like dnsdist that can actually talk DoH on external side and Do53 on the internal side. From a maintainers perspective, I would love to have a minimal DNS implementation with as few features, because that’s easier to maintain. But we are not building BIND 9 for just our own needs, we are building it for the users regardless what I personally think about DoH/2, DoH/3 or DoQ and whatever the Big Tech comes next to shave a nanosecond from the latency and pushes onto the open source developers who are limited on resources and maintain software that has long history… Ondrej -- 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. -- 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: Unable to Query DoH with `tls none` and Plain HTTP
> On 1. 1. 2024, at 15:19, r1wcp...@bbqporkmccity.com wrote: > > Thank you very much, I was unaware of the HTTP/2 requirement and was assuming > it is a bug. Is there any reason for omitting the HTTP/1.1 upgrade part of > the protocol? It would be additional complexity that's really not needed. The HTTP/2 library (libnghttp) doesn't provide HTTP/1.1 implementation, so we would have to bolt something own for a little gain. And it would increase an attack surface as it would be yet another protocol open to the world that can have bugs in it. 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
Re: Unable to Query DoH with `tls none` and Plain HTTP
Hi,
BIND 9 DoH implementation always uses HTTP/2, so you
can't talk to it via HTTP/0.9, so your proxy balancer needs
to talk HTTP/2.
curl --http2-prior-knowledge -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
should work if I am reading the curl man page correctly (I don't have bind with
doh no-tls here)
dig +http-plain @172.23.0.2
will definitely work.
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.
> On 1. 1. 2024, at 13:35, r1wcp42w--- via bind-users
> wrote:
>
> Hello,
>
> Hope you are having a great day.
>
> I am trying to setup a BIND9 DNS over HTTP (DoH but in plain HTTP) server
> with the ubuntu/bind9:latest docker image behind a HTTPS load balancer
> however I am unable to perform any DNS query with the newly installed BIND9
> server(not through the load balancer).
>
> I am getting the following when I try to perform the query:
>
>
>> ➜ curl -v -H 'accept: application/dns-message'
>> 'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
>> * Trying 172.23.0.2:80...
>> * Connected to 172.23.0.2 (172.23.0.2) port 80
>>> GET /dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1
>>> Host: 172.23.0.2
>>> User-Agent: curl/8.5.0
>>> accept: application/dns-message
>> * Received HTTP/0.9 when not allowed
>> * Closing connection
>> curl: (1) Received HTTP/0.9 when not allowed
>
>
>
> and here is my named.conf.options
>
>> options {
>>directory "/var/cache/bind";
>>// 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://psrp.bbqporkmccity.com/vye5rn/iw5hSZ1O
>>// 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 {
>>// 0.0.0.0;
>>// };
>>
>> //
>>// If BIND logs error messages about the root key being expired,
>>// you will need to update your keys. See
>> http://psrp.bbqporkmccity.com/vye5rn/nH13n27l
>>
>> //
>>dnssec-validation auto;
>>listen-on-v6 { any; };
>>// Custom Options From Here
>>allow-query { any;};
>>allow-transfer { none; };
>>listen-on port 53 { any; };
>>listen-on port 80 tls none http default { any; };
>> };
>
> Am I doing something wrong?
>
> Thank you very much and I am looking forward to a solution.
> --
> 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: Problems with openssl pkgconfig in bind 9.18.21 (but probably all 9.18) {External}
This is what I use for my ThreadSanitizer enabled builds. DON'T USE IT
VERBATIM! (It enables ThreadSanitizer and disables optimizations, etc...)
TL;DR The part you want is -Wl,-rpath=$PREFIX/lib
If that doesn't work, experiment with -Wl,--enable-new-dtags vs
-Wl,--disable-new-dtags (see here for explanation:
https://stackoverflow.com/questions/52018092/how-to-set-rpath-and-runpath-with-gcc-ld)
Also there's always an option to add the paths where you installed the updated
libraries to /etc/ld.so.conf (or to /etc/ld.so.conf.d/local.conf).
Cheers,
Ondřej
$ cat tsan-env
#!/bin/sh
export CC="${CC:-clang-18}"
export PREFIX="$HOME/.tsan-${CC}"
case "$CC" in
clang-*) export CXX=clang++-${CC#clang-} ;;
gcc-*) export CXX=g++-${CC#gcc-} ;;
*) exit 1 ;;
esac
export CFLAGS="$CFLAGS -rdynamic -ggdb -O0 -Wno-deprecated-declarations
-fno-omit-frame-pointer -fno-optimize-sibling-calls -fPIC -fsanitize=thread
-Wl,-rpath=$PREFIX/lib -Wl,--enable-new-dtags"
export CXXFLAGS="$CXXFLAGS -rdynamic -ggdb -O0 -Wno-deprecated-declarations
-fno-omit-frame-pointer -fno-optimize-sibling-calls -fPIC -fsanitize=thread
-Wl,-rpath=$PREFIX/lib -Wl,--enable-new-dtags"
export LDFLAGS="$LDFLAGS -fPIE -fsanitize=thread -Wl,-rpath=$PREFIX/lib
-Wl,--enable-new-dtags"
export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH"
export PATH="$PREFIX/sbin:$PREFIX/bin:$PATH"
$ cat build
#!/bin/sh
. ./tsan-env
rm -rf "$PREFIX"
# OpenSSL (skip, it takes too long)
#./config no-asm no-ssl3 no-comp no-weak-ssl-ciphers --prefix="$PREFIX"
&& \
(cd openssl && \
git clean -xdf && \
git reset --hard HEAD && \
./config no-ssl3 no-weak-ssl-ciphers --prefix="$PREFIX"
--libdir="$PREFIX/lib" && \
make -j && \
make install_sw)
# libuv
(cd libuv && \
git clean -xdf && \
git reset --hard HEAD && \
./autogen.sh && \
./configure --prefix="$PREFIX" && \
make -j && \
make install
)
# userspace-rcu
(cd userspace-rcu && \
git clean -xdf && \
git reset --hard HEAD && \
./bootstrap && \
./configure --prefix="$PREFIX" --enable-compiler-atomic-builtins
--disable-legacy-mb && \
make -j && \
make install
)
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 22. 12. 2023, at 16:44, William D. Colburn wrote:
>
> Your build system did say to manually change it. I used an environment
> variable, but thought (still think actually) that yhour build system
> should honor pkgconfig for finding packages.
--
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: Problems with openssl pkgconfig in bind 9.18.21 (but probably all 9.18) {External}
Please keep Cc when responding to a message from the mailing list. Re-added, but redacted most of your email. No, you missed my point - I asked why do you pretend to run stuff on RHEL 6 while in fact you do not because all the critical libraries are self-compiled. You can run BIND 9 in a container (on RHEL 6) using a still-maintained distribution, where you don’t have to self-watch the required upgrades for all the dependencies (libuv, OpenSSL, and others…) Ondrej -- 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 22. 12. 2023, at 16:50, William D. Colburn wrote: > RHEL6.10 is pretty new in the grand scheme of things. -- 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: Problems with openssl pkgconfig in bind 9.18.21 (but probably all 9.18)
You need to use rpath to build the libraries that are not in the places where dynamic linker can find them. This will solve your issue. But RHEL 6? What’s the point of pretending you are running on old system when everything you run is new? Ondrej -- 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 22. 12. 2023, at 16:14, William D. Colburn wrote: > > I'm compiling bind 9.18.21 on RHEL 6.10. I had to make my own libuv and > openssl packages (and I still need a jemalloc package). I told bind > about them via the PKG_CONFIG_PATH variable, which mostly works. The > problem is in bind-9.18.21/doc/misc which doesn't seem to receive any > information from the build system about the location of where openssl > is. I got around it by adding an LD_LIBRARY_PATH= to the initial make > command that pointed into where I had installed openssl 3.2.0, but that's a > little fragile. It also means I don't know if doc/misc is the only > place with this problem. > > And no, I can't just upgrade the computer. But we did manage to > decomission a vendor bind on a Sun workstation in a jungle on an island > in the Pacific ocean a couple of months ago, so you can take some joy > from that. :) > > I never what or how much information to send and I always get it wrong, > so I'll just wait for Ondrej (I have no idea how to type that correctly) > to chastise me and then forward on whatever else you need. Also :) > > --Schlake > Sysadmin IV, NRAO > Work: 575-835-7281 (BACK IN THE OFFICE!) > Cell: 575-517-5668 (out of work 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
Re: version errata Re: Remove PDF-related bits from the build system
I am missing your point. The documentation is readily available from both the RTD and the FTP along with the source tarballs.The sources are in Sphinx doc format, so everyone can modify and build in whatever output format sphinx-build provides: https://www.sphinx-doc.org/en/master/man/sphinx-build.htmlAre you really complaining about the lack of handholding because you want to build the documentation yourself and just can’t download it? Because it really seems like the case here.Ondrej--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 21. 12. 2023, at 21:32, Fred Morris wrote:
Just pulled the 9.18.21 tarball and checked, same thing.
m3047@sophia:/opt/downloads/bind-9.18.21> grep -B18 '> Change log' README.md
### Documentation
The *BIND 9 Administrator Reference Manual* (ARM) is included with the source
distribution, and in .rst format, in the `doc/arm`
directory. HTML and PDF versions are automatically generated and can
be viewed at [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html).
Man pages for some of the programs in the BIND 9 distribution
are also included in the BIND ARM.
Frequently (and not-so-frequently) asked questions and their answers
can be found in the ISC Knowledgebase at
[https://kb.isc.org](https://kb.isc.org).
Additional information on various subjects can be found in other
`README` files throughout the source tree.
### Change log
m3047@sophia:/opt/downloads/bind-9.18.21> sum README.md
3778511
m3047@sophia:/opt/downloads/bind-9.18.21> md5sum README.md
c4e08add5a135ce2573483eb0e5b1207 README.md
m3047@sophia:/opt/downloads/bind-9.18.21> sha256sum README.md
080e914decc2ed554d8887b0f719b82736c45380b987f23b3eba4ef7418f03f3 README.md
On 12/21/23 12:24 PM, Fred Morris
wrote:
No, I was correct the first time, but I had the wrong version.
It is a 9.18.9 tarball, not 9.18.21. Checksums are correct for
that README.md.
On 12/21/23 12:18 PM, Fred Morris
wrote:
I'm sorry 9.18.9 was the version where I discovered that the
build didn't build the PDF, and all it says is
### Building BIND 9
For information about building BIND 9, see the
["Building BIND 9"](doc/arm/build.inc.rst) section in the
BIND 9
Administrator Reference Manual.
The checksums correct for that
version of README.md.
I think I must have mistakenly cut
& pasted from the source tree in GitLab for 9.18.
On 12/21/23 10:50 AM, Fred Morris
wrote:
On 12/21/23 10:08 AM, Ondřej Surý wrote:
In the commit you referenced:
https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147
On 21. 12. 2023, at 18:59, Fred Morris wrote:
According to the commit
(https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4)
Not sure how this works, but I'm looking at what came out of the 9.18.21
tarball and it doesn't build the PDF, and neither does README.md contain
the build instructions:
### Documentation
The *BIND 9 Administrator Reference Manual* (ARM) is included with
the source
distribution, and in .rst format, in the `doc/arm`
directory. HTML and PDF versions are automatically generated and can
be viewed at
[https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html).
Man pages for some of the programs in the BIND 9 distribution
are also included in the BIND ARM.
Frequently (and not-so-frequently) asked questions and their answers
can be found in the ISC Knowledgebase at
[https://kb.isc.org](https://kb.isc.org).
Additional information on various subjects can be found in other
`README` files throughout the source tree.
# sum README.md 30538 11 README.md # md5sum README.md
4b7916a768467c54d1d1f0fd96cff505 README.md # sha256sum README.md
ed0a9280fe2f1d1fd6616f95184c6901709e79897b22205e5200bf1f5a7b1bea README.md
--
Fred Morris
**PerlJacket** deleted text/html part.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users--
Visit https://lists.isc.org/mailman/listinfo/b
Re: Remove PDF-related bits from the build system
In the commit you referenced: https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147 -- 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 21. 12. 2023, at 18:59, Fred Morris wrote: > > (Intentionally posting to the mailing list with that string since that > was the commit message where it occurred. Hopefully this will improve > findability.) > > So, yeah. > > I'll take your word for it that Read The Docs can generate PDFs. I'd > appreciate your promise that it generated the version of the doc which > is here: https://downloads.isc.org/isc/bind9/9.18.21/doc/arm/Bv9ARM.pdf > We could talk about the difference in presentation between the HTML and > PDF versions, but it's a matter of taste. > > Is this free, and where are the instructions? > > According to the commit > (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) > you removed "PDF-related bits" from not just the build system, but from > the documentation itself! You removed the instructions that are in the > commit message itself! If your intention was to remove it from the build > system, you went too far. > > I looked for this just the other day in the KB. At the least you should > have a KB article. At least there's this post to the mailing list. > > -- > > Fred Morris > > > -- > 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: unable-resolve-bank=domain
> On 17. 12. 2023, at 8:20, MEjaz via bind-users > wrote: > > Any hint would be highly appreciated.. Paraphrasing: Logs or it didn’t happen… Always start with logs. The dig output is useless as we can’t possibly know what is happening inside named on that server. Ondrej -- 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. -- 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-keyfromlabel not working with Debian 12 (bookworm)
I've added a warning to the KB article now. Thanks for reporting this. -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 4. 12. 2023, at 14:45, Gérard Parat via bind-users > wrote: > > Hi, > > I'll follow your advice ans postpone the use of SoftHSM2 for the time being. > > Anyway, thanks for your help! > > Gérard > > Le 04/12/2023 à 14:31, Ondřej Surý a écrit : >> Hi, >> >> the guide was written for OpenSSL 1.1.x and tested with that version >> and the engines support in OpenSSL 3.x is deprecated, so most probably >> something got broken along the way. >> >> Everything works properly with OpenSSL 1.1.x (for example on Ubuntu focal). >> >> There's a new provider for OpenSSL 3.x here: >> https://github.com/latchset/pkcs11-provider >> >> The catch is that OpenSSL Provider can't really be used with SoftHSM 2, >> because that SoftHSM2 is itself broken when used with providers: >> https://github.com/latchset/pkcs11-provider/discussions/68#discussioncomment-3860124 >> >> You can try using /usr/lib/x86_64-linux-gnu/libsoftokn3.so >> <http://libsoftokn3.so/> from libnss3 as PKCS#11 library >> instead of SoftHSM2, but unless you have a specific reason to use PKCS#11 I >> would >> suggest to simply avoid it until the dust settles. >> >> Adding SoftHSM2 on top of BIND 9 doesn't really increase security as the >> user under named >> runs has to have access to the private key data anyway. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >> >>> On 4. 12. 2023, at 0:43, Gérard Parat via bind-users >>> wrote: >>> >>> Hi, >>> >>> Weird behavior with /opt/bind9/etc/openssl.cnf. >>> >>> The only difference with /etc/ssl/openssl.cnf is the pkcs11 engine: >>> >>> [openssl_init] >>> >>> engines=engine_section >>> >>> [engine_section] >>> >>> pkcs11 = pkcs11_section >>> >>> [pkcs11_section] >>> >>> engine_id = pkcs11 >>> >>> dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so >>> >>> MODULE_PATH = /usr/lib/softhsm/libsofthsm2.so >>> >>> init = 0 >>> >>> For example, dig is not working with environment variable OPENSSL_CONF: >>> >>> $ dig www.internet.nl +short >>> 04-Dec-2023 00:39:24.280 EVP_PKEY_fromdata_init failed (crypto failure) >>> 04-Dec-2023 00:39:24.280 error:0396:digital envelope >>> routines::operation not supported for this >>> keytype:../crypto/evp/pmeth_gn.c:354: >>> dig: dst_lib_init: crypto failure >>> >>> It works if OPENSSL_CONF is undefined: >>> >>> $ OPENSSL_CONF= dig www.internet.nl +short >>> proloprod.internet.nl. >>> 62.204.66.10 >>> >>> Issue seems wider than only relative to dnssec-keyfromlabel. >>> >>> Gérard >>> >>> Le 03/12/2023 à 18:40, Gérard Parat via bind-users a écrit : >>>> Hi, >>>> >>>> I used this tutorial as reference to setup DNSSEC with SoftHSM2: >>>> https://kb.isc.org/docs/bind-9-pkcs11 >>>> >>>> I installed the Debian package instead of building libp11: >>>> libengine-pkcs11-openssl:amd640.4.12-0.1 >>>> >>>> It works until reaching this command: >>>> $ dnssec-keyfromlabel \ >>>> -E pkcs11 \ >>>> -a RSASHA256 \ >>>> -l "token=bind9object=example.net-ksk" \ >>>> -f KSK example.net >>>> dnssec-keyfromlabel: fatal: could not initialize dst: crypto failure >>>> >>>> Trying directly from OpenSSL works: >>>> $ openssl pkey \ >>>> -in "pkcs11:token=bind9;object=example.net-ksk" \ >>>> -inform ENGINE \ >>>> -engine pkcs11 \ >>>> -text \ >>>> -pubin >>>> Engine "pkcs11" set. >>>> -BEGIN PUBLIC KEY- >>>> MIG/MA0GCSqGSIb3DQEBAQUAA4GtADCBqQKBoQCmhO41MX09L/BiJiU7ygXt6D7J >>>> ujmZFMBB7tb/LJBazNp+Xd5TLHZvp1MxFBBW39swTU6oynLnp8IOIuWQNap6kyQ5 >>>> hkGusvZ/JsrwHLZ1phPBKsdEd2ClB9EfF+ReabhXRVbqrw9yz22mLdlajmkLTx2d >>>> V6EsjJu
Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)
Hi, the guide was written for OpenSSL 1.1.x and tested with that version and the engines support in OpenSSL 3.x is deprecated, so most probably something got broken along the way. Everything works properly with OpenSSL 1.1.x (for example on Ubuntu focal). There's a new provider for OpenSSL 3.x here: https://github.com/latchset/pkcs11-provider The catch is that OpenSSL Provider can't really be used with SoftHSM 2, because that SoftHSM2 is itself broken when used with providers: https://github.com/latchset/pkcs11-provider/discussions/68#discussioncomment-3860124 You can try using /usr/lib/x86_64-linux-gnu/libsoftokn3.so <http://libsoftokn3.so/> from libnss3 as PKCS#11 library instead of SoftHSM2, but unless you have a specific reason to use PKCS#11 I would suggest to simply avoid it until the dust settles. Adding SoftHSM2 on top of BIND 9 doesn't really increase security as the user under named runs has to have access to the private key data anyway. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 4. 12. 2023, at 0:43, Gérard Parat via bind-users > wrote: > > Hi, > > Weird behavior with /opt/bind9/etc/openssl.cnf. > > The only difference with /etc/ssl/openssl.cnf is the pkcs11 engine: > > [openssl_init] > > engines=engine_section > > [engine_section] > > pkcs11 = pkcs11_section > > [pkcs11_section] > > engine_id = pkcs11 > > dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so > > MODULE_PATH = /usr/lib/softhsm/libsofthsm2.so > > init = 0 > > For example, dig is not working with environment variable OPENSSL_CONF: > > $ dig www.internet.nl +short > 04-Dec-2023 00:39:24.280 EVP_PKEY_fromdata_init failed (crypto failure) > 04-Dec-2023 00:39:24.280 error:0396:digital envelope routines::operation > not supported for this keytype:../crypto/evp/pmeth_gn.c:354: > dig: dst_lib_init: crypto failure > > It works if OPENSSL_CONF is undefined: > > $ OPENSSL_CONF= dig www.internet.nl +short > proloprod.internet.nl. > 62.204.66.10 > > Issue seems wider than only relative to dnssec-keyfromlabel. > > Gérard > > Le 03/12/2023 à 18:40, Gérard Parat via bind-users a écrit : >> Hi, >> >> I used this tutorial as reference to setup DNSSEC with SoftHSM2: >> https://kb.isc.org/docs/bind-9-pkcs11 >> >> I installed the Debian package instead of building libp11: >> libengine-pkcs11-openssl:amd640.4.12-0.1 >> >> It works until reaching this command: >> $ dnssec-keyfromlabel \ >> -E pkcs11 \ >> -a RSASHA256 \ >> -l "token=bind9object=example.net-ksk" \ >> -f KSK example.net >> dnssec-keyfromlabel: fatal: could not initialize dst: crypto failure >> >> Trying directly from OpenSSL works: >> $ openssl pkey \ >> -in "pkcs11:token=bind9;object=example.net-ksk" \ >> -inform ENGINE \ >> -engine pkcs11 \ >> -text \ >> -pubin >> Engine "pkcs11" set. >> -BEGIN PUBLIC KEY- >> MIG/MA0GCSqGSIb3DQEBAQUAA4GtADCBqQKBoQCmhO41MX09L/BiJiU7ygXt6D7J >> ujmZFMBB7tb/LJBazNp+Xd5TLHZvp1MxFBBW39swTU6oynLnp8IOIuWQNap6kyQ5 >> hkGusvZ/JsrwHLZ1phPBKsdEd2ClB9EfF+ReabhXRVbqrw9yz22mLdlajmkLTx2d >> V6EsjJue+aSX1nxFmna6qNrZBA5ifClpKH7R/0ztQb1RlYA11RG1RGrsRSJnAgMB >> AAE= >> -END PUBLIC KEY- >> RSA Public-Key: (1280 bit) >> Modulus: >> 00:a6:84:ee:35:31:7d:3d:2f:f0:62:26:25:3b:ca: >> 05:ed:e8:3e:c9:ba:39:99:14:c0:41:ee:d6:ff:2c: >> 90:5a:cc:da:7e:5d:de:53:2c:76:6f:a7:53:31:14: >> 10:56:df:db:30:4d:4e:a8:ca:72:e7:a7:c2:0e:22: >> e5:90:35:aa:7a:93:24:39:86:41:ae:b2:f6:7f:26: >> ca:f0:1c:b6:75:a6:13:c1:2a:c7:44:77:60:a5:07: >> d1:1f:17:e4:5e:69:b8:57:45:56:ea:af:0f:72:cf: >> 6d:a6:2d:d9:5a:8e:69:0b:4f:1d:9d:57:a1:2c:8c: >> 9b:9e:f9:a4:97:d6:7c:45:9a:76:ba:a8:da:d9:04: >> 0e:62:7c:29:69:28:7e:d1:ff:4c:ed:41:bd:51:95: >> 80:35:d5:11:b5:44:6a:ec:45:22:67 >> Exponent: 65537 (0x10001) >> >> Debian 12 (bookworm) use OpenSSL version 3: >> libssl3:amd64 3.0.11-1~deb12u2 >> openssl 3.0.11-1~deb12u2 >> >> Installed BIND9 packages: >> bind9 1:9.18.19-1~deb12u1 >> bind9-utils 1:9.18.19-1~deb12u1 >> bind9-dnsutils1:9.18.19-1~deb12u1 >> bind9-doc 1:9.18.19-1~deb12u1 >> bind9-libs:amd64 1:9.18.19-1~deb12u1 >> bind9-host1
Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)
Hi, I directly see missing semicolon in the failed command. Please provide full unedited log, so we can be sure that the error was not made when redacting the output. Ondrej -- 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 3. 12. 2023, at 18:41, Gérard Parat via bind-users > wrote: > > Hi, > > I used this tutorial as reference to setup DNSSEC with SoftHSM2: > https://kb.isc.org/docs/bind-9-pkcs11 > > I installed the Debian package instead of building libp11: > libengine-pkcs11-openssl:amd640.4.12-0.1 > > It works until reaching this command: > $ dnssec-keyfromlabel \ > -E pkcs11 \ > -a RSASHA256 \ > -l "token=bind9object=example.net-ksk" \ > -f KSK example.net > dnssec-keyfromlabel: fatal: could not initialize dst: crypto failure > > Trying directly from OpenSSL works: > $ openssl pkey \ > -in "pkcs11:token=bind9;object=example.net-ksk" \ > -inform ENGINE \ > -engine pkcs11 \ > -text \ > -pubin > Engine "pkcs11" set. > -BEGIN PUBLIC KEY- > MIG/MA0GCSqGSIb3DQEBAQUAA4GtADCBqQKBoQCmhO41MX09L/BiJiU7ygXt6D7J > ujmZFMBB7tb/LJBazNp+Xd5TLHZvp1MxFBBW39swTU6oynLnp8IOIuWQNap6kyQ5 > hkGusvZ/JsrwHLZ1phPBKsdEd2ClB9EfF+ReabhXRVbqrw9yz22mLdlajmkLTx2d > V6EsjJue+aSX1nxFmna6qNrZBA5ifClpKH7R/0ztQb1RlYA11RG1RGrsRSJnAgMB > AAE= > -END PUBLIC KEY- > RSA Public-Key: (1280 bit) > Modulus: >00:a6:84:ee:35:31:7d:3d:2f:f0:62:26:25:3b:ca: >05:ed:e8:3e:c9:ba:39:99:14:c0:41:ee:d6:ff:2c: >90:5a:cc:da:7e:5d:de:53:2c:76:6f:a7:53:31:14: >10:56:df:db:30:4d:4e:a8:ca:72:e7:a7:c2:0e:22: >e5:90:35:aa:7a:93:24:39:86:41:ae:b2:f6:7f:26: >ca:f0:1c:b6:75:a6:13:c1:2a:c7:44:77:60:a5:07: >d1:1f:17:e4:5e:69:b8:57:45:56:ea:af:0f:72:cf: >6d:a6:2d:d9:5a:8e:69:0b:4f:1d:9d:57:a1:2c:8c: >9b:9e:f9:a4:97:d6:7c:45:9a:76:ba:a8:da:d9:04: >0e:62:7c:29:69:28:7e:d1:ff:4c:ed:41:bd:51:95: >80:35:d5:11:b5:44:6a:ec:45:22:67 > Exponent: 65537 (0x10001) > > Debian 12 (bookworm) use OpenSSL version 3: > libssl3:amd64 3.0.11-1~deb12u2 > openssl 3.0.11-1~deb12u2 > > Installed BIND9 packages: > bind9 1:9.18.19-1~deb12u1 > bind9-utils 1:9.18.19-1~deb12u1 > bind9-dnsutils1:9.18.19-1~deb12u1 > bind9-doc 1:9.18.19-1~deb12u1 > bind9-libs:amd64 1:9.18.19-1~deb12u1 > bind9-host1:9.18.19-1~deb12u1 > > $ dnssec-keyfromlabel -V > dnssec-keyfromlabel 9.18.19-1~deb12u1-Debian > > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so > MODULE_PATH = /usr/lib/softhsm/libsofthsm2.so > init = 0 > > strace file: > https://pasteb.in/?bd9a4ecaca6ece23#E2emtt8zi9t5UsnFJ2QWKVD6ALTkZmKG9656 > fuZR3ArX > > It seems to be an API problem or maybe I missed something ? > > Gérard > -- > 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: license for config files
Hi PJ, I actually think those config files doesn’t come from ISC, but from a Debian packaging. You should check the place where you actually took the files from. Always! It does clearly state the copyright holders and the licenses for those files. As a side note, the contents of these files are not novel enough to be covered by Berne conventions, but IANAL, and even if I were, asking three lawyers will give you five different answers, so it’s better to err on the safe side and use on the licenses listed in the Debian packaging. Ondrej -- 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 27. 11. 2023, at 23:23, PJ Fanning via bind-users > wrote: > > Hi everyone, > > I'm a developer on the Apache Pekko project, an open source fork of Akka. > > One of our mentors has queried if we have a licensing issue for the files in > this directory. > > https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/test/bind/etc > > The configs there are Bind9 configs used in our tests. > > Does the Mozilla Public License have to be applied to our config files? > > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE > > The Mozilla Public License is regarded by the ASF as having copyleft > implications. > > Any advice on the licensing implications of having config files based on this > repo would be appreciated. > > Thanks, > PJ > -- > 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 recursion for windows bind for Teamviewer
Hey, BIND 9.16 is in security-and-critical-only mode, so this won’t get fixed in any case. However, your message is incomprehensible. If you want to get anything fixed, we will need more clarity in the report - describe your setup (clients, recursive servers, authoritative servers) and properly describe the communication between those. Logs from the failing servers are absolute minimum. Perhaps (annotated) tcpdump (wireshark) dumps would be also helpful. Ondrej -- 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 19. 11. 2023, at 19:40, legacyone via bind-users > wrote: > > > I don't know if this will be fixed before EOL for windows bind but here is > the problem > Teamviewer (and maybe other sites too) when you do the recursion when no > answer under 1000ms it tries again which is trigged by client windows (not > the one running bind) which also tries again for a answer this seems to > causes the bind server not to give a answer but it tries and tries then > Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be > causing a problem for bind for windows because I tested bind in Ubuntu having > DNS forward for teamviewer.com to it and Teamviewer loads faster. > So it be nice if this could be fixed but I will not hold my breath. > Thanks for any insight on this > -- > 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: Can we enable serve-stale parameter in bind
This is a horrible reason to enable serve-stale. Serve stale is a bandaid. You should increase a resiliency of the architecture - have more nameservers for the domain, make the restarts seamless, etc. Serve-stale was meant to deal with unexpected outages and not as a workaround for bad engineering in the first place. Ondřej -- 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 6. 11. 2023, at 3:04, Prasanna Mathivanan (pmathiva) via bind-users > wrote: > > > Hi team, > > If there is a scenario where NS are not reachable, until its up we can serve > from cache. > > Enabling serve-stale can help us with this use case, is it safe to enable > this parameter and what should be the recommended value set for max-stale-ttl > ? > > -- > Regards, > Prasanna > > -- > 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: Question about URL being logged by resolver
It means something in your network sent a query containing the literal URL below. The message is just misleading - the resolver tries to do QNAME minimization on it, it fails, switches to full name which ends with NXDOMAIN from root. Ondrej -- 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 3. 11. 2023, at 23:30, J Doe wrote: > > Hello, > > On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see > URL's being noted in the log files. > > One such example is: > > 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving > 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization > due to 'ncache nxdomain' > > This seems unusual to me because Bind usually notes the domain name it is > attempting to resolve, not an URL. In this particular case, I would expect > to see a notation about "app-measurement.com" and not "http://etc;. > > What is the significance of logging the URL and why does this happen in only > some cases ? > > Thanks, > > - J > -- > 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: Help about DNS documentation
> On 3. 11. 2023, at 18:04, Fred Morris wrote: > > Your interpretation of what is occurring may be interfering with your > understanding of it. This ^^^. You should start with understanding the wider picture by studying how DNS works. I would recommend starting here: https://labs.ripe.net/author/bert_hubert/introducing-tdns-the-teachable-authoritative-dns-server/ Once you actually grasp how the DNS protocol works, some answers will become obvious. Ondřej -- 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. -- 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.18 BIND not iterated over all authoritative nameservers
Please don’t use Postel’s Law as excuse for implementations that break standards: https://datatracker.ietf.org/doc/html/rfc9413--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 28. 10. 2023, at 17:50, Paul Stead wrote:As a previous ISP admin I too have come across similar situations and frustrations.I can only say that Google and Cloudflare seem to follow Postel's Law moreso than BIND.I agree this perpetuates bad practices but end users aren't interested in technical reasoning, especially when "it works everywhere else, you must be broken"PaulOn Sat, Oct 28, 2023, 3:56 PM Rick Frey <grib...@gmail.com> wrote:As Mark mentions, the NS records gtm.bankeasy.com need to be corrected and failure is not due to lack of iterating through all auth nameservers (all of the auth nameservers have the bad NS record anyway). Not sure how many other domains you are running into similar problem, but you could disable qname-minimization in 9.18 to mimic previous behavior of 9.16 if that number is large. I believe qname-minimization is a global directive so it would remove privacy benefits of QNAME minimization for all recursive queries from your nameserver. As DNS admin of another ISP, I sympathize dealing with failures caused by non-compliant authoritative nameservers. These non-compliant auth nameservers can have little motivation to fix, especially when other large ISPs or public resolvers (looking at you Google and Cloudflare) don’t enforce DNS standards. Many non-compliant nameservers/records would be cleaned up if public/centralized DNS providers such as Google/Cloudflare would enforce since it would inflict those failures on a much larger user base. - RickOn Oct 27, 2023, at 6:31 PM, Mark Andrews <ma...@isc.org> wrote:Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NSrecords then they should expect lookups to fail. The NS records on both sides of a zonecut are supposed to be IDENTICAL. This is not a new requirement. It has been this waysince the very beginning.The bank needs to fix what they publish.MarkOn 28 Oct 2023, at 02:36, Michael Martinell via bind-users <bind-users@lists.isc.org> wrote:Hello, At this point I am hoping that somebody might have a workaround so that we can exclude domains from this behavior if they are broken on the far end. Does anybody have a workaround for this? We are a small ISP and run BIND compiled from source. We currently run 9.16.xEvery time we try to move forward with 9.18 customers start to complain that they are unable to reach certain websites. This includes banks, universities, and other organizations. I understand the goal is to get all DNS to RFC 6891, but from a practical standpoint, this isn’t working for customers, so we are prevented from upgrading either. Related website:https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Our source code compile options:./configure --with-gnu-ld --with-libxml2 --with-json-c --with-openssl=/usr/local/openssl && make && make install && ldconfigInterstate Telecommunications Coop., Inc.312 4th Street West • Clear Lake, SD 57226Phone: (605) 874-8313michael.martin...@itccoop.comwww.itc-web.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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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 service problem with BIND 9.10.3
You are using an end-of-life BIND 9 on end-of-life Ubuntu. Start with that…There is no point in debugging a version with unfixed bugs and security vulnerabilities.Ondřej --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 14. 10. 2023, at 13:20, Mosharaf Hossain wrote:Hi AllLately, we've been encountering an intriguing issue with our Auth+Recursive DNS server, characterized by relatively low traffic. Normally, our DNS server handles around 3 Mbps/second of traffic. However, at certain moments, when the load peaks at 4-5 Mbps, the DNS resolver's responsiveness falters.To my understanding, this occurrence may be indicative of an ongoing DDoS attack during these periods. Nevertheless, I'm puzzled as to why the server seems to get stuck at 4-5 Mbps, considering that the LAN capacity is a substantial 1 Gbps. I seek your guidance to address and resolve this recurrent issue.Currnet BIND9 version : .10.3-P4-Ubuntu Fig: Showing the suspicious traffic and during this time recursion unable to respond. RegardsMosharaf HossainManager, Product DevelopmentIT DivisionBangladesh Export Import Company Ltd.Level-8, SAM Tower, Plot #4, Road #22, Gulshan-1, Dhaka-1212,BangladeshTel: +880 9609 000 999, +880 2 5881 5559, Ext: 14191, Fax: +880 2 9895757Cell: +8801787680828, Email: mosharaf.hoss...@bol-online.com, Web: www.bol-online.com -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: One of my zones is failing, don't know why.
Can’t tell anything from a log snippet and incomplete config. Use named -px to
provide more complete but sanitized configuration file and look what is
happening when the zone is loaded on primary. You sent a log that confirms what
you are saying - the primary is not serving the zone, but you need to look
closely when named starts why the zone isn’t loaded.
Ondřej
--
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 5. 10. 2023, at 19:26, William D. Colburn wrote:
>
>
> One of my zones doesn't work anymore. It is an external view for
> aoc.nrao.edu. The master, zia.aoc.nrao.edu can't server it, and the two
> slaves are showing an old zone from September 20th.
>
> I see this in the logs. Is this a helpful clue? I don't see anything else
> in the logs that looks helpful, but there are a lot of logs...
>
> 05-Oct-2023 11:19:07.959 client @0x7ff3641e9460 45.91.101.41#55879
> (aoc.nrao.edu): view external: query: aoc.nrao.edu IN SOA +E(0)K (146.88.1.4)
> 05-Oct-2023 11:19:07.959 client @0x7ff3641e9460 45.91.101.41#55879
> (aoc.nrao.edu): view external: query failed (zone not loaded) for
> aoc.nrao.edu/IN/SOA at query.c:5565
>
> The server is running bind 9.16.43.
>
> The start of the zone looks correct to me.
>
> $ORIGIN .
> $TTL 86400
> aoc.nrao.eduIN SOA zia.aoc.nrao.edu. tech.nrao.edu. (
>2023100503 ; serial
>10800 ; refresh (3 hours)
>3600 ; retry (1 hour)
>360; expire (5 weeks 6 days 16 hours)
>3600 ; minimum (1 hour)
>)
>NS cv3.cv.nrao.edu.
>NS zia.aoc.nrao.edu.
>NS sadira.gb.nrao.edu.
>A 146.88.1.4
>MX 9 revere-vml.aoc.nrao.edu.
>MX 30 cv3.cv.nrao.edu.
>MX 30 io.gb.nrao.edu.
> $TTL 300
>TXT "v=spf1 mx ~all"
> $TTL 86400
> $ORIGIN aoc.nrao.edu.
> zia A 146.88.1.4
>MX 10 dropbox
>MX 15 revere-vml
> dns CNAME zia
> infoCNAME zia
> [...]
>
> The .conf looks somewhat like this:
>
># Domain aoc.nrao.edu INTERNAL
>zone "aoc.nrao.edu" {
>type master;
>file "internal/master/aoc.nrao.edu";
>allow-query {
>any;
>};
>allow-transfer {
>trusted;
>nrao-public-ns;
>nrao-stealth-ns;
>};
>also-notify { # An ACL doesnt work here! GRRR!
> [various things]
>};
>allow-update {
>146.88.1.4; # Making sure of nsupdate on zia
>127.0.0.1;
>};
>};
>
>
> I did a restore from the backups a few weeks ago, and I didn't see anything
> weird there either.
>
>
>
> --Schlake
> Sysadmin IV, NRAO
> Work: 575-835-7281 (BACK IN THE OFFICE!)
> Cell: 575-517-5668 (out of work 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
Re: Unhelpful startup message re: RPZ
Hi John,GitLab is a good place to fill well-defined feature requests.Thanks,--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 21. 9. 2023, at 18:22, John Thurston wrote: I just spent 4 hours* of my life trying to figure out why BIND 9.16 complained on startup: rpz 'rpz.local' is not a master or slave zone when the zone was obviously defined, and was obviously loading. This was easily verified by looking at named-checkconf -px output, and by looking in the logs to see the XFR from its primary. It turns out . . . my global response-policy option worked swimmingly when there was exactly one view defined. When there is more than one view, the reference to the zone becomes ambiguous and bind threw out that (not very) helpful message. When there is more than one view, the response-policy must be specified in each relevant view. Where do I make a 'feature request'? I think I see how to register defects (GitLab). Do feature requests go there, too? I'd love to see the text of that message be a little more explanatory. Maybe, "Dude. The zone you named exist, but with more than one view your reference is ambiguous." And, now that I think about it, it also feels like a defect in named-checkconf that this is not called out. Or maybe I'm expecting too much from named-checkconf ? * Admittedly, the second and third hours were of diminishing value, as my caffeine wore off and my frustration grew. After a night's sleep, and a pot of fresh tea I figured it out. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: unresolvable pms.psc.gov, but google/cloudflare/unbound work
> On 19. 9. 2023, at 9:25, Petr Špaček wrote: > > All can I tell you is "it works on my system" (with BIND, of course): I can reproduce this on BIND 9.16 (-c /dev/null as named.conf): ## BIND 9.19-dev 19-Sep-2023 09:33:51.633 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:33:52.485 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:33:52.485 validating pms.ha.psc.gov/A: no valid signature found $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35947 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 76cc17ac4ce491b90100650950c533d1d3531585cef9 (good) ## BIND 9.18-dev 19-Sep-2023 09:36:10.717 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:36:11.581 validating ha.psc.gov/DS: no valid signature found 19-Sep-2023 09:36:11.581 validating pms.ha.psc.gov/A: no valid signature found $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30482 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: f109de3980764a4201006509507caea9fe0064088c8e (good) ## BIND 9.16-dev 19-Sep-2023 09:37:17.685 validating pms.psc.gov/CNAME: no valid signature found 19-Sep-2023 09:37:27.685 query client=0x7f0b840013b0 thread=0x7f0b8ed7b6c0(pms.ha.psc.gov/A): query_gotanswer: unexpected error: timed out $ bin/dig/dig +short -p 12345 pms.psc.gov @127.0.0.1 $ bin/dig/dig +noall +comments -p 12345 pms.psc.gov @127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: e5b154394f27002201006509503c139afd80b72dd04a (good) Those servers are broken with QNAME minimization and should be fixed, but as we changed the QNAME minimization algorithm to use NS records instead of A records in BIND 9.18.17 and higher, it works now. I can confirm this works in BIND 9.18.17 and higher. And it's absolutely not BIND 9's fault. Cheers, -- 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
Re: Dnstap Re: Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)
Hi Fred,
the Dnstap UDS support is only tangential to this - the support for AF_UNIX is
implemented in the fstrm library
and is outside of the scope for this change.
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.
> On 12. 9. 2023, at 18:18, Fred Morris wrote:
>
> No objections, however I hope somebody lets me know if the same thing is
> contemplated for Dnstap and what the timeline is. I won't be unduly lathered
> by such an occurrence but I'd rather not have fire drills (and it's not just
> me it's people / projects downstream of me).
>
> FTR, I've always used an IP address with RNDC.
>
> On Tue, 12 Sep 2023, Ondřej Surý wrote:
>>
>> [...] The support for Unix
>> Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
>> error in named. This is properly documented in BIND 9.18.0 release notes and
>> known issues.
>>
>> We are now proceeding to complete remove the rest of the code and
>> documentation
>> from BIND 9.20+ (future release).
>>
>> [...]
>>
>> 1. Using 'unix' option in 'controls {}' block in named.conf is already a
>> fatal error in named
>>
>> The original issue is tracked under:
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/1759
>
> This wasn't particularly reassuring considering the Dnstap case. It discusses
> something called "netmgr" which is used for "incoming DNS queries and
> responses" and that now is apparently being adapted to a control channel; it
> talks about modifying it to support outbound TCP connections.
>
> Dnstap has never been a server, it establishes an outbound connection to a
> listener (server) on a unix socket. Seems like TCP has always been an option
> for rndc, while it's never been an option for Dnstap; so that's a difference,
> there's no explicit migration path at this moment.
>
> Personally I'd be happy to see the last of framestreams (we don't need the
> handshake, I've never used it and I've only ever seen it create confusion for
> people trying to roll their own servers). I'd love to see UDP so that we
> could get multicast (without a T/MG), but that doesn't allow for the Dnstap
> overhead since DNS message sizes are already capped at the maximum possible
> size of a UDP message.
>
> Doing nothing is an option. ;-)
>
>
> Thanks for all the work you do...
>
> --
>
> Fred Morris
> --
> 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
Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)
Hello,
in line with out deprecation policy, I am notifying the mailing list about
deprecation
of the 'unix' clause in the controls {} configuration block. The support for
Unix
Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
error in named. This is properly documented in BIND 9.18.0 release notes and
known issues.
We are now proceeding to complete remove the rest of the code and documentation
from BIND 9.20+ (future release).
The 'unix' description from the ARM:
>A :any:`unix` control channel is a Unix domain socket listening at the
>specified path in the file system. Access to the socket is specified by
>the ``perm``, ``owner``, and ``group`` clauses. Note that on some platforms
>(SunOS and Solaris), the permissions (``perm``) are applied to the parent
>directory as the permissions on the socket itself are ignored.
In BIND 9.20:
1. Using 'unix' option in 'controls {}' block in named.conf will be a fatal
error in named and named-checkconf
In BIND 9.18 :
1. Using 'unix' option in 'controls {}' block in named.conf is already a fatal
error in named
The original issue is tracked under:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1759
This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/4311
Cheers,
--
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
Deprecation notice force BIND 9.20+: dnssec-must-be-secure option
Hello, in line with out deprecation policy, I am notifying the mailing list about our preliminary intent to deprecate the 'dnssec-must-be-secure' option. The option will be marked as deprecated (causing warning from named-checkconf) in BIND 9.18 and 9.20 and it will be removed in BIND 9.21+ when the next development cycle starts next year. The 'dnssec-must-be-secured' description from the ARM: >This specifies hierarchies which must be or may not be secure (signed and >validated). If ``yes``, then :iscman:`named` only accepts answers if >they are secure. If ``no``, then normal DNSSEC validation applies, >allowing insecure answers to be accepted. The specified domain >must be defined as a trust anchor, for instance in a :any:`trust-anchors` >statement, or ``dnssec-validation auto`` must be active. > In BIND 9.21: 1. Using dnssec-must-be-secure option in named.conf will be now a fatal error In BIND 9.18 and BIND 9.20: 1. Using dnssec-must-be-secure option in named.conf will issue a deprecation warning This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/4263 Thanks. -- 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
Re: help me with the ipv6 PTR generation
dig -x 2001:db8::1 also works -- 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 24. 8. 2023, at 8:49, Jan-Piet Mens wrote: > > >> >> IPv6 PTR records are simply reversed. > > easier said than done, for some of us. I use BIND's arpaname(1) utility which > does the work for me: > > $ arpaname 2001:db8::1 > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA > >-JP > -- > 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: Moving to a IPv4 only server
You did the classic mistake - assuming what the problem is and then trying to find a solution for that problem. You should start with just describing what you see - and the logs you sent indicate that the named is unable to communicate on port 53. This indicates that your network (firewall on the server, firewall at the provider) might be blocking DNS queries to the outside world. You should diagnose that - try sending DNS queries to those addresses by hand and look what’s happening on the wire (tcpdump, wireshark, etc. are your friends). Ondřej -- 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 18. 8. 2023, at 22:00, Julien Salort wrote: > > Hello, > > I am sorry if this is a FAQ. I haven't been able to find the answer. > > I used to have bind9 running on a server with both IPv4 and IPv6. This server > has failed unfortunately, and I am setting up replacement using the last > backup of the failed server. The new server happens to have IPv4 address > only, unfortunately. Both the old and the new server are running Ubuntu 22 if > that matters. > > I copied /etc/bind directory from the backup to the new server. > > Authoritative zones work fine. It also transfers successfully to the slaves > when I make changes in the zones. > > However, I can't get the recursion to work. I originally had a lot of > "network unreachable" with IPv6 addresses. So I figured I should start bind > with -4 option. Now, I no longer have the "network unreachable" errors in the > log, but it is still unable to recurse. > > For example: > > dig www.google.com @127.0.0.1 > > ;; communications error to 127.0.0.1#53: timed out > ;; communications error to 127.0.0.1#53: timed out > > ; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> www.google.com @127.0.0.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35198 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: a497120ee47312be010064dfccb2ba16350e188a7bc4 (good) > ;; QUESTION SECTION: > ;www.google.com.INA > > ;; Query time: 1988 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) > ;; WHEN: Fri Aug 18 19:55:30 UTC 2023 > ;; MSG SIZE rcvd: 71 > > > And in the log file: > > Aug 18 19:55:23 vpsl named[3183]: client @0x7f8a4c0152f8 127.0.0.1#33163 > (www.google.com): query: www.google.com IN A +E(0)K (127.0.0.1) > Aug 18 19:55:28 vpsl named[3183]: resolver priming query complete: timed out > Aug 18 19:55:28 vpsl named[3183]: client @0x7f8a5420b6f8 127.0.0.1#43890 > (www.google.com): query: www.google.com IN A +E(0)K (127.0.0.1) > Aug 18 19:55:30 vpsl named[3183]: shut down hung fetch while resolving > 'www.google.com/A' > Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a54213b58 127.0.0.1#46373 > (www.google.com): query failed (operation canceled) for www.google.com/IN/A > at query.c:7794 > Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a5420b6f8 127.0.0.1#43890 > (www.google.com): query failed (operation canceled) for www.google.com/IN/A > at query.c:7794 > Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a4c0152f8 127.0.0.1#33163 > (www.google.com): query failed (operation canceled) for www.google.com/IN/A > at query.c:7794 > Aug 18 19:55:38 vpsl named[3183]: resolver priming query complete: timed out > > > It feels like there are some root server addresses with IPv6 address that it > can't use, but I have no clue where these addresses are and how to replace > them with their IPv4 counterparts. > > > Thanks for any clue, > > > Julien > > -- > 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: Zone Transfers Being Refused
Well, for starters your primaries list 192.168.2.10, but your logs show
connection from 192.168.1.1…
--
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 31. 7. 2023, at 9:51, duluxoz wrote:
>
> Hi Ondřej,
>
> Sorry, force of habit (re: "example.com").
>
> External Secondary DNS Server (ns1.mjb-co.com):
>
> ~~~
>
> acl "bogusnets" {
> !"internal_hosts";
> 0.0.0.0/8;
> 10.0.0.0/8;
> 172.16.0.0/12;
> 192.0.2.0/24;
> 192.168.0.0/16;
> 224.0.0.0/3;
> };
> acl "internal_hosts" {
> 192.168.1.0/24;
> 192.168.2.0/24;
> 192.168.3.0/24;
> };
> acl "secondary_external_servers" {
> 192.168.1.10/32;
> };
> acl "secondary_internal_servers" {
> 192.168.2.11/32;
> 192.168.2.12/32;
> };
> acl "ddns_servers" {
> "localhost";
> 192.168.2.10/32;
> 192.168.2.11/32;
> };
> acl "rndc_servers" {
> "localhost";
> 192.168.2.10/32;
> };
> acl "stats_hosts" {
> 192.168.2.0/24;
> };
> controls {
> inet 0.0.0.0 port 953 allow {
> "rndc_servers";
> } keys {
> "rndc-key";
> };
> };
> logging {
> channel "auth_servers_log" {
> file "/var/log/named/auth_servers.log" versions 3 size 20971520
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "client_security_log" {
> file "/var/log/named/client_security.log" versions 3 size 20971520
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "default_log" {
> file "/var/log/named/default.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "default_debug_log" {
> file "/var/log/named/default_debug.log" versions 3 size 20971520
> suffix timestamp;
> severity dynamic;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "ddns_log" {
> file "/var/log/named/ddns.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "dnssec_log" {
> file "/var/log/named/dnssec.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "dnstap_log" {
> file "/var/log/named/dnstap.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "queries_log" {
> file "/var/log/named/queries.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "query_errors_log" {
> file "/var/log/named/query_errors.log" versions 3 size 20971520
> suffix timestamp;
> severity dynamic;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "rate_limiting_log" {
> file "/var/named/log/rate_limiting.log" versions 3 size 20971520
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "rpz_log" {
> file "/var/named/log/rpz.log" versions 3 size 20971520 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "zone_transfers_log" {
> file "/var/log/named/zone_transfers.log" versions 3 size 20971520
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> category "client
Re: Zone Transfers Being Refused
Hi, it’s hard to help you if you don’t provide your configuration (named-checkconf -px) and use example.com instead of real domain names. Are even the IP addresses real? Ondřej -- 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 31. 7. 2023, at 9:23, duluxoz wrote: > > Hi All, > > Hoping someone can help with this: I've got a primary dns server on an > internal network (192.168.2.10/24) and an external secondary dns server on > the dmz network (192.168.1.10/24). The gateway for each (ie the router) is > 192.168.x.1. > > The external domain is dynamic, with dnssec set up, and everything *seems* to > be working correctly. > > So I did a rndc to update a record in the external zone on the primary. The > primary's logs show that the update went through and that a zone transfer > notification was sent out to the external secondary. I can also see the > updated record in the (raw) zone file on the primary. > > The external secondary's logs show that it received the zone update > notification, BUT that it was coming from the gateway's IP and not the > primary server, and thus because the gateway's IP was not in the "primaries" > ACL it was/is being refused. > > I don't know if its relevant but the external zone has the `dnssec-policy > default` option set. > > The (what I think are the relevant) parts of the external secondary's logs > are: > > ~~~ > > 31-Jul-2023 16:23:14.182 notify: info: client @0x7ff49061ecc8 > 192.168.1.1#36875: received notify for zone 'example.com' > > 31-Jul-2023 16:23:14.182 general: info: zone example.com/IN: refused notify > from non-master: 192.168.1.1#36875 > > ~~~ > > Can someone please point me in the correct direction to resolve this issue? I > can provide further info if required. I am reluctant to add the gateway's IP > to the "primaries" ACL because its also the external gateway for the site, > and I believe that adding the gateway's IP to the ACL will be a (major) > security issue. > > Thanks in advance > > Dulux-Oz > > -- > 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: Potential bug in Bind 9.16.23
The latest BIND 9.16 release is 9.16.42. You either need to upgrade to the latest release, preferably directly to 9.18.17. Alternatively, you should contact the supplier who provided you the outdated version. Ondřej -- 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 28. 7. 2023, at 10:04, Jiaming Zhang wrote: > > > Hi Community, > > I recently upgraded bind to 9.16.23, and a wired error occurs: the named > could not start after the configuration is loaded (and any zone mentioned in > the config). However, if loaded with the example config, and after the > service is successfully started, I can replace the sample config with the > previous config (`mv old.conf sample.conf`), and reconfig with rndc. In which > case the Bind behaves totally normal and can also answer every zone it has > loaded. > > I thought in the beginning that there's incompatibility in the conf file > between versions, but named-checkconf returns 0 as exit code. > > bind version info: > ``` > $ named -V > BIND 9.16.23-RH (Extended Support Version) > running on Linux aarch64 5.4.17-2136.321.4.el8uek.aarch64 #2 SMP Wed Jun 28 > 17:52:50 PDT 2023 > built by make with '--build=aarch64-redhat-linux-gnu' > '--host=aarch64-redhat-linux-gnu' '--program-prefix=' > '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' > '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' > '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' > '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' > '--mandir=/usr/share/man' '--infodir=/usr/share/info' > '--with-python=/usr/libexec/platform-python' '--with-libtool' > '--localstatedir=/var' '--with-pic' '--disable-static' > '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' > '--with-maxminddb' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' > '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' > '--enable-full-report' 'build_alias=aarch64-redhat-linux-gnu' > 'host_alias=aarch64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS > -fexceptions -fstack-protector-strong -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables > -fstack-clash-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' > 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' > compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-18.0.2) > compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 > linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 > compiled with libuv version: 1.41.1 > linked to libuv version: 1.41.1 > compiled with libxml2 version: 2.9.7 > linked to libxml2 version: 20907 > compiled with json-c version: 0.13.1 > linked to json-c version: 0.13.1 > compiled with zlib version: 1.2.11 > linked to zlib version: 1.2.11 > linked to maxminddb version: 1.2.0 > compiled with protobuf-c version: 1.3.0 > linked to protobuf-c version: 1.3.0 > threads support is enabled > > default paths: > named configuration: /etc/named.conf > rndc configuration: /etc/rndc.conf > DNSSEC root key: /etc/bind.keys > nsupdate session key: /var/run/named/session.key > named PID file: /var/run/named/named.pid > named lock file: /var/run/named/named.lock > geoip-directory: /usr/share/GeoIP > ` > > Met vriendelijke groet / Best regards, > Jiaming Zhang > -- > 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: DNSSec Setup ARM Manual vs KB article on adding inline-signing for non-dynamic zones
Well, you didn’t say which version of ARM did you follow. Your ARM needs to match the BIND 9 version - you need to ask RH for the matching ARM. And of course, if you find discrepancies between the BIND 9 version as provided by ISC and matching ARM as provided by ISC, we would be happy to fix it. And I need to mention that ISC provides packages for RHEL and generally recommends that user use latest upstream version of the BIND 9. Ondřej -- 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 24. 7. 2023, at 20:15, E R wrote: > > > As if DNSSec is not confusing enough...It seems the ARM manual that matches > my release is out of step with the web site. I followed the "Easy-Start > Guide for Signing Authoritative Zones" in the ARM manual after manually > signing my test zone for my starting point. The ARM says you ONLY need to > specify "dnssec-policy default;" in your zone, view or options clause for the > newer way to sign things. I completed the steps successfully (except for one > command that no longer works as shown in the manual which is not important). > I cannot find anything broken with BIND 9.16.23-RH (Extended Support Version) > when I follow the ARM manual. > > This document https://kb.isc.org/docs/dnssec-key-and-signing-policy says I > need to have dynamic zone for things to work. Don't need or design anything > other than a good ole static zone since an entry is changed like 3-4 times > per year. The newest ARM has a new section that mentions needing to setup > Dynamic DNS but it also states that BIND previously used implicit > inline-signing. It is really difficult for a casual observer to sort this > out. No reference to what they mean by "previously". > > Did they break builds newer than 9.16.23 and that is why I am not seeing any > issues? Or is it the fact that I am not an DNSSEC expert I am not seeing a > glaring issue? > -- > 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: Bind to Bind DNS Lookup - Returns wildcard value for defined A record
Also:- make the record self-contained, don’t make us go elsewhere, especially not to a place where data could disappear at the whim of the owner (as seen recently)- and finally, describe what you see, don’t speculate what it might be; by describing you are less likely to miss an important detailOndřej--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 16. 7. 2023, at 10:25, Greg Choules via bind-users wrote:Real data please:- example queries (genuine, not invented for illustration)- real domains- real IP addresses- packet captures- both BIND server configs- zone file contents- startup logsThere are so many things it *could* be, the more information the better.Cheers, GregOn Sun, 16 Jul 2023 at 09:09, OwN-3m-All <own3m...@gmail.com> wrote:I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server. Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying. I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host. Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host. It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on.Is this a recent bug in bind? More information about my setup and issue can be found here:https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entrFrom what I found online, if there's a specific host A record entry defined, it should always return that IP. Wildcard is only for those not defined. Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there. But Google and other major DNS providers return the non-wildcard value as expected.Any help is appreciated. -- 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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Changes to the Git repository
Hi, in case anybody here follows the git repository, the following changes have been done to the repository: 1. The tags have been changed from CVS-style v9_x_y to v9.x.y naming, e.g. v9.19.14, v9.18.16, v9.16.42 2. The branches have been changed from CVS-style v9_x naming to bind-9.x naming, e.g. bind-9.16, bind-9.18 And just for clarity: 3. The default and development branch is called main (this has been true for quite some time now) The rest of the branches is various work in progress (as usual). Cheers, -- 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
Re: Unable to upgrade BIND v9.19.11 on Ubuntu without error
And this: --cut here-- Notes for BIND 9.18.14 -- Removed Features - Zone type ``delegation-only``, and the ``delegation-only`` and ``root-delegation-only`` statements, have been deprecated. A warning is now logged when they are used. These statements were created to address the SiteFinder controversy, in which certain top-level domains redirected misspelled queries to other sites instead of returning NXDOMAIN responses. Since top-level domains are now DNSSEC-signed, and DNSSEC validation is active by default, the statements are no longer needed. :gl:`#3953` --cut here-- When you are skipping releases and running development release, I would strongly advise using `named-checkconf` when doing the upgrades. 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. > On 11. 7. 2023, at 10:25, Peter Davies wrote: > > > Hi Richard, > FYI: The BIND 9.19.12 Release Notes contain the following: > > > Removed Features > ... > Zone type delegation-only, and the delegation-only and root-delegation-only > statements, > have been removed. Using them is a configuration error. > ... > > Kind Regards 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 -- 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: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
You are wrong if you think the SOA record is only informal. It’s not, see https://www.rfc-editor.org/rfc/rfc2308 for more details. Then > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address mixes things that **are** important to DNS (caches) and those that **aren’t** important to the DNS. You used that as a strawman argument and that never helps to have a useful discussion. Ondřej -- 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 7. 7. 2023, at 12:35, Jakob Bohm via bind-users > wrote: > > On 2023-07-07 12:17, Emmanuel Fusté wrote: >>> Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : >>> >>> >>> On 2023-06-02 05:02, Jesus Cea wrote: >>>> On 2/6/23 4:25, Mark Andrews wrote: >>>>> Yep, some people just don’t take care with delegations. Complain to >>>>> Huawei. >>>>> Complain to the other companies you list in your followup email. >>>>> >>>>> All it takes to fix this is to change the name of the zone on the child >>>>> servers >>>>> (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from >>>>> “huawei.com” >>>>> to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the >>>>> zone >>>>> if they are fully qualified. If there are other delegations from >>>>> huawei.com >>>>> for other sub zones to these servers they will also need to be >>>>> instantiated. >>>>> >>>>> It’s maybe 10 minute work for each subdomain to fix. It just requires >>>>> someone >>>>> to do the work. >>>> >>>> I sympathize. Expertise and caring for the job is something the world is >>>> losing fast and few people care at all. Complaining to business is not >>>> going to work, because this misconfiguration works fine for 99.9% of their >>>> users, clients of more "lax" DNS resolvers. >>>> >>>> What I get from your reply is that BIND is not expected to do anything >>>> about this. It is a bit disappointed but I agree that BIND is doing the >>>> right thing. Too bad big players don't care. But I need to "solve" this, >>>> so dropping BIND (nooo!) or patching software is on my table now. >>>> >>>>> When people come to you and say that it works with Google, et al. point >>>>> them at >>>>> https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error >>>>> and say >>>>> “Here is a DNS configuration testing site and it reports the zone as >>>>> broken, you >>>>> need to take it up with the company." >>>> >>>> "Whatever, Google works and you don't. You sucks!". Few people care about >>>> doing the right thing if crap works for them. If only 8.8.8.8 cared and >>>> gave back SERVFAIL as it should, everybody would fix her configuration >>>> immediately. Postel law [*] was a mistake (be strict when sending and >>>> forgiving when receiving). Nice advice, awful consequences we will pay >>>> forever. >>>> >>>> https://en.wikipedia.org/wiki/Robustness_principle >>>> >>> >>> The robustness principle isn't the problem here. It is more that parts of >>> the >>> bind code isapparently being strict about receiving out-of-range values in >>> an >>> informational part ofDNS responses, then turning a mostly usable reply from >>> remote servers into a SERVFAIL of binds own making, rather than just >>> filtering >>> out that informational part if bind considers it worth checking at all. >>> >> It is at the core of delegation and trust model of DNS, now possibly >> enforced by DNSSEC. Peer centric resolvers are lax on this checking for all >> but the security of their users. >> So in your opinion it is purely useless, and bad data it better than >> nodata/error. >> > I am saying that the SOA copy in the authority section of responses is purely > informational, unlike the data that provides DNSSEC signatures or even the > data that provides IP addresses for servers in responses to MX queries. > > So from that perspective, if bind code checks that this informal copy of an > SOA record is f
Changes to GitLab Sign-Up policy
Hey all, we had a massive Spam surge over couple past days, so we had to tighten the GitLab Sign-Up policy, so we don't waste our time on deleting spam from the issues. There's now couple of domains that are on denylist for signups: - hotmail.com <http://hotmail.com/> - outlook.com <http://outlook.com/> - gmail.com <http://gmail.com/> Those are the domains mostly used by 99% of the spam users [1]. If you absolutely need to create an account from these domains, talk to us, we can create the account for you. Also the same restrictions as before apply - any account created must have 2fa or create an issue within one day or it will be banned and then deleted. Any bio will be deleted in each Victor the GitLab Cleaner[2] run in the CI in the initial period to avoid a Bio Spam. Unfortunately with these rules, the Spammers were able to keep their accounts by creating Spam Issues, so we had to implement additional measures. I understand this might complicate things for some of you, but a) there were only couple of legitimate accounts with gmail/hotmail/outlook domain in the past, b) it's better if you use your real address and real name if you want our help[3]. 1. I have also enabled the qq.com <http://qq.com/> (and any domain hosted by their SMTP servers) as their implementation of DMARC is broken and all email from GitLab bounces. 2. http://gitlab.isc.org/ondrej/gitlab-victor/edit#js-general-project-settings 3. https://berthub.eu/articles/posts/anonymous-help/ Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Best way to handle multiple retries from BIND?
> On 26. 6. 2023, at 6:04, Randy Bush wrote: > > so, for address foux, how do i know if there is one client or more than > one? I think you only know that for an established TCP connection. Everything else could be port reuse. Ondřej -- 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. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18 available for Ubuntu from PPA ?
Yeah, the thing that Canonical is doing is frankly confusing for more people. Basically from now on you only get Ubuntu 18.04 updates if you pay for the Ubuntu Pro service (or register for **Personal use**).I think it’s better to upgrade than to pay for most of the normal deployments.Ondřej --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 23. 6. 2023, at 22:20, John Thurston wrote: Welp, there I have it. I thought I had until April 2028 :( Sorry for the noise. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 6/23/2023 12:04 PM, Ondřej Surý wrote: CAUTION: This email originated from outside the State of Alaska mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. Ubuntu 18.04 is EOL (End of Standard Support), and we don’t publishing packages for distributions without security support. You need to upgrade to Ubuntu 20.04 or Ubuntu 22.04. Ondřej -- 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 23. 6. 2023, at 21:48, John Thurston wrote: bind9: Installed: 1:9.18.15-1+ubuntu18.04.1+isc+1 Candidate: 1:9.18.15-1+ubuntu18.04.1+isc+1 Version table: *** 1:9.18.15-1+ubuntu18.04.1+isc+1 100 100 /var/lib/dpkg/status 1:9.11.3+dfsg-1ubuntu1.18 500 500 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 1:9.11.3+dfsg-1ubuntu1 500 500 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 6/23/2023 11:43 AM, Ondřej Surý wrote: What does apt-cache policy bind9 say? -- Ondřej Surý — ISC (He/Him) -- 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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: BIND 9.18 available for Ubuntu from PPA ?
Ubuntu 18.04 is EOL (End of Standard Support), and we don’t publishing packages for distributions without security support. You need to upgrade to Ubuntu 20.04 or Ubuntu 22.04.Ondřej--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 23. 6. 2023, at 21:48, John Thurston wrote: bind9: Installed: 1:9.18.15-1+ubuntu18.04.1+isc+1 Candidate: 1:9.18.15-1+ubuntu18.04.1+isc+1 Version table: *** 1:9.18.15-1+ubuntu18.04.1+isc+1 100 100 /var/lib/dpkg/status 1:9.11.3+dfsg-1ubuntu1.18 500 500 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 1:9.11.3+dfsg-1ubuntu1 500 500 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 6/23/2023 11:43 AM, Ondřej Surý wrote: What does apt-cache policy bind9 say? -- Ondřej Surý — ISC (He/Him) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: BIND 9.18 available for Ubuntu from PPA ?
What doesapt-cache policy bind9say?--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 23. 6. 2023, at 21:28, John Thurston wrote: I have an Ubuntu instance on which I'm running 9.18. It was installed in 2021 from the PPA, using the instructions at https://launchpad.net/~isc/+archive/ubuntu/bind We have successfully updated the packages many times in the past two years. But apt currently says there are no updates to install. If I 'dpkg -l bind9' I get back '1:9.18.15-1+ubuntu1 amd64' If I cat '/var/lib/apt/lists/ppa.launchpad.net_isc_bind_ubuntu_dists_bionic_InRelease' I see the same as if I look at http://ppa.launchpad.net/isc/bind/ubuntu/dists/bionic/InRelease When I look at https://launchpad.net/~isc/+archive/ubuntu/bind I think it is telling me that 1:9.18.16-1+ubuntu22.04.1+isc+1 should be available. Has anyone successfully updated to 9.18.16 from this PPA? Can you suggest what I'm doing wrong today? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: DNSSEC doubt
It’s not. TL;DR use dnssec-policy. The more elaborate version of the TL;DR can be found in the DNSSEC Guide here: https://bind9.readthedocs.io/en/v9.18.16/dnssec-guide.html -- 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 22. 6. 2023, at 20:43, Daniel A. Rodriguez via bind-users > wrote: > > > I wonder if it's mandatory make a manual deployment prior to an automated > setup. > -- > 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: Permission issue ¿?
Which would not be a problem. But we can’t help the OP without the config (named-checkconf -px) -- 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 22. 6. 2023, at 17:53, Marco wrote: > > Am 22.06.2023 um 11:47:50 Uhr schrieb Daniel Armando Rodriguez via > bind-users: > >> drwxr-sr-x 4 root bind 4,0K jun 22 11:17 . > > That means that the group bind is not allowed to write into that > directory. > -- > 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: replace "SERVFAIL" to "NXDOMAIN" with rpz
8. Configuration Reference — BIND 9 9.18.13 documentationbind9.readthedocs.ioI would certainly recommend reading the docs… especially the sections on break-dnssec and qname-wait-recurse.--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 17. 6. 2023, at 6:40, Fred Morris wrote:Admittedly, since I'm writing software to do "off label" stuff with DNS I make mistakes. But I have seen things along this line (interactions between RPZ and regular resolution in the context of "broken" domains): in some cases it has seemed impossible to ameliorate / mitigate SERVFAIL utilizing RPZ.I'll try to pay more attention and see if I can isolate a test case if the problem recurs. (I was kind of hoping someone would have a solution!)--Fred MorrisOn Fri, 16 Jun 2023, Crist Clark wrote:That should return a NXDOMAIN. Returning SERVFAIL is never a normal RPZaction. Something is wrong with your configuration.On Fri, Jun 16, 2023 at 1:39 PM wrote:For monitoring reasons I try to change the return code of a domain namefrom "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration ofBIND9.16.42 as follows:example.com IN CNAME.*.example.com IN CNAME .But it still doesn't work, I still have the message " SERVFAIL", is itfeasible or not please ?-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: dnssec not automatically updating on 1 server
What does the logs say? Have you checked them?
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 15. 6. 2023, at 15:54, Michael Martinell via bind-users
> wrote:
>
> Anybody have any ideas on why my dnssec records don’t always automatically
> update on my NS2 authoritative server? On my NS1 authoritative server the
> records update without issue.
> NS2 is an exact copy of NS1. We SCP all of the config files from the first
> server to the second server and do “rndc reconfig && rndc reload && systemctl
> restart bind” on both servers.
> They are both Centos 7 running Bind 9.16.40.
> When it fails, I get this message:
> [root@ns2 ~]# delv itctel.com @ns2.itctel.com
> ;; validating itctel.com/A: verify failed due to bad signature (keyid=3593):
> RRSIG has expired
> ;; validating itctel.com/A: no valid signature found
> ;; RRSIG has expired resolving 'itctel.com/A/IN': 75.102.160.231#53
> ;; validating itctel.com/A: verify failed due to bad signature (keyid=3593):
> RRSIG has expired
> ;; validating itctel.com/A: no valid signature found
> ;; RRSIG has expired resolving 'itctel.com/A/IN':
> 2607:d600:9000:300:75:102:160:231#53
> ;; resolution failed: RRSIG has expired
> I have this policy in named.conf
> dnssec-policy "itc-no-rotate" {
> keys {
> ksk key-directory lifetime unlimited algorithm 13;
> zsk key-directory lifetime unlimited algorithm 13;
> };
> nsec3param;
> };
> I have this set up in a custom includes file:
> zone "itctel.com" in {
> type master;
> file "forward/itctel.com.zone";
> dnssec-policy itc-no-rotate;
> inline-signing yes;
> };
> No changes to my actual zone files. The inline signing takes care of
> everything.
> Here is a list of my files for this domain
> /var/named/forward/itctel.com.zone
> /var/named/forward/itctel.com.zone.jnl
> /var/named/forward/itctel.com.zone.signed
> /var/named/forward/itctel.com.zone.jbk
> /var/named/forward/itctel.com.zone.new
> /var/named/forward/itctel.com.zone.signed.jnl
>Michael Martinell
> Network/Broadband Technician
>
> Interstate Telecommunications Coop., Inc.
> 312 4th Street West • Clear Lake, SD 57226
> Phone: (605) 874-8313
> michael.martin...@itccoop.com
> www.itc-web.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
--
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: Controlling which interface named uses
The other approach might be the up/down scripts on your ppp connection that will reconfigure the query-source(-v6) address as the connection is established or tore down. Ondřej -- 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 10. 6. 2023, at 19:24, Ondřej Surý wrote: > > You are over-complicating things. If unconfigured, named binds the outgoing > UDP to 0.0.0.0 (::0), which means the chosen IP address is picked by the > kernel. You need to configure priorities on your interfaces in the kernel - > ip route is your friend. > > And for goddess’ sake, don’t do anything wild like proposed round robin > across default routes. That would be a living hell to debug. > > Ondřej > -- > 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 10. 6. 2023, at 18:55, Alessandro Vesely wrote: >> >> On Fri 09/Jun/2023 18:32:25 +0200 Anand Buddhdev wrote: >>>>> On 09/06/2023 17:26, Alessandro Vesely wrote: >>>>> Having two WANs, it would be reasonable, in case one doesn't work, to try >>>>> the other one. However, it's always useless to try the LAN. Is there >>>>> any way to configure which interface is used for outgoing queries? >>> You can configure "query-source" and "query-source-v6" in named.conf, to >>> tell BIND which interface to use for outgoing queries. >> >> >> Thank you, Anand; I hadn't found those statements. However, they take a >> single address only. >> >> I'm not as much concerned about IP version as about availability. Enabling >> IPv6 looks nice as I see queries going out through an interface which is not >> the default. But will named turn back to the default interface in case the >> IPv6 link goes down? >> >> Keep in mind that links sometimes seem to be up, as they're connected to a >> PPP peer or router, for example, but don't actually work. Knowing that UDP >> entails multiple attempts, it would be great to have, say, even attempts on >> wan0 and odd ones on wan1. If that's not possible, perhaps I could look for >> ways to configure it using dscp. Any hint? >> >> >> Best >> Ale >> -- >> >> >> >> >> -- >> 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 -- 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: Controlling which interface named uses
You are over-complicating things. If unconfigured, named binds the outgoing UDP to 0.0.0.0 (::0), which means the chosen IP address is picked by the kernel. You need to configure priorities on your interfaces in the kernel - ip route is your friend. And for goddess’ sake, don’t do anything wild like proposed round robin across default routes. That would be a living hell to debug. Ondřej -- 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 10. 6. 2023, at 18:55, Alessandro Vesely wrote: > > On Fri 09/Jun/2023 18:32:25 +0200 Anand Buddhdev wrote: >>> On 09/06/2023 17:26, Alessandro Vesely wrote: >>> Having two WANs, it would be reasonable, in case one doesn't work, to try >>> the other one. However, it's always useless to try the LAN. Is there any >>> way to configure which interface is used for outgoing queries? >> You can configure "query-source" and "query-source-v6" in named.conf, to >> tell BIND which interface to use for outgoing queries. > > > Thank you, Anand; I hadn't found those statements. However, they take a > single address only. > > I'm not as much concerned about IP version as about availability. Enabling > IPv6 looks nice as I see queries going out through an interface which is not > the default. But will named turn back to the default interface in case the > IPv6 link goes down? > > Keep in mind that links sometimes seem to be up, as they're connected to a > PPP peer or router, for example, but don't actually work. Knowing that UDP > entails multiple attempts, it would be great to have, say, even attempts on > wan0 and odd ones on wan1. If that's not possible, perhaps I could look for > ways to configure it using dscp. Any hint? > > > Best > Ale > -- > > > > > -- > 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: Workaround needed for TSIG Zone Transfer
Hi Rick,
even while I should be destroying message (Sensitivity: Internal.) message, I
am rather going to respond…
Our colleague Tony Finch written nsnotifyd: https://dotat.at/prog/nsnotifyd/
Run this somewhere close to the proprietary server and configure it to send
valid notifies to named. Then configure the non conformant proprietary server
to send notifies to nsnotifyd.
My recommendation would be still to save money by replacing the broken
proprietary stuff with the open source.
Alternatively, perhaps the server can send notifies from a different IP address
than the address of the primary NS? You might be able to configure different
ACLs for the allow-notify block and don’t couple the notify-IP with any TSIG
key.
Ondřej
--
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 9. 6. 2023, at 23:52, Frey, Rick E via bind-users
> wrote:
>
>
> I’ve got a case where using BIND (v9.16.41) as a secondary to a third party
> (commercial) primary nameserver. Using TSIG for the zone transfers. Have
> verified zone transfers and TSIG key using dig between hosts. BIND is
> configured to use TSIG for the primary server using server x.x.x.x { keys
> “somekey”; } directive.
>
> Problem is that the primary server does not sign the response with TSIG for
> the SOA query sent by BIND to determine if update is needed. Since response
> to SOA query is not signed, BIND considers response invalid:
>
> Sample log message when SOA not signed:
> zone some-domain.com/IN: refresh: failure trying master x.x.x.x#53 (source
> 0.0.0.0#0): expected a TSIG or SIG(0)
>
> I know that BIND is not at fault and the primary server is breaking RFC8945
> as any query with TSIG is required to return a TSIG RR in the response.
> Working w/ vendor of the primary nameserver to resolve. The vendor is a
> pretty widely used provider so I’m a bit surprised issue has not occurred
> before now.
>
> Mainly wondering if there is any workaround available to allow BIND to either
> not send TSIG in SOA query to the primary server (but still use TSIG for zone
> transfer) or accept the SOA response w/o TSIG RR. I was unable to find any
> means to configure this behavior in reading through BIND documentation.
>
> Rick
>
> This email message and any attachments are for the sole use of the intended
> recipient(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original message and any
> attachments.
> Sensitivity: Internal
>
> --
> 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
From top of my head - try disabling QNAME minimization. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 1. 6. 2023, at 16:58, Jesus Cea wrote: > > I am getting errors "Name huawei.com (SOA) not subdomain of zone > cloud.huawei.com". The problem raises when requesting on > oauth-login.cloud.huawei.com . The problem was described in the mailing list: > > https://lists.isc.org/pipermail/bind-users/2021-January/104064.html > > BIND is replying with a SERVFAIL. This is correct and appropriate. > Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) other > are not doing that SOA verification, so for users we are the guilty, not > Huawey, because "using Google it works!". In fact, we have a big customer > phone app failing because of this (yes, this seems to be a bug with that app > but, again, "with google it works!"). > > What can we do? Is possible to disable that check in bind? > > We are using 9.16. We could upgrade to 9.18, if needed. > > Thanks. > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > 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: git branches v9_18 vs bind-9.18
Hi, the bind-9.xx branches are current major.minor tracking branches. The old CVS-style branches and tags are kept for the moment until the dust settles and we are sure nothing broke. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 30. 5. 2023, at 13:10, Stacey Marshall wrote: > > Looking at https://github.com/isc-projects/bind9/branches > shows the underscore branches have not been updated in two months, unlike the > dot versions which were updated recently > Does that help? > -- > Stace > On 30 May 2023, at 9:54, MAYER Hans wrote: > > > Dear All, > > looking at https://github.com/isc-projects/bind9 I see there are several > branches. For example there is v9_18 and there is also bind-9.18 > I am asking what is the difference ? When I checkout 'origin/v9_18‘ I get > 9.18.14-dev and for'origin/bind-9.18’ I get 9.18.16-dev So in both cases a > development release. Why ever ? > Looking at GitHub both are active branches. Can someone point me to link > describing the intention for both branches ? > Many thanks in advance. > > // Hans > > > > > -- > > Ing. Dipl.-Ing. Hans Mayer > Systems Analyst > Network Unix Security Team (NUST) > Information and Communication Technologies (ICT) > > International Institute for Applied Systems Analysis (IIASA) > Schlossplatz 1 > A-2361 Laxenburg, Austria > Phone: +43 2236 807 Ext 215 > Mobile: +43 676 83 807 215 > Web: http://www.iiasa.ac.at > E-Mail: hans.ma...@iiasa.at > > Note: If there is a disclaimer or other legal boilerplate in the above > message, it is NULL AND VOID. You may ignore it. > > > > > > > > -- > 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 -- 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 (9.18.14) build / install on macOS Ventura (13.3.1) fails to create dirs or files as expected
I would like to re-iterate what Greg said here - use the Homebrew package.
Using the Homebrew hides some gory details about the system administrators
and could be a good entry to learn how the system administration works.
Otherwise, you need to look at the output that the build process produced,
running `make install V=1` will give you little bit more detail about the
process.
Uploading config.log and providing link to it also help to give us more
information,
so we can help you.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 9. 5. 2023, at 22:57, Greg Choules via bind-users
> wrote:
>
> Hello.
> By far the simplest way to install BIND natively on Mac is to use the
> Homebrew package manager. I have 9.18.14 installed on mine and it works fine.
> The other alternative is to run it from the Docker image. See here for
> details: https://hub.docker.com/r/internetsystemsconsortium/bind9
>
> Hope that helps.
> Greg
>
> On Tue, 9 May 2023 at 21:43, Pacific wrote:
> Installing bind9 (9.18.14) on macOS Ventura (13.3.1) — install is not
> creating a namedb directory nor can I find a boilerplate named.conf.
> Steps taken:
> Downloaded tar directly from isc, saved to a local directory as a user with
> admin privs.
> Steps to build:
> tar xzf bind-9.18.14.tar.gz
> cd bind-9.18.14
> ./configure
>
>
> Config summary reads:
> =
> Configuration summary:
> -
> Optional features enabled:
> Memory allocator: jemalloc
> GSS-API (--with-gssapi)
> DNSSEC validation active by default (--enable-auto-validation)
> -
> Features disabled or unavailable on this platform:
> Small-system tuning (--with-tuning)
> Allow 'dnstap' packet logging (--enable-dnstap)
> GeoIP2 access control (--enable-geoip)
> DNS Response Policy Service interface (--enable-dnsrps)
> Allow 'fixed' rrset-order (--enable-fixed-rrset)
> Very verbose query trace logging (--enable-querytrace)
> Single-query trace logging (--enable-singletrace)
> LMDB database to store configuration for 'addzone' zones (--with-lmdb)
> IDN support (--with-libidn2)
> -
> Configured paths:
> prefix: /usr/local
> sysconfdir: ${prefix}/etc
> localstatedir: ${prefix}/var
>
> Compiler: gcc
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
> Target: arm64-apple-darwin22.4.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> CFLAGS: -Wall -Wextra -Wwrite-strings -Wpointer-arith
> -Wno-missing-field-initializers -Wformat -Wshadow
> -Werror=implicit-function-declaration -Werror=missing-prototypes
> -Werror=format-security -Werror=parentheses -Werror=implicit
> -Werror=strict-prototypes -Werror=vla -fno-strict-aliasing
> -fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2 -pthread
> -Wno-deprecated-declarations
> CPPFLAGS: -D_FORTIFY_SOURCE=2 -I/opt/homebrew/opt/openssl@3/include
> LDFLAGS: -L/opt/homebrew/opt/openssl@3/lib
> —
> After configure completes:
> make
> When make successfully completes, ran test suite:
> sudo ./bin/tests/system/ifconfig.sh up
> make test
> Tests run clean, bring down interface and do make install which runs to
> completion:
> sudo ./bin/tests/system/ifconfig.sh down
> sudo make install
> Install appears to complete successfully, however there is no namedb
> directory in either /etc or /usr/local/etc
> In fact there is no named.conf file anywhere on the system except in the
> source tree.
> Please advise as to where to look or please advise if there are additional
> build steps to take, if configure needs edits, etc.
> Thanks for any assistance.
>
> --
> 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://l
Re: Is it possible to upgrade bind from 9.11 to 9.18 directly?
Hi, I can confirm that it’s ok to skip 9.16 and go straight to 9.18. There’s no need for the intermediate step. As usual, it’s recommended to do a test migration first if you want to be extra careful. Ondrej -- 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 21. 4. 2023, at 9:41, Stacey Marshall wrote: > > > If it helps, my assessment was that one could skip 9.16 too. > > I recognise that this is thanks to the hard effort that ISC work to provide > backward compatibility, and not by some accident. > > On Solaris 11.4 current shipping versions of BIND are > > $ pkg list -fa service/network/dns/bind > NAME (PUBLISHER) VERSION IFO > service/network/dns/bind 9.18.11.0.0-11.4.55.0.1.138.1 --- > service/network/dns/bind 9.16.33.0.0-11.4.54.0.1.138.0 --- > service/network/dns/bind 9.16.33.0.0-11.4.51.0.1.132.0 --- > service/network/dns/bind 9.16.33.0.0-11.4.50.0.1.126.2 --- > service/network/dns/bind 9.16.29.0.0-11.4.48.0.1.126.0 --- > service/network/dns/bind 9.11.37.0.0-11.4.45.0.1.119.0 --- > service/network/dns/bind 9.11.36.0.0-11.4.42.0.1.113.0 --- > ... > > > It is possible to update from Solaris 11.4.45.0.1.119.0 to 11.4.55.0.1.138.1 > and thereby skip 9.16 altogether. > > Regards, > > Stacey > > * 9.18.11 uses OpenSSL v3 > > On 20 Apr 2023, at 17:26, Saleck wrote: > > Hi, > > we are currently running several bind 9.11 servers on Debian buster machines. > We would like to upgrade and wonder if we could skip version 9.16 altogether > or if it's a necessary middle step. > > We have read both > > https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916 > > and > > https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918 > > and it looks like there should be nothing that would break (we use only text > and raw zone file types) if we did the direct 9.11 to 9.18 upgrade. But > better be safe then sorry. Therefore we are seeking advice. ;) > > If it's possible, can anyone confirm zone transfers from master to slave > would still work even if the servers ran different major versions? I know we > won't be able to use TLS until both servers would run 9.18 but would the > regular transfers still work? > > It would help us a great deal if anyone could confirm this or (and) warn us > if there is something that we are missing in our assessment. > > Kind regards, > David Bruha > -- > 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 -- 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: help with notify
> On 17. 4. 2023, at 15:59, Matt Zagrabelny via bind-users > wrote: > > Greetings bind-users, > > I'm running a little older Debian bind: > > bind9 1:9.9.5.dfsg-9 A little older? Debian Jessie reached EOL in June 2018, Debian Jessie LTS reached EOL in June 2020 So, you are running software that hasn't received any update in 3-5 years. Upgrade to current Debian stable, it has a fully-maintained up-to-date BIND 9.16 version in security (1:9.16.37-1~deb11u1) and almost up-to-date BIND 9.18 in backports (the update is currently blocked by the Debian being frozen for the next stable release). Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Fully automated DNSSEC with BIND 9.16
Petr, while I understand that you are trying to do a great job maintaining the BIND 9 packages for RHEL, it is what it is - a random snapshot defined not by the quality of the chosen version but by the time availability. This is made even more complicated by applying a set of patches where the set is defined by the downstream maintainer. The whole idea that something frozen in time with patches applied by distribution maintainer must be more stable than the software actively developed by upstream developers is wrong. This could perhaps work for slow-paced low complex software, but for anything that's reasonably complex (as various network servers and clients are) it's doomed to fail. And what's even worse that people will come, use the distribution package of BIND 9 and think this is the "best" quality they can get. > If he wanted bleeding edge This narrative is wrong. I am not recommending people to run the latest development release - that would be "bleeding edge". The latest stable BIND 9 version is not bleeding edge. You are trying to frame it as it's something dangerous to use the latest version provided by the upstream developers who are in all due respect more knowledgeable about the upstream source code than any downstream package maintainer could be. Sure, that doesn't mean that mistakes doesn't happen, they do, but running latest upstream patch release (or latest stable release) is considerably more safe for BIND 9 than running BIND 9 release that's many version behind, often EOL and with considerable amount of patches[1] applied. So, no, I am not going to stop telling people to stop using packages bundled with a distribution unless the distribution follows the latest patch release. Alternatively, the RedHat can dedicate a support team to triage, answer and fix problems in these versions (taken from DistroWatch): * RHEL 7 - BIND 9.11.4 - released on 2018-07-11 - 33 patch releases behind - EOL since March 2022[2] * RHEL 8 - BIND 9.11.36 - released on 2021-10-27 - 1 patch release behind - EOL since March 2022[2] * RHEL 9 - BIND 9.16.23 - released on 2021-11-17 - 16 patch releases behind And since this is not really going to happen, I will continue people to use upstream sanctioned packages because that will not waste the user time and it will not waste the developers time. > if the only issue in our version is unrelated to the problem investigated? There were 448 merge requests between BIND version 9.16.23 and 9.16.39, and 963 commits. So, how do you know that? I don't and I am certainly not willing to spend my already spread-thin time investigating whether any issue has been fixed in the last year and half, but I would be thrilled to fix any issue found in the latest stable BIND release. We don't make changes to BIND 9 just because we can, there's (usually) a good reason behind every commit and every merge request. 1. https://git.centos.org/rpms/bind/blob/c8s/f/SOURCES 2. https://lists.isc.org/pipermail/bind-announce/2022-March/001210.html Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 17. 4. 2023, at 13:57, Petr Menšík wrote: > > Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he wanted > bleeding edge, he would use RHEL 9 or even Fedora. But he uses conservative > package I am looking after. While it may have some known issues, it has all > important fixes it needs. Can you please stop telling people to not use our > packages, if the only issue in our version is unrelated to the problem > investigated? > > But I admit we should update to more recent BIND 9.16 release already. > > Cheers, > Petr > > On 4/13/23 15:40, Ondřej Surý wrote: >>> On 13. 4. 2023, at 15:25, David Carvalho via bind-users >>> wrote: >>> >>> I'm using 9.16.23 >> Just don't. >> >> ISC provides packages for major linux distributions >> (https://www.isc.org/download/), >> so there's really no reason to shoot yourself into foot to use a random BIND >> 9 >> snapshot provided by your distro. >> >> And while you are at it - upgrade straight to latest 9.18, your experience >> will be much >> smoother. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >> > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with p
Re: Fully automated DNSSEC with BIND 9.16
> On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: RPZ zone response delay time ?
I don’t think we are ever going to implement something like this. This is a wrong layer to fix this. -- 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 10. 4. 2023, at 22:36, Evan Hunt wrote: > > On Fri, Apr 07, 2023 at 05:27:38PM +0100, Jason Vas Dias wrote: >> I will put something like this as a patch into MY named, I just >> wondered if there'd be any interest in adding such a >> 'DelayRPZResponse' NamedConf option for the standard BIND9 release. > > You can put in a feature request at https://gitlab.isc.org/isc-projects/bind9, > and if you submit a patch we'll look at it, but I don't think this is > the right way to do this. Why are you remapping to a blackholed > address, instead of returning NXDOMAIN? > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > -- > 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: Response Policy Zone returns servfail for time.in Trigger
Hi,time.in is currently broken - I am guessing this is the reason why are you trying to rewrite the answers.RPZ does try to resolve the name first, and it fails, so there’s nothing to rewrite.See the documentation https://bind9.readthedocs.io/en/v9.18.13/reference.html#namedconf-statement-response-policy on qname-wait-recurse and break-dnssec to turn off the default behavior.Ondrej--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. 4. 2023, at 16:32, Matthew Gomez wrote:Hi, has anyone run into this before? It looks like a bug to me. SummaryRPZ Returns a servfail when the trigger is "time.in"BIND version usedBIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)Steps to reproduceConfigure a RPZ rule with the trigger as time.in (the action does not seem to matter, I tried both CNAME . and A 1.1.1.1 both fail) Try to resolve time.in against the bind server using dig, nslookup, etc a servfail is returnedWhat is the current bug behavior?Bind returns a servfail when the trigger for an RPZ rule is "time.in" RPZ works as expected for "tim.in" and "time.ind"What is the expected correct behavior?Bind should return the expected action (nxdomain, A record rewrite, etc)Relevant configuration filesRPZ Zone File $TTL 86400 @ IN SOA localhost. root.localhost. ( 12 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL ; @ IN NS localhost.time.in CNAME .named.conf.local snippet zone "rpz.local" { type master; file "/var/lib/bind/rpz.local"; allow-query { localhost; }; allow-transfer { 1.1.1.1; }; also-notify { 1.1.1.1; }; };named.conf.options snippet //enable response policy zone. response-policy { zone "rpz.local"; };Relevant logs and/or screenshotsdig time.in @127.0.0.1; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> time.in @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25602 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: a197e43b329c51e70100643028c76d5822e3f9c2bbcb (good) ;; QUESTION SECTION: ;time.in. IN A;; Query time: 292 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Apr 07 10:29:27 EDT 2023 ;; MSG SIZE rcvd: 64LOG Apr 7 10:30:37 server named[941]: client @0x7f74a80d03b8 127.0.0.1#34415 (time.in): query failed (failure) for time.in/IN/A at query.c:7775
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: Bind dns amplification attack
More likely, it’s a malware used to do a targeted attack rather than insecure routers. Also why not both? ;) Ondrej -- 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 28. 3. 2023, at 10:44, Borja Marcos wrote: > > > >> On 28 Mar 2023, at 09:33, Nyamkhand Buluukhuu wrote: >> >> Hello, >> >> We are having slowly increasing dns requests from our customer zones all >> asking mXX.krebson.ru. I think this is a DNS amplification attack. >> And source zones/IP addresses are different but sending same requests like >> below. > > I wonder, maybe some of your customers have open recursive DNS servers > themselves? Some brands of routers > are unfortunately easy to misconfigure. > > I must play whack-a-mole now and then. > > > > > Borja. > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: PPA for Raspbian distros
Hi, launchpad publishes packages only for Ubuntu, not for Debian and kind-of direct derivatives like Raspbian. If your RPi is at least ARMv7, you can try using: https://bind.debian.net/bind/ Unfortunately, Raspbian armhf is an absolute mess, reusing armhf for architecture name for a different hardware compatibility than Debian’s armhf was wrong, so you need to be careful. Ondrej -- 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 25. 3. 2023, at 3:37, Andrew P. wrote: > > Greetings. > > Per chance, is there a repo of pre-built bind code for the Raspberry Pi > platform? I tried using the PPA specified at > https://launchpad.net/~isc/+archive/ubuntu/bind but it didn't support the > release on my DNS server host (buster). I received the error > > Ign:2 https://ppa.launchpadcontent.net/isc/bind/ubuntu buster InRelease > > Err:3 https://ppa.launchpadcontent.net/isc/bind/ubuntu buster Release > > 404 Not Found [IP: 185.125.190.52 443] > Hit:4 http://archive.raspberrypi.org/debian buster InRelease > > Reading package lists... Done > E: The repository 'https://ppa.launchpadcontent.net/isc/bind/ubuntu buster > Release' does not have a Release file. > N: Updating from such a repository can't be done securely, and is therefore > disabled by default. > N: See apt-secure(8) manpage for repository creation and user configuration > details. > > If I have to compile from source, so be it, but it would be far more > convenient to get a binary build from the authority. > > Andrew Pavlin > -- > 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: Bind not sending notifies for some time
> On 24. 3. 2023, at 14:36, Klaus Darilion via bind-users > wrote: > > Is there some rate liming in Bind? https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-notify-rate -- 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
Re: BIND 9.16.30 - $INCLUDE file in the rpz zone file not reloading content and dig not working
Honestly, it's pretty hard to help you, as you provided only snippets of configuration. If you want the help here, you should provide: 1. full (sanitized) configuration file - named-checkconf -px is your friend 2. full state of the zone before 3. full state of the zone after 4. named.log - at least the parts where it shows loading of the zone, rndc commands and what happens after; increasing debugging level might sometimes help (add -d xx to your named invocation) Without these, we would be just guessing in the dark. Also you are running BIND 9.16.30; the current version that includes all the bugfixes and security fixes is BIND 9.16.39, but our general recommendation is to upgrade to latest 9.18 version (9.18.13 as of now). Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 20. 3. 2023, at 4:53, Nagesh Thati wrote: > > HI, > I am still not able to reload the named with the $include file updated > content. Any help would be appreciated. > Thanks. > > On Fri, Mar 17, 2023 at 12:43 PM Nagesh Thati wrote: > Hi, > I tried syntax, but it didn't work. > Thanks. > > On Fri, Mar 17, 2023 at 11:41 AM Sachchidanand Upadhyay > wrote: > Hi, > > Have you checked the syntax? > > try this: > >$INCLUDE "/var/named/zones/masters/rpz.local.data"; > > Regards, > Sachchidanand > > From: tcpnag...@gmail.com > To: m3...@m3047.net > Cc: bind-users@lists.isc.org > Sent: Friday, March 17, 2023 9:18:32 AM > Subject: Re: BIND 9.16.30 - $INCLUDE file in the rpz zone file not reloading > content and dig not working > > Thanks for the reply Fred Morris, > Yes, even after serial number increment and reconfig and reload also not > picking up the include file data. > > > On Fri, Mar 17, 2023 at 2:45 AM Fred Morris wrote: > Hello > > On Thu, 16 Mar 2023, Nagesh Thati wrote: > > [...] > > When named is restarted using systemctl above rpz rules are working fine, > > but when I add a new rule *nagesh3.com <http://nagesh3.com> A 3.4.5.6 > > * manually in > > the include file and run "rndc reconfig and rndc reload", named is not > > picking up the updated include file and *nagesh3.com <http://nagesh3.com>* > > rpz > > rule is not working. > > Are you incrementing the SOA serial number? > > -- > > Fred Morris, internet plumber > > -- > 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 > -- > 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: Deprecation notice for BIND 9.18: (root-)delegation-only option
> On 23. 3. 2023, at 17:57, Matus UHLAR - fantomas wrote: > > On 22.03.23 17:36, Ondřej Surý wrote: >> in line with our deprecation policy, I am notifying the mailing list about >> our intent >> to deprecated the delegation-only and root-delegation-only options. This is >> again >> adept for expedited deprecation - it will be removed in BIND 9.20 and >> deprecated >> in BIND 9.18. > > what's the reason? Code cleanliness? > Or is it problematic to maintain? Those are wrong questions to ask - the right question to ask is whether this bring any value - and the answer is that it doesn't, then it becomes unmaintained and untested cruft. >> The (root-)delegation-options were introduced as a countermeasure for the >> infamous >> Site Finder by Verisign[1]. With the controversy around this and >> introduction of DNSSEC, >> the likelihood of this happening is infinitesimal. >> >> If you don't even know what those options does, the TL;DR is that it disables >> the non-delegation records for configured domains (TLD), this in turns might >> break legitimate TLDs like .de, .fr, .museum and others [2][3]. >> >> If you know a legitimate reason to keep those options, please describe the >> use case >> here or in the issue mention below. > > well, if "just for sure no other AH tries that again" is not a reason for > you... No, it will not happen again, at least not at the TLD level. The community has learned and ICANN has learned too. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
Deprecation notice for BIND 9.18: (root-)delegation-only option
Hi, in line with our deprecation policy, I am notifying the mailing list about our intent to deprecated the delegation-only and root-delegation-only options. This is again adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated in BIND 9.18. The (root-)delegation-options were introduced as a countermeasure for the infamous Site Finder by Verisign[1]. With the controversy around this and introduction of DNSSEC, the likelihood of this happening is infinitesimal. If you don't even know what those options does, the TL;DR is that it disables the non-delegation records for configured domains (TLD), this in turns might break legitimate TLDs like .de, .fr, .museum and others [2][3]. If you know a legitimate reason to keep those options, please describe the use case here or in the issue mention below. This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/3953 1. https://en.wikipedia.org/wiki/Site_Finder 2. https://circleid.com/posts/the_name_domain_disrupted_by_site_finder_patch 3. https://www.afnic.fr/en/observatory-and-resources/news/warning-for-bind-and-delegation-only-users/ 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
Re: BIND Process failed during logrotate
Peter, > On 22. 3. 2023, at 14:40, White, Peter wrote: > > First of all, is this script part of the normal BIND distribution, or is it > part of the RHEL 7 distribution? From what I can tell, it is called weekly. This is RH's script > Any thoughts on what could have caused this on two secondaries? The primary > reloaded around the same time without incident. This is ancient version patches with multiple security patches: > running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 My advices would be either to talk to RedHat (if you have a support contract) or use ISC BIND 9 packages, I would recommend upgrading straight to the latest BIND 9.18 (with proper testing, etc..). The packages are available from: https://www.isc.org/download/ (See the paragraph just above the table.) Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: RPZ answer me NXDOMAIN for some domain
> On 22. 3. 2023, at 14:26, BONIN Nathanael wrote: > > If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted > to !!! Thanks. +1 > But what I don’t understand is why, when I use directly SrvA (server that > have RPZ zone), it works ? That's something that's impossible to answer without seeing the full configuration (named-checkconf -px). Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: RPZ answer me NXDOMAIN for some domain
Hi, look for break-dnssec in https://bind9.readthedocs.io/en/stable/reference.html#response-policy-zone-rpz-rewriting -- 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 22. 3. 2023, at 12:52, BONIN Nathanael wrote: > > > Hi there, > > We are using RPZ zone for some times now, but recently we found a weird > behavior from some domains. Let me explain ! > > We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind > (let’s call him SrvB, with global forwarder : SrvA ). My RPZ zone is on SrvA. > > If we took a little diagram, we have : > > User = > SrvB = > SrvA = > Internet > > If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist at > google.com) on RPZ zone : > > On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5 => GREAT ! > On SrvB with : dig @localhost tatata.google.com (that point on SrvA), we got > IP : 2.3.4.5 => WONDERFUL ! > > BUT > > If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t > exist at biopyrenees.net) on RPZ zone : > > On SrvA with : dig @localhost sri.biopyrenees.net, we got IP : 3.4.5.6 => > YOUPI ! > On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN => > WHA ? > > Why for some domain, the RPZ isn’t working ? > > An exemple of what I wrote on my RPZ zone : > > tatata.google.com A 2.3.4.5 > sri.biopyrenees.net A 3.4.5.6 > > Is it normal ? Is there a way to have the good answer on my SrvB ? > > With tcpdump, I see the same behavior with a record that works and with the > record that doesn’t work… > > Thanks for your help. > > Nath. > > > > > > -- > 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: How to use update-policy type "external"
> I am not sure how to start debugging this. Can anyone help?
Well, start with sharing as much details as you can. It’s hard to tell what you
are doing from a single configuration line.
Ondrej
--
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 14. 3. 2023, at 19:00, Vladimir Brik
> wrote:
>
> Thanks, quoting worked!
>
> Does anybody know if the socket of an "external" update-policy supposed to
> receive data for every dynamic DNS update?
>
> I `strace`ed the `named` process and pushed some updates using nsupdate, but
> I saw no attempts to do anything with the socket file (no opens, no writes)
> and nothing related to the socket in the logs either.
>
> I am not sure how to start debugging this. Can anyone help?
>
>
> Vlad
>
>
>> On 3/14/23 11:06, Ondřej Surý wrote:
>> I haven't used this personally, but in the system tests, this works:
>>update-policy {
>>grant administra...@example.nil wildcard * A SRV CNAME;
>>grant testden...@example.nil wildcard * TXT;
>>grant "local:/tmp/auth.sock" external * CNAME;
>>};
>> e.g. you need to quote the path.
>> The documentation is silent on NAME field, but I would suggest using either
>> * or . as placeholder.
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>> My working hours and your working hours may be different. Please do not feel
>> obligated to reply outside your normal working hours.
>>>> On 14. 3. 2023, at 16:56, Vladimir Brik
>>>> wrote:
>>>
>>> Hello
>>>
>>> I am trying to set up an "external" dynamic DNS update policy but I can't
>>> figure out the syntax.
>>>
>>> The documentation [1] says that the "identity" field needs to be in the
>>> form local:PATH, but using something like the following results in an
>>> error: "expected unquoted string near '/'", and I don't know how to fix it.
>>>
>>> update-policy {
>>>grant local:/tmp/sock external NAME txt;
>>> };
>>>
>>> Also, the documentation doesn't say how NAME is interpreted. Is it ignored?
>>>
>>>
>>> Thanks very much
>>>
>>> Vlad
>>>
>>>
>>> [1]
>>> https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-update-policy
>>> --
>>> 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
--
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: How to use update-policy type "external"
I haven't used this personally, but in the system tests, this works:
update-policy {
grant administra...@example.nil wildcard * A SRV CNAME;
grant testden...@example.nil wildcard * TXT;
grant "local:/tmp/auth.sock" external * CNAME;
};
e.g. you need to quote the path.
The documentation is silent on NAME field, but I would suggest using either *
or . as placeholder.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 14. 3. 2023, at 16:56, Vladimir Brik
> wrote:
>
> Hello
>
> I am trying to set up an "external" dynamic DNS update policy but I can't
> figure out the syntax.
>
> The documentation [1] says that the "identity" field needs to be in the form
> local:PATH, but using something like the following results in an error:
> "expected unquoted string near '/'", and I don't know how to fix it.
>
> update-policy {
>grant local:/tmp/sock external NAME txt;
> };
>
> Also, the documentation doesn't say how NAME is interpreted. Is it ignored?
>
>
> Thanks very much
>
> Vlad
>
>
> [1]
> https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-update-policy
> --
> 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: Bind listener to an IPv6 from AnyIP subnet
Hi, > On 13. 3. 2023, at 10:37, Michael Richardson wrote: > > Signed PGP part > > m...@at.encryp.ch wrote: >> Regarding the usage of [::] - due to usage of firewall I am able to >> block connections to the 53/udp and 53/tcp which are not coming to >> specific IP addresses or ranges, I do not need such filtering >> functionality within bind itself. > > Bind doesn't listen to specific sockets because of security. > It does so because of connectivity and plumbing. > > I think you are making your life hard for no benefit. Basically, what Michael said... The AnyIP is not compatible with a way how BIND 9 discovers where it should listen (via route socket). Also it's much simpler and faster then calling getsockname(2) (a syscall!) on every incoming UDP packet[1]. You can probably write a firewall rules (conntrack) to rewrite the destination addresses from the AnyIP range to single local address (DNAT) or if you are feeling really fancy I think this could be also accomplished with an eBPF rule. Ondrej 1. Or implement an extra logic to see whether the bound interface is "wildcard" or not. -- 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. signature.asc Description: Message signed with OpenPGP -- 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
Deprecation notice force BIND 9.20+: TKEY Mode 2 (Diffie-Hellman Exchanged Keying)
Hello, in line with out deprecation policy, I am notifying the mailing list about our preliminary intent to deprecate the TKEY Mode 2 - Diffie-Hellman Exchanged Keying. This mode is adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated in BIND 9.18 The draft-eastlake-dnsop-rfc2930bis-tkey (in progress) specifies: > 4.2 Diffie-Hellman Exchanged Keying (Deprecated) > > The use of this mode (#2) is NOT RECOMMENDED for the following two > reasons but the specification is still included in Appendix A in case > an implementation is needed for compatibility with old TKEY > implementations. See Section 4.6 on ECDH Exchanged Keying. > > The mixing function used does not meet current cryptographic > standards because it uses MD5 [RFC6151]. > > RSA keys must be excessively long to achieve levels of security > required by current standards. We are going to implement the advice from the draft and completely remove the TKEY DH implementation from BIND 9. In BIND 9.20: 1. Using tkey-dhkey option in named.conf will be now a fatal error 2. Using dnssec-keygen -a DH will be now a fatal error 3. Using dnssec-keyfromlabel -a DH will be now a fatal error In BIND 9.18: 1. Using tkey-dhkey option in named.conf will issue a deprecation warning Users are advised to switch to TKEY Mode 3 (GSS-API). Removing this insecure algorithm that should not be used anyway will reduce an attack surface. This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/3905 Thanks. -- 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
Re: Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Tom, the ADB (Address DataBase) responsible for caching the delegations had been heavily refactoring in 9.19 branch, I think the best course of action would be to fill a GitLab issue with the description, so we can follow-up there. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 2. 2023, at 10:03, Tom wrote: > > Hi list > > Using BIND-9.19.10: > > An A-query on our resolver for "ns2.comtronic.ch" causes the following info > in the named.log, after the first response was answered to the client and > cached and then the entry is flushed from cache with "rndc flushname > ns2.comtronic.ch": > 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving > 'ns2.comtronic.ch/A' > > > The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks > like this (after flushing the cached name with "rndc flushname > ns2.comtronic.ch"): > > # Client query > 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? > ns2.comtronic.ch. (57) > > # Query from the resolver to the authoritative server for A > 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] > A? ns2.comtronic.ch. (45) > > > # Querying TLD nameserver for A and > 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] > ? ns2.comtronic.ch. (45) > 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? > ns2.comtronic.ch. (45) > > # Response from the authoritative > 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- > 1/0/1 A 195.200.242.162 (61) > > # Response back to the client > 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A > 195.200.242.162 (89) > > > # Delegations back from the TLD nameserver for the A and query > 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 > (695) > 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 > (695) > > > # Query against another authoritative for A and > 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] > ? ns2.comtronic.ch. (45) > 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] > A? ns2.comtronic.ch. (45) > > > # Answer back from the authoritative (no record found for > "ns2.comtronic.ch) > 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 > A 195.200.242.162 (61) > 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- > 0/1/1 (96) > > > > BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. > BIND-9.18.12 doesn't query for lookup after flushing the name, where > BIND-9.19.10 always does with the same configuration..., why? > See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced > "loop detection resolving" info (after flushing the name with "rndc flushname > ns2.comtronic.ch"): > > # Query from the client > 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? > ns2.comtronic.ch. (57) > > # Query from the resolver to the authoritative > 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] > A? ns2.comtronic.ch. (45) > > # Query from the resolver to the TLD server > 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] > A? ns2.comtronic.ch. (45) > > # Response back from the authoritative server > 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- > 1/0/1 A 195.200.242.162 (61) > > # Response back to the client > 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A > 195.200.242.162 (89) > > # Delegation answer from the TLD server > 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- > 0/10/10 (695) > > # A 2nd query to the same authoritative > 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% > [1au] A? ns2.comtronic.ch. (45) > > # 2nd response back from the authoritative server > 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- > 1/0/1 A 195.200.242.162 (61) > > > > The info "loop detected resolving" is always reproducable in BIND-9.19.10 > after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. > > So my questions are: > - What does "loop detected resolving 'ns2.comtronic.ch/A' means here?
Re: Simplistic serial number roll back
Well, the serial number arithmetics is there for a reason - you usually don’t want to rollback to previous version of the zone - you can have multiple primaries with different serial numbers.I don’t really consider the two step rollover of the serial number that complicated, so something extra needs to be put in place. And it’s something you don’t really do on a daily basis.Ondrej--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 17. 2. 2023, at 20:34, John Thurston wrote:
That was my first thought, but stopping the secondary would
affect all of the published zones.
If retransfer ignores serial number, then using "rndc retransfer"
would affect only the specifically-named zone in the
specifically-named view. Resolution of the other zones, in all of
the other views, would be uninterrupted.
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
On 2/17/2023 10:23 AM, Ondřej Surý
wrote:
CAUTION: This email originated from
outside the State of Alaska mail system. Do not
click links or open attachments unless you recognize
the sender and know the content is safe.
Why so complicated? Stop the secondary, purge the zone files
and journal, and start the secondary. The zones will get
retransfered as there’s no state now.
--
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 17. 2. 2023, at 20:18, John
Thurston wrote:
Assumptions: A primary and several secondaries, with the
secondaries using XFR to stay up to date.
Scenario: Make a change in the serial number algorithm
which will result in newer zone-data being published on an
"earlier" serial number.
The 'correct' method is to increase the serial number
(by steps not exceeding 0x7FFF) until it rolls back
around to the desired number. These increments are to
happen no more frequently than the refresh interval
specified in the SOA record. This 'correct' method relies
on nothing more than the communication standards defined
in RFC.
But if we add the assumption: All authorities are running
ISC BIND software, and all are under central management.
can the whole process be reduced to publishing the new
serial number on the primary, and using an "rndc
retransfer" on each secondary?
The man-file says "retransfer . . . This command
retransfers the given secondary zone from the primary
server."
It doesn't say serial number is considered, nor does it
does it say that it is ignored. I'm thinking it makes
sense that it ignores the serial number, but I can't think
of a good way to test this.
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
--
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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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 mai
Re: Simplistic serial number roll back
Why so complicated? Stop the secondary, purge the zone files and journal, and start the secondary. The zones will get retransfered as there’s no state now.--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 17. 2. 2023, at 20:18, John Thurston wrote: Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method is to increase the serial number (by steps not exceeding 0x7FFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of a good way to test this. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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: Ubuntu service file is missing Restart parameter
Those are maintained by Ubuntu, not ISC, so you need to contact them. Or you can use packages provided by ISC: https://kb.isc.org/docs/isc-packages-for-bind-9 Ondrej -- 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 5. 2. 2023, at 15:46, Blažej Krajňák wrote: > > Hi Ondrej, > > sorry, I really thought it's clear enough, but as I just found, the > problem presents in releases for Ubuntu 20.04, 18.04 and maybe older > also. > > It's all about the content of /lib/systemd/system/named.service > > Release for Ubuntu Jammy 22.04 LTS (1:9.18.1-1ubuntu1.3) contains > "Restart=on-failure" parameter. > > Releases for >Ubuntu Focal 20.04 LTS (1:9.16.1-0ubuntu2.12) >Ubuntu Bionic 18.04 LTS (1:9.11.3+dfsg-1ubuntu1.18) > and maybe older also are missing "Restart" parameter. > > I found this problem with friend, when Bind9 on Ubuntu 20.04 exited > with SIGV signal and keeps down (systemd did not restart the service). > > > Thanks > > > ne 5. 2. 2023 o 14:18 Ondřej Surý napísal(a): >> >> Hi, >> >> it might seem like we do practice black magic, but we really don’t. Thus we >> can’t really help if you don’t provide more details like the content of the >> file, the source of the package(s), and the version of the package(s). >> >> Ondrej >> -- >> 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 5. 2. 2023, at 13:29, Blažej Krajňák wrote: >>> >>> Hi there, >>> >>> I just discovered that default Bind9 systemd service file for Ubuntu >>> is missing "Restart" parameter. Is there any reason? >>> Service file for Debian contains "Restart=on-failure" >>> >>> >>> Thanks >>> Blažej >>> -- >>> 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: Ubuntu service file is missing Restart parameter
Hi, it might seem like we do practice black magic, but we really don’t. Thus we can’t really help if you don’t provide more details like the content of the file, the source of the package(s), and the version of the package(s). Ondrej -- 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 5. 2. 2023, at 13:29, Blažej Krajňák wrote: > > Hi there, > > I just discovered that default Bind9 systemd service file for Ubuntu > is missing "Restart" parameter. Is there any reason? > Service file for Debian contains "Restart=on-failure" > > > Thanks > Blažej > -- > 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: filter-a and dns64 in a ipv6-only network
> On 1. 2. 2023, at 13:33, Thomas Schäfer wrote: > > I have learned bind/isc is not willing to support such (test) scenarios. And yet again, let me emphasize that open-source isn't free Swedish buffet. If you want other people to do the work it must either have a strong case (like being useful to more than a single person on planet earth) or incentivised in some other way. Neither was presented here, you just came here telling us that we should not tell you what to do because you know the best. Ok, your choice, your consequences. Nobody is preventing from doing the work yourself, or paying somebody for doing the work for you. That's where the open-source model shines. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Docker image
Hi, Yes, it is. Ondřej -- 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 27. 1. 2023, at 19:07, Elias Pereira wrote: > > > hi, > > Is this docker image official? > > https://hub.docker.com/r/internetsystemsconsortium/bind9 > > -- > Elias Pereira > -- > 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: Gratuitous AXFRs of RPZ after 9.18.11
> On 27. 1. 2023, at 1:49, John Thurston wrote: > And now when I study my xfer.log more closely, the behavior changed this > morning when I completed the update from 9.18.10 -> 9.18.11 > I'm not yet ready to revert, because this isn't affecting my business (this > is a really small zone). Is anyone else seeing similar behavior Hi John, FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause the described behaviour. That said - in addition to what Greg said, I would suggest increasing the log level to small debug levels if you can and perhaps something will stand out Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: I need to find statistics on a running server.
It's generally better to pull the server statistics via statistics channel via XML or JSON that can be directly parsed by many commonly available libraries and tools. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 12. 1. 2023, at 20:25, King, Harold Clyde (Hal) via bind-users > wrote: > > Thank you very much. I forgot about rndc stats > > > -- > > Hal King - h...@utk.edu <mailto:h...@utk.edu> > Systems Administrator > Office of Information Technology > Shared Services > > The University of Tennessee > 103c5 Kingston Pike Building > 2309 Kingston Pk. Knoxville, TN 37996 > Phone: 974-1599 > > From: Howard, Christopher > Sent: Thursday, January 12, 2023 1:42 PM > To: bind-users@lists.isc.org ; King, Harold Clyde > (Hal) > Subject: Re: I need to find statistics on a running server. > > You can use "rndc stats" to have bind dump a file with stats in it. This is > how I get stats from our servers. I store the values every 2 minutes and > create a dashboard from that. Stuff like total queries, total queries from > ipv4 clients, total queries from ipv6 clients, total > A//CNAME/PTR/NXDOMAIN requests/answers. With it stored every 2 minutes > it's easy to chart out number per second, of course that's averaged out over > the 2 minute window. > > -Christopher > > > On Thu, 2023-01-12 at 18:30 +, King, Harold Clyde (Hal) via bind-users > wrote: >> That's not bad idea. >> >> >> -- >> >> Hal King - h...@utk.edu >> Systems Administrator >> Office of Information Technology >> Shared Services >> >> The University of Tennessee >> 103c5 Kingston Pike Building >> 2309 Kingston Pk. Knoxville, TN 37996 >> Phone: 974-1599 >> >> From: Jeff Sumner >> Sent: Thursday, January 12, 2023 1:22 PM >> To: King, Harold Clyde (Hal) ; bind-users >> >> Subject: Re: I need to find statistics on a running server. >> >> You don't often get email from kc4...@gmail.com. Learn why this is important >> <https://aka.ms/LearnAboutSenderIdentification> >> I’ve turned on query logging, then grepped for the count of lines logged in >> a particular second. >> >> Worked well enough for the job at the time. >> >> J >> >> De: bind-users em nome de "King, Harold >> Clyde (Hal) via bind-users" >> Responder A: "King, Harold Clyde (Hal)" >> Data: quinta-feira, 12 de janeiro de 2023 1:20 PM >> Para: bind-users >> Assunto: I need to find statistics on a running server. >> >> I need to find some answers like queries per second. Any fast ideas folks? >> >> -- >> >> Hal King - h...@utk.edu >> Systems Administrator >> Office of Information Technology >> Shared Services >> >> The University of Tennessee >> 103c5 Kingston Pike Building >> 2309 Kingston Pk. Knoxville, TN 37996 >> Phone: 974-1599 >> >> -- 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 -- 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: Deprecation notice for BIND 9.18: Differentiated Services Code Point (DSCP) support
> On 5. 1. 2023, at 14:46, Robert M. Stockmann wrote: > > On Thu, 5 Jan 2023, [utf-8] Ondřej Surý wrote: > >> There's an alternative plan that would include re-implementing the >> functionality, but there would have to be strong user case behind the >> work. But again, judging from the fact that nobody has noticed, there >> doesn't seem to be strong user base behind DSCP. > > [...] > > This is like Mercedes Benz announcing they will only sell > the Baby Benz model, which is a Volkswagen EV barebonez with > the VW logo replaced with a plastic Mercedes Benz star I've asked for a strong use-case and all I've got was a snark. Do you actually have a real-world use for DSCP or are you just in bad mood? Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
Deprecation notice for BIND 9.18: Differentiated Services Code Point (DSCP) support
Hi, in line with our deprecation policy, I am notifying the mailing list about our intent to deprecated the Differentiated Services Code Point (DSCP) support in BIND 9. The DSCP support in BIND 9 has been already non-operational since BIND 9.16 as the support for setting the DSCP socket option was not implemented in the new networking code for the listening sockets, and since BIND 9.18 when the outgoing DNS code started using the new networking code. So far, nobody has noticed. There's an alternative plan that would include re-implementing the functionality, but there would have to be strong user case behind the work. But again, judging from the fact that nobody has noticed, there doesn't seem to be strong user base behind DSCP. The deprecation will include: * specifying the **dscp** option in following statements: - `also-notify` - `catalog-zones` - `dual-stack-servers` - `forwarders` - `listen-on` - `listen-on-v6` - `notify-source` - `notify-source-v6` - `parental-source` - `parental-source-v6` - `query-source` - `query-source-v6` - `transfer-source` - `transfer-source-v6` - `parental-agents` - `primaries` - ` * following statements as whole: - `dscp` We plan to mark the options as deprecated in BIND 9.16 and 9.18 and remove it in BIND 9.20 because it's already non-operational. Cheers, -- 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
Deprecation notice force BIND 9.20+: source port(s)
Hi, in line with out deprecation policy, I am notifying the mailing list about our preliminary intent to deprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections. Specifying outgoing ports is a bad practice, it's already discouraged, it's prone to errors (it's not only specifying single port, but specifying not enough ports removes a layer of protection) and is already full of caveats like: .. note:: The address specified in the :any:`query-source` option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port. .. warning:: Specifying a single port is discouraged, as it removes a layer of protection against spoofing errors. .. warning:: The configured :term:`port` must not be the same as the listening port. The deprecation will include: * specifying **port** in following statements: - `query-source` - `query-source-v6` - `transfer-source` - `transfer-source-v6` - `notify-source` - `notify-source-v6` - `parental-source` - `parental-source-v6` * following statements as whole: - `use-v4-udp-ports` - `use-v6-udp-ports` - `avoid-v4-udp-ports` - `avoid-v6-udp-ports` These options will be marked as deprecated in BIND 9.20[1][2] and removed in BIND 9.22[3]. 1. BIND 9.20 will be released early 2024 2. Most probably we will also enable the warning in BIND 9.18 to notify users that skip versions. 3. BIND 9.22 will be release in early 2026 Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys vs trust-anchors
Hi Bob, no manually configured bind.keys file is needed. Just don't provide one and correct compiled-in defaults will be used. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 2. 1. 2023, at 13:33, Bob McDonald wrote: > > I've upgraded to bind 9.16.36. > > I went to the ISC site and picked up the bind.keys file. > > However, it is intended for use in bind 9.11 and contains the managed-keys > clause. This throws an error in the syslog messages during startup. It > appears to still function correctly. > > In the ARM for bind 9.16 it states that managed-keys clause is deprecated. > Replacing the managed-keys clause with the trust-anchors clause seems to fix > the issue. In the file itself it states the following: > > # This file is NOT expected to be user-configured. > > Perhaps I've missed something. If not, the documentation needs to be a bit > more clear on this. Would it be helpful to have a version of the bind.keys > file for bind 9.16 and above? > > Regards, > > Bob > -- > 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
