Re: Building bind 9.19.24 on Openwrt w/ MUSL
Hi Philip, we'll need more. Ideally fill an issue, follow the bug template and attach config.log as a bare minimum. -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 1. 6. 2024, at 23:19, Philip Prindeville via bind-users > wrote: > > Hi, > > Having some more issues building 9.19.24 on MUSL. configure.ac isn't > correctly detecting the following: > > ac_cv_func_setresuid=yes > ac_cv_type_size_t=yes > ac_cv_type_ssize_t=yes > ac_cv_type_uintptr_t=yes > > And even passing this manually via ./configure's environment isn't causing it > to work... it's showing as the wrong value and not "(cached)". > > I wouldn't have noticed except that the included replacement for setresuid() > dies in compilation with a warning about it being declared as static and then > later defined as non-static or some such. > > Anyone else had problems with autoconf and cross-compilation w/ MUSL? > > I wanted to do a bump on bind to pick up this fix: > > https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 > > Thanks, > > -Philip > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Building bind 9.19.24 on Openwrt w/ MUSL
Hi, Having some more issues building 9.19.24 on MUSL. configure.ac isn't correctly detecting the following: ac_cv_func_setresuid=yes ac_cv_type_size_t=yes ac_cv_type_ssize_t=yes ac_cv_type_uintptr_t=yes And even passing this manually via ./configure's environment isn't causing it to work... it's showing as the wrong value and not "(cached)". I wouldn't have noticed except that the included replacement for setresuid() dies in compilation with a warning about it being declared as static and then later defined as non-static or some such. Anyone else had problems with autoconf and cross-compilation w/ MUSL? I wanted to do a bump on bind to pick up this fix: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Thanks, -Philip -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
To the last windows Bind
Eagle-Eye Cherry - Save Tonight (youtube.com) <https://www.youtube.com/watch?v=Nntd2fgMUYw> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: named fails to start with bind-9.18.0
No idea what OS or product. This is a compile, as in build the binary, or a daemon run issue? For myself I have an Ubuntu base and am running IND 9.18.x. Not locally compiled. I have found journalctl, systemctl, bind logs and /usr/bin/named-checkconf and named-checkzone to be very useful. From: bind-users On Behalf Of John Thurston Sent: Tuesday, May 21, 2024 2:15 PM To: bind-users@lists.isc.org Subject: Re: named fails to start with bind-9.18.0 ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Assurance you are actually trying to compile current code. A statement of what your operating system is. Actual output of your compile steps. Actual logged output of your attempt to launch. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov<mailto:john.thurs...@alaska.gov> Department of Administration State of Alaska On 5/20/2024 8:10 PM, avijeet gupta wrote: Please let me know if more information is needed. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named fails to start with bind-9.18.0
Assurance you are actually trying to compile current code. A statement of what your operating system is. Actual output of your compile steps. Actual logged output of your attempt to launch. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 5/20/2024 8:10 PM, avijeet gupta wrote: Please let me know if more information is needed.-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named fails to start with bind-9.18.0
As Ondrej said. Upgrade. You compiled BIND 9.18.0. That is 27 release behind current. Unless you are doing archaeological investigations of old code you shouldn’t be trying to use old code like that. Running newer code means that you can avoid all the bugs that have been fixed in the meantime. Named logs what it finds wrong to syslog by default. Read your logs. You can also run named in the foreground and send the logs to stderr. named -g -c /etc/named.conf’ Due to Linux’s co-operating processes as its threading model, named can’t just daemonize once it has finished its startup phase. It has to daemonize then finish its startup. The parent process waits for the startup to complete and then exits with an appropriate error code. Somewhere in that startup something has failed. Mark > On 21 May 2024, at 14:10, avijeet gupta wrote: > > My Apologies. I was just trying to show the snippet of bind library code > where named was failing. > > I am trying to run named after compiling the bind library. The command I use > to run named is as follows: > > /bin/named -c /etc/named.conf > > It appears that it is failing when it tries to daemonize named. what could be > causing it ? > > named will eventually run as daemon in my dns server. > > Please let me know if more information is needed. > > Thanks, > Avi > > > > On Mon, May 20, 2024 at 10:47 AM Ondřej Surý wrote: >> Can someone please help what could be the issue here? > > > Not really. First start by using the latest 9.18 version and not something > that’s two years old and then you need to provide more information than a > screenshot of random code snippet. If you want free help you need to provide > information about what you are actually doing. > > This old essay is still true: > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > 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 20. 5. 2024, at 17:55, avijeet gupta wrote: >> >> Hi All, >> >> I compiled bind-9.18.0 successfully but when I try to run named via >> configuration file, named exits with return code 1. >> >> The below code in bin/named/os.c is where it is failing. >> >> >> >> >> When i run named with gdb , i see that it is exiting in the above code. >> >> Can someone please help what could be the issue here? >> >> Thanks, >> Avij >> >> -- >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >> this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named fails to start with bind-9.18.0
My Apologies. I was just trying to show the snippet of bind library code where named was failing. I am trying to run named after compiling the bind library. The command I use to run named is as follows: /bin/named -c /etc/named.conf It appears that it is failing when it tries to daemonize named. what could be causing it ? named will eventually run as daemon in my dns server. Please let me know if more information is needed. Thanks, Avi On Mon, May 20, 2024 at 10:47 AM Ondřej Surý wrote: > Can someone please help what could be the issue here? > > > Not really. First start by using the latest 9.18 version and not something > that’s two years old and then you need to provide more information than a > screenshot of random code snippet. If you want free help you need to > provide information about what you are actually doing. > > This old essay is still true: > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > 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 20. 5. 2024, at 17:55, avijeet gupta wrote: > > > Hi All, > > I compiled bind-9.18.0 successfully but when I try to run named via > configuration file, named exits with return code 1. > > The below code in bin/named/os.c is where it is failing. > > > > > When i run named with gdb , i see that it is exiting in the above code. > > Can someone please help what could be the issue here? > > Thanks, > Avij > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://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: named fails to start with bind-9.18.0
> Can someone please help what could be the issue here? Not really. First start by using the latest 9.18 version and not something that’s two years old and then you need to provide more information than a screenshot of random code snippet. If you want free help you need to provide information about what you are actually doing. This old essay is still true: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html 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 20. 5. 2024, at 17:55, avijeet gupta wrote: > > > Hi All, > > I compiled bind-9.18.0 successfully but when I try to run named via > configuration file, named exits with return code 1. > > The below code in bin/named/os.c is where it is failing. > > > > > When i run named with gdb , i see that it is exiting in the above code. > > Can someone please help what could be the issue here? > > Thanks, > Avij > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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
named fails to start with bind-9.18.0
Hi All, I compiled bind-9.18.0 successfully but when I try to run named via configuration file, named exits with return code 1. The below code in bin/named/os.c is where it is failing. [image: image.png] When i run named with gdb , i see that it is exiting in the above code. Can someone please help what could be the issue here? Thanks, Avij -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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]how to configure ecs subnet for bind-9.18-21
OK. Firstly, the bad news. ECS is only available in the subscription version of BIND. That is, versions ending with -S. To get this version you need a (paid) support contract with ISC. If you are interested, let me know. Secondly, 9.18.21 is not current. I would recommend that you use the latest version, which is 9.18.26 (you can see in your screenshot). I hope that helps. Greg > On 28 Apr 2024, at 08:42, Yang <395096...@qq.com> wrote: > > > > is v.9.18.21 below this reference >  > > > > Yang > 395096...@qq.com > > <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage=true=Yang=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287=395096713%40qq.com=> > > > > -- Original -- > From: "Greg Choules" ; > Date: Sun, Apr 28, 2024 03:39 PM > To: "Yang"<395096...@qq.com>; > Cc: "bind-users"; > Subject: Re: [help]how to configure ecs subnet for bind-9.18-21 > > Hello. > Do you mean 9.18-S1? > > >> On 28 Apr 2024, at 08:06, Yang via bind-users >> wrote: >> >> >> dear admin: >> now, i use bind-9.18-21, i want to use ecs client subnet function; but i >> don't know how to configure it, and i don't get method from google >> please give me some example,or document , or google links to learn about >> it ; >> thanks! >> >> Yang >> 395096...@qq.com >> >> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage=true=Yang=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287=395096713%40qq.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: [help]how to configure ecs subnet for bind-9.18-21
Hello. Do you mean 9.18-S1? > On 28 Apr 2024, at 08:06, Yang via bind-users > wrote: > > > dear admin: > now, i use bind-9.18-21, i want to use ecs client subnet function; but i > don't know how to configure it, and i don't get method from google > please give me some example,or document , or google links to learn about it > ; > thanks! > > Yang > 395096...@qq.com > > <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage=true=Yang=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287=395096713%40qq.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
[help]how to configure ecs subnet for bind-9.18-21
dear admin: now, i use bind-9.18-21, i want to use ecs client subnet function; but i don't know how to configure it, and i don't get method from google please give me some example,or document , or google links to learn about it ; thanks! Yang 395096...@qq.com-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
> The facts are: > > * 191.131.in-addr.arpa is served from awsdns Correct. And it's delegated to from the 131.in-addr.arpa zone, maintained by ARIN. > * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com > and ns102.click-network.com above the zone cut. Correct. > * Below the zone cut the nameserver claims to be authoritative for its > parent's zone (191.131.in-addr.arpa) instead of > 85.191.131.in-addr.arpa. (In other words it's lame.) Well, yes. When queried for the NS set for 85.191.131.in-addr.arpa it returns "NOERROR" with the 191.131.in-addr.arpa SOA record in the authority section. This is what is called an "upward referral", and indicates that the delegation structure and/or child name server setup is inconsistent with the delegation structure. Were I less charitable I would say "messed up". Basically what you say above -- it doesn't serve the delegated zone so is "lame". > * (Below the zone cut it also erroneously advertises one of its > nameservers as simply ns102. instead of ns102.click-network.com) Yep. > * There is no server which actually advertises itself as authoritative > for 85.191.131.in-addr.arpa Yep. Both of the resolveable NSes ns102.click-network.com and fs838.click-network.com claim authority over 191.131.in-addr.arpa, which they don't have according to the parent zone DNS delegations. Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Trace from my location dies even earlier: ;; Received 915 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 17 ms ;; connection timed out; no servers could be reached Again just a data point. > On 24 Apr 2024, at 22.03, tale via bind-users > wrote: > > Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: > > 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. > 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. > couldn't get address for 'fs838.click-network.com': not found > couldn't get address for 'ns102.click-network.com': not found > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users 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
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
As further data points with BIND as a caching / recursive sometimes it "works" and provides inconsistent AUTHORITY, although anecdata suggests this is more prevalent with older versions of BIND. In one case BIND 9.12 reports the AUTHORITY as the parent zone in fact, with the parent's nameservers. The facts are: * 191.131.in-addr.arpa is served from awsdns * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com and ns102.click-network.com above the zone cut. * Below the zone cut the nameserver claims to be authoritative for its parent's zone (191.131.in-addr.arpa) instead of 85.191.131.in-addr.arpa. (In other words it's lame.) * (Below the zone cut it also erroneously advertises one of its nameservers as simply ns102. instead of ns102.click-network.com) * There is no server which actually advertises itself as authoritative for 85.191.131.in-addr.arpa 9.18.21 with "qname-minimization disabled; minimal-responses no;": ; <<>> DiG 9.18.21 <<>> @127.0.0.1 -x 131.191.85.31 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45088 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1420 ; COOKIE: 95f68497698c23e20100662bd448c6b1f33814567a34 (good) ;; QUESTION SECTION: ;31.85.191.131.in-addr.arpa.IN PTR ;; ANSWER SECTION: 31.85.191.131.in-addr.arpa. 604800 IN PTR flame.m3047.net. ;; AUTHORITY SECTION: 85.191.131.in-addr.arpa. 1799 IN NS ns102.click-network.com. 85.191.131.in-addr.arpa. 1799 IN NS fs838.click-network.com. ;; ADDITIONAL SECTION: fs838.click-network.com. 172799 IN A 131.191.7.194 ns102.click-network.com. 172799 IN A 131.191.7.12 ;; Query time: 1620 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Apr 26 09:20:24 PDT 2024 ;; MSG SIZE rcvd: 201 9.12.3 offering two different responses: ; <<>> DiG 9.12.3-P1 <<>> -x 131.191.85.31 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20212 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ; COOKIE: 22623b3f260659f6699dc2ae662bcf96945739b2062b578d (good) ;; QUESTION SECTION: ;31.85.191.131.in-addr.arpa.IN PTR ;; ANSWER SECTION: 31.85.191.131.in-addr.arpa. 183024 IN PTR flame.m3047.net. ;; AUTHORITY SECTION: 191.131.in-addr.arpa. 49595 IN NS ns-986.awsdns-59.net. 191.131.in-addr.arpa. 49595 IN NS ns-7.awsdns-00.com. 191.131.in-addr.arpa. 49595 IN NS ns-1603.awsdns-08.co.uk. 191.131.in-addr.arpa. 49595 IN NS ns-1165.awsdns-17.org. ;; ADDITIONAL SECTION: ns-7.awsdns-00.com. 106009 IN A 205.251.192.7 ns-986.awsdns-59.net. 110789 IN A 205.251.195.218 ns-1165.awsdns-17.org. 110789 IN A 205.251.196.141 ns-1603.awsdns-08.co.uk. 110789 IN A 205.251.198.67 ;; Query time: 1 msec ;; SERVER: 10.0.0.220#53(10.0.0.220) ;; WHEN: Fri Apr 26 09:00:22 PDT 2024 ;; MSG SIZE rcvd: 334 ; <<>> DiG 9.12.3-P1 <<>> -x 131.191.85.31 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42172 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ; COOKIE: 166de4c8b3f9b189d0aad8b9662bd608135dc2782eb1138a (good) ;; QUESTION SECTION: ;31.85.191.131.in-addr.arpa.IN PTR ;; ANSWER SECTION: 31.85.191.131.in-addr.arpa. 181374 IN PTR flame.m3047.net. ;; AUTHORITY SECTION: 85.191.131.in-addr.arpa. 1794 IN NS ns102.click-network.com. 85.191.131.in-addr.arpa. 1794 IN NS fs838.click-network.com. ;; ADDITIONAL SECTION: fs838.click-network.com. 294IN A 131.191.7.194 ns102.click-network.com. 294IN A 131.191.7.12 ;; Query time: 1 msec ;; SERVER: 10.0.0.220#53(10.0.0.220) ;; WHEN: Fri Apr 26 09:27:52 PDT 2024 ;; MSG SIZE rcvd: 201 Housekeeping: the version of DiG above also changes, but this is not simply the version of dig: # dig @127.0.0.1 version.bind ch txt +short "9.18.21" # dig version.bind ch txt +short "9.12.3-P1" There are other oddities, for instance the actual authoritative TTL for the nameservers appears to be 300 not 172799: # rndc flush # dig @127.0.0.1 click-network.com ns ; <<>> DiG 9.18.21 <<>> @127.0.0.1 click-net
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
They've got a number of problems. click-network.com is one of them. https://dnsviz.net/d/click-network.com/dnssec/ There is some backstory. The City of Tacoma used to run broadband, and that was Click! Network. The origin story is that this had something to do with SCADA or power distribution, but who knows? They have a /16, and it appears half of it is available to broadband customers. Anyway they privatized it and subsequently sole-sourced that. Like many businesses today, IT appears to be outsourced and the suppliers for various services do strange things sometimes. Here's the verbose log that 9.18.21 spits out in conjunction with the SERVFAIL: 24-Apr-2024 08:43:35.587 resolver: notice: DNS format error from 131.191.7.194#53 resolving 85.191.131.in-addr.arpa/NS for : Name 191.131.in-addr.arpa (SOA) not subdomain of zone 85.191.131.in-addr.arpa -- invalid response 24-Apr-2024 08:43:35.587 lame-servers: info: FORMERR resolving '85.191.131.in-addr.arpa/NS/IN': 131.191.7.194#53 24-Apr-2024 08:43:35.603 resolver: notice: DNS format error from 131.191.7.12#53 resolving 85.191.131.in-addr.arpa/NS for : Name 191.131.in-addr.arpa (SOA) not subdomain of zone 85.191.131.in-addr.arpa -- invalid response 24-Apr-2024 08:43:35.603 lame-servers: info: FORMERR resolving '85.191.131.in-addr.arpa/NS/IN': 131.191.7.12#53 I'm not saying it's the wrong thing to do, although to borrow someone else's line that may be like arguing over the particular weasels chosen rather than the decision to stuff rabid weasels down your pants in the first place. -- Fred Morris On Wed, 24 Apr 2024, tale wrote: Hmm, I wonder if qname-minimisation is at issue here. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. couldn't get address for 'fs838.click-network.com': not found couldn't get address for 'ns102.click-network.com': not found -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Observation: BIND 9.18 qname-minimization strict vs dig +trace
While BIND 9.18.21 with "qname-minimization strict;" SERVFAILs on the following query, dig with +trace resolves it. Just a data point, and if they fix their s**t and stop impersonating a signed zone then presumably the example will resolve itself (pun intended). dig -x 131.191.85.31 dig -x 131.191.85.31 +trace -- 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
Re: BIND 9.16 is approaching EOL in April, 2024
> On Mar 11, 2024, at 4:09 PM, John Thurston wrote: > > I assume the day is approaching when the packages in the COPR repositories > will be changed; isc/bind-esv will have 9.18 (instead of 9.16), and ics/bind > will have 9.20 > > So that we might start weaving this into our maintenance plans, is there a > projected date on which this will happen? > I think this will happen in May - because we plan to release our last 9.16 package in April. > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov <mailto:john.thurs...@alaska.gov> > Department of Administration > State of Alaska > On 2/26/2024 7:35 AM, Victoria Risk wrote: >> The BIND 9.16 release branch is approaching EOL as of April, 2024. We >> encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. >> >> The 9.18 branch has consistently out-performed the 9.16 branch, and we are >> confident that it is more stable than 9.16. One of our support engineers has >> prepared a helpful knowledgebase article on updating from 9.16 to 9.18 >> (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918) >> which may be useful to you as you plan your migration. >> >> For an overview of our release plan, we maintain another knowledgebase >> article (https://kb.isc.org/docs/aa-00896). This was updated earlier this >> month, to move the start of future new stable branches from Q1 to Q2. The >> problem with starting a new stable branch in Q1 is, after the long holiday >> quiet period, we always have a number of important fixes and changes we need >> to release *before* we can start a new stable branch. We are currently >> projecting that our next stable branch, BIND 9.20, will be released in Q2. >> >> For your convenience, we also maintain our planned EOL dates listed next to >> each software release on https://www.isc.org/download/. >> >> Vicky Risk > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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 9.16 is approaching EOL in April, 2024
I assume the day is approaching when the packages in the COPR repositories will be changed; isc/bind-esv will have 9.18 (instead of 9.16), and ics/bind will have 9.20 So that we might start weaving this into our maintenance plans, is there a projected date on which this will happen? -- 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/26/2024 7:35 AM, Victoria Risk wrote: The BIND 9.16 release branch is approaching EOL as of April, 2024. We encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. The 9.18 branch has consistently out-performed the 9.16 branch, and we are confident that it is more stable than 9.16. One of our support engineers has prepared a helpful knowledgebase article on updating from 9.16 to 9.18 (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918 <https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918>) which may be useful to you as you plan your migration. For an overview of our release plan, we maintain another knowledgebase article (https://kb.isc.org/docs/aa-00896 <https://kb.isc.org/docs/aa-00896>). This was updated earlier this month, to move the start of future new stable branches from Q1 to Q2. The problem with starting a new stable branch in Q1 is, after the long holiday quiet period, we always have a number of important fixes and changes we need to release *before* we can start a new stable branch. We are currently projecting that our next stable branch, BIND 9.20, will be released in Q2. For your convenience, we also maintain our planned EOL dates listed next to each software release on https://www.isc.org/download/ <https://www.isc.org/download/>. Vicky Risk-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01/03/2024 11:02, Jim Reid wrote: On 1 Mar 2024, at 10:37, Greg Choules via bind-users wrote: In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best +1 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 force BIND 9.20+: "rrset-order fixed" and "sortlist"
> On 1 Mar 2024, at 10:37, Greg Choules via bind-users > wrote: > > In summary, Do the hard work of traffic steering somewhere else and let your > DNS resolvers deliver the chosen answer. Don't make the resolvers themselves > try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 force BIND 9.20+: "rrset-order fixed" and "sortlist"
2nd $beverage consumed. I have never liked sortlist since I inherited it 16 years ago in my previous job. For me it suffers from at least one fundamental problem: - If a client, say at location "1", is given a bunch of sorted A records with the server at location "1" first, what does the client do when the server at location "1" is down? Clients come in many varieties. Some are capable of cacheing multiple answers, timing out and trying a different one, some are not. This leads to service reliability issues because, even though a perfectly healthy instance of the service may exist at site "2", clients (at site "1") are still told by DNS, go to site "1" The DNS service is not (by default) either application or client-aware. It just gives the answers you tell it to, whether they're working or not. If you want an efficient, reliable multi-site service, use load-balancers that can direct traffic from local clients to a local service instance, or use an application aware DNS server (I can think of one; I'm sure others exist) that monitors availability, delay and whatever other metrics are important and feeds the DNS resolvers with *the* answer they want them to give to a client at this moment in time. ECS would even allow said box to be aware of client location, to use as an additional metric when making this decision. In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. On Fri, 1 Mar 2024 at 10:12, G.W. Haywood wrote: > Hi there, > > On Fri, 1 Mar 2024, Matus UHLAR wrote: > > On 01.03.24 08:24, Ond?ej Sur? wrote: > > > 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. > > > > I don't know about _requirement_, but I have used this option as poor > > man's way to implement geographically local IP addresses > > - to anyone return topologically closer IP addresses first, others next. > > Maybe I need more of my morning $beverage but this sort of thing seems > to me to militate against other - existing - efficiency mechanisms. > > Network performance isn't just about topology, there are things like > performance and load to consider. Might your tweaked responses just > send clients to a nearby but tragically overloaded server? > > My preference would be to let those people whose job it is to think > about this stuff - which, reading this list, clearly they do - get on > with their job. > > Observations welcome of course. > > -- > > 73, > Ged. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://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 force BIND 9.20+: "rrset-order fixed" and "sortlist"
Hi there, On Fri, 1 Mar 2024, Matus UHLAR wrote: On 01.03.24 08:24, Ond?ej Sur? wrote: > 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. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. Maybe I need more of my morning $beverage but this sort of thing seems to me to militate against other - existing - efficiency mechanisms. Network performance isn't just about topology, there are things like performance and load to consider. Might your tweaked responses just send clients to a nearby but tragically overloaded server? My preference would be to let those people whose job it is to think about this stuff - which, reading this list, clearly they do - get on with their job. Observations welcome of course. -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01.03.24 08:24, Ondřej Surý wrote: 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. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. I found it especially nice because it doesn't matter which service are we using - if there are multiple IP's for _anything_, return topologically closer first. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: BIND Upgrade
We are working intensively at Red Hat to finally fix that version. A huge thanks goes to ISC, which kindy provided complex backport into 9.11 version, which they do not support for a long time. It was discovered those changes require also changes to bind-dyndb-ldap used in freeipa and also may break dhcp without rebuilds. Because we use bind rebuild also for dhcp, which were fixed already. It should be fixed soon finally. We are sorry this is taking us so long, but those changes are not trivial to make. Especially without additional regressions. If you can use bind9.16 package instead, that would be fixed earlier. Regards, Petr On 15. 02. 24 13:53, Semra Türkkal Nazlımoğlu wrote: Hello, Our bind version seems below. How can we upgrade bind version? And if we upgrade bind version, is there any problem? [root@ns2 ~]# named -v BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) Thanks Semra -- Petr Menšík Software Engineer, RHEL Red Hat,http://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 paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.16 is approaching EOL in April, 2024
The BIND 9.16 release branch is approaching EOL as of April, 2024. We encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. The 9.18 branch has consistently out-performed the 9.16 branch, and we are confident that it is more stable than 9.16. One of our support engineers has prepared a helpful knowledgebase article on updating from 9.16 to 9.18 (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918) which may be useful to you as you plan your migration. For an overview of our release plan, we maintain another knowledgebase article (https://kb.isc.org/docs/aa-00896). This was updated earlier this month, to move the start of future new stable branches from Q1 to Q2. The problem with starting a new stable branch in Q1 is, after the long holiday quiet period, we always have a number of important fixes and changes we need to release *before* we can start a new stable branch. We are currently projecting that our next stable branch, BIND 9.20, will be released in Q2. For your convenience, we also maintain our planned EOL dates listed next to each software release on https://www.isc.org/download/. Vicky Risk-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 Upgrade
Hi there, On Fri, 16 Feb 2024, Semra T?rkkal Nazl?mo?lu wrote: Our bind version seems below. How can we upgrade bind version? And if we upgrade bind version, is there any problem? Recently I upgraded from 9.11.26 (not 9.11.36) to 9.18.24 using the source from the ISC Website. It's a very small setup here. The only thing I needed to do to the configuration was remove a single obsolete option (dnssec-enable) from named.conf. -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 Upgrade
Hi, You don't need to use the RHEL version of BIND. ISC supplies packages that you can add as described here: https://kb.isc.org/docs/isc-packages-for-bind-9 Thank you, Darren Ankney On Thu, Feb 15, 2024 at 8:02 AM Marco Moock wrote: > > Am 15.02.2024 schrieb Semra Türkkal Nazlımoğlu > : > > > Our bind version seems below. How can we upgrade bind version? > > It comes from the OS you are using. > Upgrade to the current RHEL release. > If you prefer bleeding-edge versions, use Fedora instead. > > > And if we upgrade bind version, is there any problem? > > Install the new OS in a virtual machine and try running BIND there with > your configuration/zones and check for any errors. > In most cases, the upgrade works without any problems. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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 Upgrade
Am 15.02.2024 schrieb Semra Türkkal Nazlımoğlu : > Our bind version seems below. How can we upgrade bind version? It comes from the OS you are using. Upgrade to the current RHEL release. If you prefer bleeding-edge versions, use Fedora instead. > And if we upgrade bind version, is there any problem? Install the new OS in a virtual machine and try running BIND there with your configuration/zones and check for any errors. In most cases, the upgrade works without any problems. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND Upgrade
Hello, Our bind version seems below. How can we upgrade bind version? And if we upgrade bind version, is there any problem? [root@ns2 ~]# named -v BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) Thanks Semra -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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}
On Fri, Dec 22, 2023 at 05:43:09PM +0100, Ond??ej Surý wrote: >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???) There is a lot of momentum in our organization. Take timekeeping. There is local time, UTC, TAI, GPS time, Julian time, modified Julian time, nutation sidereal time, mean sideral time, Greenwich sideral time, modified local sidereal time, and probably more I can't remember. We have to keep track of contintal drift because of General Relativity with regards to timekeeping, and our most demanding applications require femtosecond accuracies in the clocks (which isn't possible with today's technology). Not only do we use all of those timekeeping standards in different places, but we also invented our own timekeeping standard back in the 1970s that we still use and is one of our main ways of keeping track of things. Some groups here here don't trust DHCP. They started out soldering and wirewraping IP addresses into boards that are inaccessible in the bowels of the machines, but have progressed to selectable IP addresses controlled by dip switches inside brass boxes that have up to 206 screws holding them closed. The modern data stream uses ethernet, but I'm told not ethernet collisions. It was deemed better to time every packet from every device so that no collisions ever happen in the ethernet network. But containers are something we plan to try soon! This coming calendar year actually. Using one for RHEL6.5 to support Xilinx is high on my list. --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
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
Problems with openssl pkgconfig in bind 9.18.21 (but probably all 9.18)
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
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
On Wed, Dec 06, 2023 at 04:05:03PM -0800, Fred Morris wrote: > They don't seem well documented. Indeed they are not! > I say go ahead, if nothing else consider it a "scream test". But can you > take a moment and tell us which stakeholder group(s) you think you're > optimizing for, why, and how? In this case, merely optimizing for the number of things we on the BIND development team need to test and maintain. I really don't think anyone's using these knobs, so they might as well not be there. They were added during the development process for serve-stale, which came to us originally as a third-party contributed patch. I suspect they were used by the contributors for testing, but nobody on our team ever did, or gathered any of the data that would be needed to properly document them. So they really should have been stripped out of the patch before it was merged. You do raise a good point - there may be reasons for different sites to want to teak these settings. Iif so, though, they we should probably add the tuning to named judiciously, after a proper research and data-gathering process, instead just accidentally leaving it there. :) -- 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
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
Hi there, On Fri, 8 Dec 2023, Fred Morris wrote: I welcome birds of a feather. Need to define / refine the problem statement first. ... ... Er, tweet! Up to my @$$ in aligators and can't afford the time to more than chime in here, but this is all absolutely fascinating. Fwiw I'd love to see it played out on this list (if the Ps that B think it appropriate). -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: "resolver-nonbackoff-tries", "resolver-retry-interval"
On 07. 12. 23 22:12, Fred Morris wrote: I welcome birds of a feather. Need to define / refine the problem statement first. On 12/7/23 12:30 AM, Petr Špaček wrote: On 07. 12. 23 1:05, Fred Morris wrote: On Wed, 6 Dec 2023, Evan Hunt wrote: I say go ahead, if nothing else consider it a "scream test". But can you take a moment and tell us which stakeholder group(s) you think you're optimizing for, why, and how? On the technical level we optimize using real (anonymized!) traffic provided to us by operators. Here's what we need: https://kb.isc.org/docs/collecting-client-queries-for-dns-server-testing If you want us to optimize for your use-case let's talk how we can get the data and replicate your setup! I run Dnstap (for $reasons), but I'd be able to run dnscap and from the look of that KB page you only want the queries. I'm not sure that really captures the qualitative issue(s). I plan to dig into this some more over the winter anyway, maybe I should turn the tables and ask if there are other systemic issues I should look at or for? We are certainly interested in hearing what metric is of interest and what we might be missing. Right now we monitor everything we can from statistics provided by DNS Shotgun [1], BIND statistics channel [2], and system resource monitoring [3]. [1] https://dns-shotgun.readthedocs.io/en/stable/ [2] https://bind9.readthedocs.io/en/v9.19.18/reference.html#namedconf-statement-statistics-channels [3] https://gitlab.isc.org/isc-projects/resource-monitor/-/blob/main/resmon.yaml -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: "resolver-nonbackoff-tries", "resolver-retry-interval"
th of a second is acceptable, there's time to wait for the database and no need for the additional complexity. Some datastores might take even longer than that (nobody cares about happy eyeballs in that use case). What is the reason for caching resolvers? We see proposals to do prefetch for answers which are soon to expire from cache. If the network is slow enough that that matters, and it works, why the continued obsession with superfast authoritative responses? If this is a prefetch, is the retry schedule less aggressive? Aggressive UDP retry mints unique requests. Anecdotally it has been observed that the aggressive retries from caching resolvers directed at authoritatives mint new queries (query id) for each retry. (I have to ask because of the next item on the list) is this a de-optimization in the name of privacy? The same application (caching resolver) is issuing what are as far as the protocol is concerned different queries which presumably could have come from different applications on the same host. If there's a full-blown recursive resolver living on the host wouldn't those apps avail themselves of the resource? Personally I would hope so. So can the authoritative server debounce (reply to only one request within some time period), or does it have to reply to each and every one of them on the offchance that they're coming from different applications? (And if they're using the stub resolver, shouldn't it be caching? And if they're not using the stub resolver, maybe their "very good reason" should include dealing with whatever the issue is and not passing it off to the DNS? Or if they're not, maybe a competent sysadmin should be sandboxing that app with a caching resolver in front of it?) Qname minimization generates more requests. Without explaining in detail what qname minimization is for or what it entails, traditionally a DNS query contains the full accurate query when sent to every authoritative server regardless of whether or not it is conceivable that that server can answer the query rather than providing a referral; with qname minimization this is not the case and the query is tailored to the type of response(s) the authoritative server is anticipated to be able to provide. Aside from the additional traffic, the crux of most of what can go wrong happens with empty non-terminals. Empty non-terminals are comparatively rare in the portions of the namespace utilized for FQDN -> address mapping. Based on this observation maybe it should be limited to that use case? Why aren't there tuning / configuration options around this? (Won't be surprised if there are for at least some implementations.) If this resonates with you, feel free to reach out. If you use the trualias morris.dns.systems.thinking@m3047.net that will help me manage things if there are more than a handful of interested parties. -- 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
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
On 07. 12. 23 1:05, Fred Morris wrote: On Wed, 6 Dec 2023, Evan Hunt wrote: I say go ahead, if nothing else consider it a "scream test". But can you take a moment and tell us which stakeholder group(s) you think you're optimizing for, why, and how? On the technical level we optimize using real (anonymized!) traffic provided to us by operators. Here's what we need: https://kb.isc.org/docs/collecting-client-queries-for-dns-server-testing If you want us to optimize for your use-case let's talk how we can get the data and replicate your setup! -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: "resolver-nonbackoff-tries", "resolver-retry-interval"
They don't seem well documented. Even in the ARM for 9.12 they're listed as options but no explanation is provided. It's easy to suspect that nobody is going to use an option which isn't documented (unless they're of a mind to browse sourcecode). This could be a self-fulfilling assumption. On Wed, 6 Dec 2023, Evan Hunt wrote: In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "resolver-nonbackoff-tries" and "resolver-retry-interval" options in named. [...] They are not thought to be useful in a production environment, and we know of no operators using them. (Please let us know if this is incorrect!) Exactly who is the "user", anyway? Am I to assume that "operator" is supposed to mean "somebody administering a naming service in conjunction with internet resources (addresses) to be located with said naming service? The default aggressive retry profile suggests that it's all about addresses and "happy eyeballs". However as an example email doesn't need that level of aggression, either for locating SMTP servers or for filtering done with such as SPF or DANE. And how about all of the PYLM TXT records (and all of those SPF includes)? The behavior of qname minimization in an environment with a lot of empty non-terminals strongly suggests that things are increasingly optimized towards namespaces which don't have a lot of them; and is there any problem domain addressed by the DNS where that is more the case than name to address mapping? (Counterexample: PTR records, now more than ever.) I say go ahead, if nothing else consider it a "scream test". But can you take a moment and tell us which stakeholder group(s) you think you're optimizing for, why, and how? Thanks... -- 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
Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "resolver-nonbackoff-tries" and "resolver-retry-interval" options in named. These options fine-tune query retry behavior in the resolver for testing purposes. They are not thought to be useful in a production environment, and we know of no operators using them. (Please let us know if this is incorrect!) Our plan is to mark these options as deprecated in BIND 9.16 and 9.18, and to remove them as of BIND 9.20. -- 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
Re: Question on ISC BIND DNS Server
On Thu, 23 Nov 2023 at 00:07, Matus UHLAR - fantomas wrote: > > On 22.11.23 23:44, Turritopsis Dohrnii Teo En Ming wrote: > >I have Virtualmin / Webmin web hosting server control panel. I have 2 > >Virtual Private Servers in Germany and 1 Virtual Private Server in > >Japan. > > > >Can I upgrade BIND DNS Server manually? Will it cause problems with > >Virtualmin / Webmin? > > > I think this is question for webmin/virtualmin, but from what I know about > webmin it tends to edit local configuration, so I guess it will edit primary > zone file. > Noted I will try to ask at the Virtualmin/Webmin mailing list. Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 on ISC BIND DNS Server
On 22.11.23 23:44, Turritopsis Dohrnii Teo En Ming wrote: I have Virtualmin / Webmin web hosting server control panel. I have 2 Virtual Private Servers in Germany and 1 Virtual Private Server in Japan. Can I upgrade BIND DNS Server manually? Will it cause problems with Virtualmin / Webmin? I think this is question for webmin/virtualmin, but from what I know about webmin it tends to edit local configuration, so I guess it will edit primary zone file. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question on ISC BIND DNS Server
Subject: Question on ISC BIND DNS Server Good day from Singapore, I have Virtualmin / Webmin web hosting server control panel. I have 2 Virtual Private Servers in Germany and 1 Virtual Private Server in Japan. Can I upgrade BIND DNS Server manually? Will it cause problems with Virtualmin / Webmin? Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com GIMP also stands for Government-Induced Medical Problems. <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Virus-free.www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
So here is a theory if a client asks a query and bind goes out for that query and the reply is delayed but you get the answer then for what ever reason the reply to the client from bind is delayed more! So the quicker the answer the quicker the answer to the client. Why? I have no idea? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
and this from dig maybe a routing iusse why it take so long for me? C:\Program Files\ISC BIND 9\bin>dig @213.227.191.1 router14.teamviewer.com +norecurs ; <<>> DiG 9.16.45 <<>> @213.227.191.1 router14.teamviewer.com +norecurs ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36405 ;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router14.teamviewer.com. IN A ;; ANSWER SECTION: router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com. routerpool14.rlb.teamviewer.com. 120 IN A 188.172.235.146 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.13.137 routerpool14.rlb.teamviewer.com. 120 IN A 34.17.240.4 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.21.139 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.234.165 ;; Query time: 3106 msec ;; SERVER: 213.227.191.1#53(213.227.191.1) ;; WHEN: Mon Nov 20 18:49:09 GMT Standard Time 2023 ;; MSG SIZE rcvd: 177 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
This is the thing the setup works for many site fast just this Teamviewer and their DNS servers are a problem and bind does reply to 192.168.53.19 all be it 26 seconds later! but Teamviewer trys over and over then it connects yet the for the WAN side took under 4 seconds to get the answer WAN side https://ufile.io/6ofm19ng -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
Have you checked the routeing table on this server? Without any other evidence, this looks to me like packets are going places you aren't expecting. In the first screenshot the query goes to 213.227.191.1 and apparently a response doesn't come back until 4s later. When I try it using dig I get an immediate response: ; <<>> DiG 9.18.17 <<>> @213.227.191.1 router14.teamviewer.com +norecurs ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32608 ;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router14.teamviewer.com. IN A ;; ANSWER SECTION: router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com. routerpool14.rlb.teamviewer.com. 120 IN A 188.172.219.139 routerpool14.rlb.teamviewer.com. 120 IN A 188.172.198.141 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.232.103 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.246.104 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.4.136 ;; Query time: 11 msec ;; SERVER: 213.227.191.1#53(213.227.191.1) (UDP) ;; WHEN: Mon Nov 20 17:40:22 GMT 2023 ;; MSG SIZE rcvd: 177 In the second screenshot you see no response to #60. My suspicion again is that it went somewhere you weren't monitoring, or just wasn't routed at all. I would capture ALL packets, not just DNS, on ALL interfaces. See if you can see where key packets are going, whether you receive ICMP unreachables or retries etc. Also do some tests. If you have BIND you should also have dig. If you don't have dig, use Windows nslookup in interactive mode and send queries to the teamviewer NSs. Right now I would prove that the network is clean first. I see no reason to suspect BIND at the moment. Cheers, Greg On Mon, 20 Nov 2023 at 17:40, legacyone via bind-users < bind-users@lists.isc.org> wrote: > This might show the problem even more on two interfaces WAN side and LAN > you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62 > gets a answer # 75 and no reply back to 192.168.53.19 > > https://ufile.io/v8oob3jg > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://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
This might show the problem even more on two interfaces WAN side and LAN you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62 gets a answer # 75 and no reply back to 192.168.53.19 https://ufile.io/v8oob3jg -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
On starting Teamviewer it can say no connection when bind does the lookup with this delay it cause bind to not reply LAN side sometimes which causes the app to fail yet with a bind on Ubuntu there is no problem. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
I'm just using bind to do my DNS look ups with no forwarders thats all Teamviewer app uses DNS to find its servers from what I can tell it can take over 4000ms to get a answer. The following seems to help in bind resolver-retry-interval 5000; I think if I can then find a setting in windows to do the same thing that might help even over here is what I see from Wireshark https://ufile.io/q0kxqltc -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
Hi there. Can you send some information, for those unfamiliar with what you're trying to do? - Full BIND config - IP addresses of relevant things, like interfaces of the servers on which you are running BIND and of Teamviewer. - What does Teamviewer need from DNS? What kinds of queries is it making and to where? A binary pcap would be very useful. - Is this an AD environment? i.e. do you have Domain Controllers and other such AD components? - How are your Windows boxes configured to use DNS? What IP address(es) do they get given and what are those addresses? Diagnosing a problem is difficult if you only have snippets of information to work from. Cheers, Greg On Mon, 20 Nov 2023 at 13:48, legacyone via bind-users < bind-users@lists.isc.org> wrote: > Now its not working fast again! I don't know now must be Teamviewer DNS > delaying replies causing windows bind to fail in some way. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://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
Now its not working fast again! I don't know now must be Teamviewer DNS delaying replies causing windows bind to fail in some way. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
So more tests and the problem has come back but I think I know why thinking internet sharing was the problem I found a way to disable it because it bind shared access for port 53 on 0.0.0.0 so that the problem I think now after testing with it on. For any interested MS has made it really hard to disable ICS on windows 11 I have tried many ways to disable it all over the web none worked but what did work was to delete the start key for: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
I'm by no means an expert in DNS or how it fully works so I can't be of any more help about this problem then I already have. But it seems Teamviewer have rebooted their DNS servers and now windows bind allows the Teamviewer to load faster -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
Problem with recursion for windows bind for Teamviewer
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
Re: BIND-9.10.2-P4: Cannot use in-view to refer to RPZ zone definitions: "'$RPZ_ZONE' is not a master or slave zone"
I know this is an incredibly old thread, but I was wondering if there has been
any progress on this topic within the last 8 years.
I am attempting to use views to offer different configurations of RPZ filtering
to different subsets of the user population. My original approach was having
multiple named processes running on different ports, with PF redirecting port
53 to the appropriate port based on the user's source IP.
Some of my RPZ zones are quite large, and if the same zone records exist for
multiple configurations, this means loading a lot of the same data into
multiple processes, resulting in long startup times and very high memory
utilization. So I wanted to use views to reduce named to a single process, and
define RPZ zones that can be shared among multiple views using the "in-view"
config.
I'm using a config like the following:
view Child {
match-clients { Child; };
allow-recursion { any; };
response-policy { zone "cf1"; zone "cf2"; };
zone "cf1" {
type master;
file "cf1";
};
zone "cf2" {
type master;
file "cf2";
};
};
view Teen {
match-clients { Teen; };
allow-recursion { any; };
response-policy { zone "cf1"; };
zone "cf1" {
in-view Child;
};
};
Since the rpz for cf1 is large, I want to only have to load/keep a single copy
of it in memory and reference it from both the Child and Teen views. However
the above configuration gives me the error:
response-policy zone 'cf1' for view B is not a master or slave zone
If I add "type master;" to the cf1 zone in view B, I get
zone 'cf1': 'in-view' used with incompatible zone options
So it appears my goal is still not achievable, unless I'm missing something.
Is there some other mechanism to achieve this end result (sharing zones between
different user populations without loading multiple copies of the zone into
memory)?
I am currently running BIND 9.16.44 by the way.
Thanks for any advice!
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://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
Can we enable serve-stale parameter in bind
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
Re: 9.18 BIND not resolving .gov.bd site
Hello All The problem of the .gov.bd domain resolution has been successfully resolved. In the zone file configuration, there was a forward entry for .gov.bd, and after commenting out those lines, all .gov.bd domains are now functioning correctly. Thank you all for providing the right guidance that helped us pinpoint the issue." root@ns1:/# dig mofa.gov.bd +trace \ ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> mofa.gov.bd +trace ;; global options: +cmd . 452497 IN NS m.root-servers.net. . 452497 IN NS i.root-servers.net. . 452497 IN NS e.root-servers.net. . 452497 IN NS g.root-servers.net. . 452497 IN NS l.root-servers.net. . 452497 IN NS a.root-servers.net. . 452497 IN NS j.root-servers.net. . 452497 IN NS b.root-servers.net. . 452497 IN NS c.root-servers.net. . 452497 IN NS f.root-servers.net. . 452497 IN NS h.root-servers.net. . 452497 IN NS d.root-servers.net. . 452497 IN NS k.root-servers.net. . 452497 IN RRSIG NS 8 0 518400 2023111205 2023103004 46780 . KOSvh8dmDkcY070FSYz+vAkH6BC+ZR4nGbEu0plshkZZX47oFXFpsHTJ /LiU7G7KXp6gE+g+QDcHk/HPEljGFNY5RwvzQaCjHGG063ypr+Huj1vJ 0SR03fSwm1FALKZ0EFNI2aIfpxY/1S8xc2HzZmHuneQcp7mTY7i+KtOY z8ljk2jQbdCjHYPg/AgIPtF2+507LnFScSCTw+zOVFYFktoPHyy/wDIk 3G0VQQIQG5+1kjn7YZl1yuyxiSqJhq1+7tSkrL3AKhA4fJtynJcBbZsw dq3mVHPfARjUjby2WNt/M2clERoo+W/zYsZpkKamUpvTNm6gYnnt2xUV 8F5/Ow== ;; Received 1137 bytes from 202.84.32.22#53(202.84.32.22) in 0 ms bd. 172800 IN NS surma.btcl.net.bd. bd. 172800 IN NS dns.bd. bd. 172800 IN NS bd-ns.anycast.pch.net. bd. 172800 IN NS jamuna.btcl.net.bd. bd. 86400 IN DS 26044 8 2 BD01C4B4345D21FC38AA88129F7BC00FDD7B422799CC6703736E3B38 1F37DD5B bd. 86400 IN DS 26044 8 1 2DAD1B7F8CA778464F536FDDD15EFD24CCCB62EF bd. 86400 IN RRSIG DS 8 1 86400 2023111217 2023103016 46780 . IFF4dDc0UEceikw9rf2bEaz/4LZtyCHeKAxX+gD8okseRzK1EcheFZ53 m8ZJtUa/ptVRIm6Hvwc8HTq7KeRKoCULw2isoqB/gNJDc+PasE0/2Uq8 vEY0CCPJad/zKRAjSXxkI6tmvOt3a3Mk6soTIOFCiK0eITwx2sJsdIGZ /wL3cfaqSHh1735dWtg0kWFstyesSida7YHjNyOsJ/X/mUMEInhFdHzR mg3Sa64FUy8BamA/yTUazNb3VG3yRS9ZUFJXeMib7qjSspDEqb2dTKzy RvFxiNKOD5rDoCN3/Da6hi/dBhCLL9Zh+6mhsV0KHLahoKI2Bl2xw2v3 F9hFyA== ;; Received 722 bytes from 192.36.148.17#53(i.root-servers.net) in 51 ms mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. ;; Received 146 bytes from 204.61.216.108#53(bd-ns.anycast.pch.net) in 0 ms mofa.gov.bd.38400 IN A 103.163.210.117 mofa.gov.bd.38400 IN A 103.163.210.121 mofa.gov.bd.38400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.38400 IN NS ns2.bcc.gov.bd. ;; Received 146 bytes from 114.130.54.124#53(ns2.bcc.gov.bd) in 0 ms Regards Mosharaf Hossain Manager, Product Development IT Division Bangladesh Export Import Company Ltd. Level-8, SAM Tower, Plot #4, Road #22, Gulshan-1, Dhaka-1212,Bangladesh Tel: +880 9609 000 999, +880 2 5881 5559, Ext: 14191, Fax: +880 2 9895757 Cell: +8801787680828, Email: mosharaf.hoss...@bol-online.com, Web: www.bol-online.com <https://www.google.com/url?q=http://www.bol-online.com=D=hangouts=1557908951423000=AFQjCNGMxIuHSHsD3qO6y5JddpEZ0S592A> On Tue, Oct 31, 2023 at 7:15 AM Mark Andrews wrote: > > > > On 30 Oct 2023, at 17:25, Mosharaf Hossain < > mosharaf.hoss...@bol-online.com> wrote: > > > > mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. > > mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. > > couldn't get address for 'ns1.bcc.gov.bd': not found > > couldn't get address for 'ns2.bcc.gov.bd': not found > > dig: couldn't get address for 'ns1.bcc.gov.bd': no more > > root@ns1:/etc/bind# > > So you got this this point and that is saying that the lookup of > the addresses of the nameservers is failing. The next step would to > do a 'dig +trace' or a 'dig +trace +all' of those names. > > % dig +trace ns1.bcc.gov.bd. +all -4 > ;; BADCOOKIE, retrying. > > ; <<>> DiG 9.19.18-dev <<>> +trace ns1.bcc.gov.bd. +all -4 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11927 > ;; flags: qr rd ra ad; QUERY: 1, ANS
Re: 9.18 BIND not resolving .gov.bd site
> On 30 Oct 2023, at 17:25, Mosharaf Hossain > wrote: > > mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. > mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. > couldn't get address for 'ns1.bcc.gov.bd': not found > couldn't get address for 'ns2.bcc.gov.bd': not found > dig: couldn't get address for 'ns1.bcc.gov.bd': no more > root@ns1:/etc/bind# So you got this this point and that is saying that the lookup of the addresses of the nameservers is failing. The next step would to do a 'dig +trace' or a 'dig +trace +all' of those names. % dig +trace ns1.bcc.gov.bd. +all -4 ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.18-dev <<>> +trace ns1.bcc.gov.bd. +all -4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11927 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 69a562ec1c50e2280100654052b51e141922bd619839 (good) ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 193742 IN NS b.root-servers.net. . 193742 IN NS c.root-servers.net. . 193742 IN NS d.root-servers.net. . 193742 IN NS g.root-servers.net. . 193742 IN NS j.root-servers.net. . 193742 IN NS l.root-servers.net. . 193742 IN NS i.root-servers.net. . 193742 IN NS h.root-servers.net. . 193742 IN NS k.root-servers.net. . 193742 IN NS a.root-servers.net. . 193742 IN NS f.root-servers.net. . 193742 IN NS e.root-servers.net. . 193742 IN NS m.root-servers.net. . 193742 IN RRSIG NS 8 0 518400 2023110905 2023102704 46780 . CkAeB9x0RdrjpMfUJWlZS8F8YwnNj8KY7CYkukIncgzX1eve21wHBkgF kXrIEQP7Atkq4/KYqsgs4fKnFwIkxtEqqDDvkU/635/cYgOFaBKiU5Di 4sPC5Q/q8jORU4WPM7vg+j7bY48qEaoTImPuT+EQpI4HF5uHekYm9F35 tJENhmLryMv8K4+072w2eaOTc45wirnVNxhxZ2QK8aZylubq2ELQ43aJ GgRmrFhujt8jzi20OvySAq1MNCd3Dy0Xqh99DSu6YkhflypgZXeUEiRV 8/HB33V9yQBs/GNXjajxSw/NwxLAxMDNv8kdkE08YBWTZLQfPmY/+ZDU FEchxA== ;; ADDITIONAL SECTION: l.root-servers.net. 135488 IN A 199.7.83.42 g.root-servers.net. 135488 IN A 192.112.36.4 i.root-servers.net. 135488 IN A 192.36.148.17 h.root-servers.net. 135488 IN A 198.97.190.53 k.root-servers.net. 135488 IN A 193.0.14.129 j.root-servers.net. 135488 IN A 192.58.128.30 d.root-servers.net. 135488 IN A 199.7.91.13 b.root-servers.net. 135488 IN A 199.9.14.201 a.root-servers.net. 135488 IN A 198.41.0.4 f.root-servers.net. 135488 IN A 192.5.5.241 e.root-servers.net. 135488 IN A 192.203.230.10 c.root-servers.net. 135488 IN A 192.33.4.12 m.root-servers.net. 135488 IN A 202.12.27.33 l.root-servers.net. 135488 IN 2001:500:9f::42 g.root-servers.net. 135488 IN 2001:500:12::d0d i.root-servers.net. 135488 IN 2001:7fe::53 h.root-servers.net. 135488 IN 2001:500:1::53 k.root-servers.net. 135488 IN 2001:7fd::1 j.root-servers.net. 135488 IN 2001:503:c27::2:30 d.root-servers.net. 135488 IN 2001:500:2d::d b.root-servers.net. 135488 IN 2001:500:200::b a.root-servers.net. 135488 IN 2001:503:ba3e::2:30 f.root-servers.net. 135488 IN 2001:500:2f::f e.root-servers.net. 135488 IN 2001:500:a8::e c.root-servers.net. 135488 IN 2001:500:2::c m.root-servers.net. 135488 IN 2001:dc3::35 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Tue Oct 31 12:04:53 AEDT 2023 ;; MSG SIZE rcvd: 1125 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38819 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 69a562ec1c50e2280100654052b5f101b47fe1d10f06 (good) ;; QUESTION SECTION: ;ns1.bcc.gov.bd. IN A ;; AUTHORITY SECTION: bd. 172800 IN NS dns.bd. bd. 172800 IN NS surma.btcl.net.bd. bd. 172800 IN NS bd-ns.anycast.pch.net. bd. 172800 IN NS jamuna.btcl.net.bd. bd. 86400 IN DS 26044 8 1 2DAD1B7F8CA778464F536FDDD15EFD24CCCB62EF bd. 86400 IN DS 26044 8 2 BD01C4B4345D21FC38AA88129F7BC00FDD7B422799CC6703736E3B38 1F37DD5B bd. 86400 IN RRSIG DS 8 1 86400 2023111217 2023103016 46780 . IFF4dDc0UEceikw9rf2bEaz/4LZtyCHeKAxX+gD8okseRzK1EcheFZ53 m8ZJtUa/ptVRIm6Hvwc8HTq7KeRKoCULw2isoqB/gNJDc+PasE0/2Uq8 vEY0CCPJad/zKRAjSXxkI6tmvOt3a3Mk6soTIOFCiK0eITwx2sJsdIGZ /wL3cfaqSHh1735dWtg0kWFstyesSida7YHjNyOsJ/X/mUMEInhFdHzR mg3Sa64FUy8BamA/yTUazNb3VG3yRS9ZUFJXeMib7qjSspDEqb2dTKzy RvFxiNKOD5rDoCN3/Da6hi/dBhCLL9Zh+6mhsV0KHLahoKI2Bl2xw2v3 F9hFyA== ;; ADDITIONAL SECTION: jamuna.btcl.net.bd. 172800 IN A 203.112.194.231 surma.btcl.net.bd. 172800 IN A 203.112.194.232 bd-ns.anycast.pch.net. 172800 IN A 204.61.216.108 dns.bd. 172800 IN A 123.49.12.112 jamuna.btcl.net.bd. 172800 IN 2407:5000:88:4::231 surma.btcl.net.bd. 172800 IN 2407:5000:88:4::232 bd-ns.anycast.pch.net. 172800 IN 2001:500:14:6108:ad::1 dns.bd. 172800 IN 2407:5000:88:5::3 ;; Query time: 19 msec ;; SERVER: 192.33.4.12#53(c.root-servers.net) (UDP) ;; WHEN: Tue Oct 31 12:04:53 AEDT 2023 ;; MSG SIZE r
Re: 9.18 BIND not iterated over all authoritative nameservers
> Am 30.10.2023 um 16:59 schrieb Michael Martinell via bind-users > : > > Thanks to all who responded. Putting qname-minimization disabled; in > named.conf resolves the issue in my testing. > > I did try specifying relaxed (which appears to be the default), but that > didn’t work either. > > I agree it would be great if the far ends would make sure what they publish > is correct, but it will take a large company to push them to do so. > I usually tell people that the other side needs to fix their stuff. Mostly happens when people fubar their DNSSEC setup. But this name server stuff (more often then not, it’s some Load-Balancer acting as a DNS-server) In both cases: I usually ask them if they can be absolutely sure if the other side hasn’t been hacked? You don’t go and try to override broken SSL certificate setups with HSTS, do you? That said, I’m still on 9.16, too. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
Thanks to all who responded. Putting qname-minimization disabled; in named.conf resolves the issue in my testing. I did try specifying relaxed (which appears to be the default), but that didn’t work either. I agree it would be great if the far ends would make sure what they publish is correct, but it will take a large company to push them to do so. Michael Martinell Network/Broadband Technician Interstate Telecommunications Coop., Inc. From: bind-users On Behalf Of Paul Stead Sent: Saturday, October 28, 2023 11:35 AM Cc: bind-users@lists.isc.org Subject: Re: 9.18 BIND not iterated over all authoritative nameservers I wasn't On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý mailto:ond...@isc.org>> wrote: Please don’t use Postel’s Law as excuse for implementations that break standards: https://datatracker.ietf.org/doc/html/rfc9413<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 mailto:paul.st...@gmail.com>> 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" Paul On Sat, Oct 28, 2023, 3:56 PM Rick Frey mailto:grib...@gmail.com>> wrote: As Mark mentions, the NS records gtm.bankeasy.com<http://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. - Rick On Oct 27, 2023, at 6:31 PM, Mark Andrews mailto:ma...@isc.org>> wrote: Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NS records then they should expect lookups to fail. The NS records on both sides of a zone cut are supposed to be IDENTICAL. This is not a new requirement. It has been this way since the very beginning. The bank needs to fix what they publish. Mark On 28 Oct 2023, at 02:36, Michael Martinell via bind-users mailto: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.x Every 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<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 && ldconfig Interstate Telecommunications Coop., Inc. 312 4th Street West • Clear Lake, SD 57226 Phone: (605) 874-8313 michael.martin...@itccoop.com<mailto:michael.martin...@itccoop.com> www.itc-web.com<http://www.itc-web.com> -- Visit https://lists.isc.org/mailman/listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/<https://www.isc.org/contact/> for more information. bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users> -- Visit https://lists.isc.org/mailman/listinfo/b
Re: 9.18 BIND not resolving .gov.bd site
On 30-Oct-23 03:46, Marco M. wrote: Am 30.10.2023 um 12:25:32 Uhr schrieb Mosharaf Hossain: mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. couldn't get address for 'ns1.bcc.gov.bd': not found couldn't get address for 'ns2.bcc.gov.bd': not found dig: couldn't get address for 'ns1.bcc.gov.bd': no more root@ns1:/etc/bind# I can resolve them, but only A records exist. Please try it again. dig a ns2.bcc.gov.bd When encountering these sorts of errors, particularly if not a DNS expert, the easiest diagnostic to use is https://dnsviz.net It's graphical, detailed and while oriented toward DNSSEC, detects many other misconfigurations. Fix the errors and warnings shown at https://dnsviz.net/d/mofa.gov.bd/dnssec/ and retest. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature.asc Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.18 BIND not resolving .gov.bd site
Everything looks good from here in a Debian with 9.18 # nslookup mofa.gov.bd Server: 193.93.164.194 Address:193.93.164.194#53 Non-authoritative answer: Name: mofa.gov.bd Address: 103.163.210.121 Name: mofa.gov.bd Address: 103.163.210.117 # dig ns mofa.gov.bd ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> ns mofa.gov.bd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10354 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mofa.gov.bd. IN NS ;; ANSWER SECTION: mofa.gov.bd.31394 IN NS ns2.bcc.gov.bd. mofa.gov.bd.31394 IN NS ns1.bcc.gov.bd. ;; ADDITIONAL SECTION: ns1.bcc.gov.bd. 31394 IN A 114.130.54.123 ns2.bcc.gov.bd. 31394 IN A 114.130.54.124 ;; Query time: 0 msec ;; SERVER: 193.93.164.194#53(193.93.164.194) (UDP) ;; WHEN: Mon Oct 30 10:24:37 EET 2023 ;; MSG SIZE rcvd: 118 On 30/10/2023 9:46, Marco M. wrote: Am 30.10.2023 um 12:25:32 Uhr schrieb Mosharaf Hossain: mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. couldn't get address for 'ns1.bcc.gov.bd': not found couldn't get address for 'ns2.bcc.gov.bd': not found dig: couldn't get address for 'ns1.bcc.gov.bd': no more root@ns1:/etc/bind# I can resolve them, but only A records exist. Please try it again. dig a ns2.bcc.gov.bd -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 resolving .gov.bd site
Am 30.10.2023 um 12:25:32 Uhr schrieb Mosharaf Hossain: > mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. > mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. > couldn't get address for 'ns1.bcc.gov.bd': not found > couldn't get address for 'ns2.bcc.gov.bd': not found > dig: couldn't get address for 'ns1.bcc.gov.bd': no more > root@ns1:/etc/bind# I can resolve them, but only A records exist. Please try it again. dig a ns2.bcc.gov.bd -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.18 BIND not resolving .gov.bd site
Hi Recently I installed BIND 9.18 in the debina12 server and everything is working fine except .gov.bd sites. Following are some reports attached for your reference. Kindly help me to identify the reason. [image: image.png] root@ns1:/etc/bind# dig mofa.gov.bd +trace ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> mofa.gov.bd +trace ;; global options: +cmd . 518244 IN NS b.root-servers.net. . 518244 IN NS c.root-servers.net. . 518244 IN NS f.root-servers.net. . 518244 IN NS g.root-servers.net. . 518244 IN NS l.root-servers.net. . 518244 IN NS k.root-servers.net. . 518244 IN NS i.root-servers.net. . 518244 IN NS d.root-servers.net. . 518244 IN NS e.root-servers.net. . 518244 IN NS a.root-servers.net. . 518244 IN NS h.root-servers.net. . 518244 IN NS m.root-servers.net. . 518244 IN NS j.root-servers.net. . 518244 IN RRSIG NS 8 0 518400 2023111205 2023103004 46780 . KOSvh8dmDkcY070FSYz+vAkH6BC+ZR4nGbEu0plshkZZX47oFXFpsHTJ /LiU7G7KXp6gE+g+QDcHk/HPEljGFNY5RwvzQaCjHGG063ypr+Huj1vJ 0SR03fSwm1FALKZ0EFNI2aIfpxY/1S8xc2HzZmHuneQcp7mTY7i+KtOY z8ljk2jQbdCjHYPg/AgIPtF2+507LnFScSCTw+zOVFYFktoPHyy/wDIk 3G0VQQIQG5+1kjn7YZl1yuyxiSqJhq1+7tSkrL3AKhA4fJtynJcBbZsw dq3mVHPfARjUjby2WNt/M2clERoo+W/zYsZpkKamUpvTNm6gYnnt2xUV 8F5/Ow== ;; Received 1137 bytes from x.x.x.x#53(x.x.x.x) in 0 ms bd. 172800 IN NS dns.bd. bd. 172800 IN NS bd-ns.anycast.pch.net. bd. 172800 IN NS surma.btcl.net.bd. bd. 172800 IN NS jamuna.btcl.net.bd. bd. 86400 IN DS 26044 8 1 2DAD1B7F8CA778464F536FDDD15EFD24CCCB62EF bd. 86400 IN DS 26044 8 2 BD01C4B4345D21FC38AA88129F7BC00FDD7B422799CC6703736E3B38 1F37DD5B bd. 86400 IN RRSIG DS 8 1 86400 2023111205 2023103004 46780 . MiQoaKFiMKBfioQieg7q6riR+DKwn6vZyvNYUcfQRWi9obbcpq2vAK3m N82C22NxFtX3jwa1IxKjp2kh53PTiLgVcgS9HWiugsyzbmaTyVGI6iL8 dsUXGEpd0i+QTNv3TEFtApmsj1R+tbsvotUlVwSwYS3GPJ7KRVUN1ewN Pr/sD5hfDXl+SSlLD6Y1zka5y8PU9wIh5wWngKtIXlFgil/DYu7vuOMi 3i8Cpw/bfFkwz4PxluUCLX1aFmCKjFrxz4t4SlagzHUVtfGGVfFCEB/K pNqoHVmORAKBUjJU713QESLhLEosS8BOcCJhe3/X9YYA9iiXNiPR/NLT QrXXkQ== couldn't get address for 'surma.btcl.net.bd': not found couldn't get address for 'jamuna.btcl.net.bd': not found ;; Received 690 bytes from 192.203.230.10#53(e.root-servers.net) in 0 ms mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. couldn't get address for 'ns1.bcc.gov.bd': not found couldn't get address for 'ns2.bcc.gov.bd': not found dig: couldn't get address for 'ns1.bcc.gov.bd': no more root@ns1:/etc/bind# Regards Mosharaf Hossain Manager, Product Development IT Division -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
I wasn't On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý wrote: > 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" > > Paul > > > On Sat, Oct 28, 2023, 3:56 PM Rick Frey 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. >> >> - Rick >> >> >> >> On Oct 27, 2023, at 6:31 PM, Mark Andrews wrote: >> >> >> >> Named now uses NS lookups to perform QNAME minimisation. If one puts >> garbage in the NS >> records then they should expect lookups to fail. The NS records on both >> sides of a zone >> cut are supposed to be IDENTICAL. This is not a new requirement. It has >> been this way >> since the very beginning. >> >> The bank needs to fix what they publish. >> >> Mark >> >> On 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.x >> Every 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 && ldconfig >> >> >> >> 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 > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: 9.18 BIND not iterated over all authoritative nameservers
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" Paul On Sat, Oct 28, 2023, 3:56 PM Rick Frey 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. > > - Rick > > > > On Oct 27, 2023, at 6:31 PM, Mark Andrews wrote: > > > > Named now uses NS lookups to perform QNAME minimisation. If one puts > garbage in the NS > records then they should expect lookups to fail. The NS records on both > sides of a zone > cut are supposed to be IDENTICAL. This is not a new requirement. It has > been this way > since the very beginning. > > The bank needs to fix what they publish. > > Mark > > On 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.x > Every 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 && ldconfig > > > > 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: 9.18 BIND not iterated over all authoritative nameservers
As Mark mentions, the NS records gtm.bankeasy.com <http://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. - Rick > On Oct 27, 2023, at 6:31 PM, Mark Andrews wrote: > > > > Named now uses NS lookups to perform QNAME minimisation. If one puts garbage > in the NS > records then they should expect lookups to fail. The NS records on both > sides of a zone > cut are supposed to be IDENTICAL. This is not a new requirement. It has > been this way > since the very beginning. > > The bank needs to fix what they publish. > > Mark > >> On 28 Oct 2023, at 02:36, Michael Martinell via bind-users >> 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.x >> Every 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 && ldconfig >> >> >> >> 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
Re: 9.18 BIND not iterated over all authoritative nameservers
Well if the bank is stupid enough to use NS records that point to nameservers that do not exist on the internet then lookups FAIL. % dig ns gtm.bankeasy.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.18-dev <<>> ns gtm.bankeasy.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: dbef45feadd7b3850100653c2cefd1f381fbb389e388 (good) ;; QUESTION SECTION: ;gtm.bankeasy.com. IN NS ;; ANSWER SECTION: gtm.bankeasy.com. 0 IN NS bkx-bigip1-out.ffc.local. ;; Query time: 992 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Sat Oct 28 08:34:39 AEDT 2023 ;; MSG SIZE rcvd: 111 % Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NS records then they should expect lookups to fail. The NS records on both sides of a zone cut are supposed to be IDENTICAL. This is not a new requirement. It has been this way since the very beginning. The bank needs to fix what they publish. Mark > On 28 Oct 2023, at 02:36, Michael Martinell via bind-users > 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.x > Every 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 && ldconfig > When I do a dig against a server running 9.18 I get the following: > dig @dns1.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; Query time: 8 msec > ;; SERVER: > 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) > ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 > ;; MSG SIZE rcvd: 74 > The same command resolves just fine when I run it against 9.16 > dig @dns2.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; ANSWER SECTION: > view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. > view.gtm.bankeasy.com. 300 IN A 96.2.250.200 > ;; Query time: 11 msec > ;; SERVER: > 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) > ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 > ;; MSG SIZE rcvd: 125 > [root@brkr-dns2 bind-9.18.12]# > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.18 BIND not iterated over all authoritative nameservers
Doing some checking on this locally trying to understand what may be happening. I stumbled across this: view.bankeasy.com is a cname to view.gtm.bankeasy.com However if I try to dig for gtm.bankeasy.com that is where the oddities show up: dig @ns1.dakotanames.com gtm.bankeasy.com ; <<>> DiG 9.18.18 <<>> @ns1.dakotanames.com gtm.bankeasy.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5025 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gtm.bankeasy.com. IN A ;; AUTHORITY SECTION: gtm.bankeasy.com. 60 IN SOA bkx-bigip1-out.ffc.local. hos tmaster.bkx-bigip1-out.ffc.local. 2023102501 10800 3600 604800 60 ;; Query time: 52 msec ;; SERVER: 96.2.250.214#53(ns1.dakotanames.com) (UDP) ;; WHEN: Fri Oct 27 18:03:58 CDT 2023 ;; MSG SIZE rcvd: 116 Not sure how this effects things, but the SOA record shows bad info '.local.' I wonder if this is where the issue is. The authoritive nameserver and responsible party records are not resolvable. Maybe someone with more knowledge of DNS and the use of .local. domain name can shed some light on this. Lyle Giese On 10/27/23 10:36, Michael Martinell via bind-users 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.x Every 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 && ldconfig When I do a dig against a server running 9.18 I get the following: dig @dns1.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; Query time: 8 msec ;; SERVER: 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 ;; MSG SIZE rcvd: 74 The same command resolves just fine when I run it against 9.16 dig @dns2.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; ANSWER SECTION: view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. view.gtm.bankeasy.com. 300 IN A 96.2.250.200 ;; Query time: 11 msec ;; SERVER: 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 ;; MSG SIZE rcvd: 125 [root@brkr-dns2 bind-9.18.12]# *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
9.18 BIND not iterated over all authoritative nameservers
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.x Every 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 && ldconfig When I do a dig against a server running 9.18 I get the following: dig @dns1.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; Query time: 8 msec ;; SERVER: 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 ;; MSG SIZE rcvd: 74 The same command resolves just fine when I run it against 9.16 dig @dns2.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; ANSWER SECTION: view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. view.gtm.bankeasy.com. 300 IN A 96.2.250.200 ;; Query time: 11 msec ;; SERVER: 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 ;; MSG SIZE rcvd: 125 [root@brkr-dns2 bind-9.18.12]# 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
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
bind9 service problem with BIND 9.10.3
Hi All Lately, 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. [image: image.png] Regards Mosharaf Hossain Manager, Product Development IT Division Bangladesh Export Import Company Ltd. Level-8, SAM Tower, Plot #4, Road #22, Gulshan-1, Dhaka-1212,Bangladesh Tel: +880 9609 000 999, +880 2 5881 5559, Ext: 14191, Fax: +880 2 9895757 Cell: +8801787680828, Email: mosharaf.hoss...@bol-online.com, Web: www.bol-online.com <https://www.google.com/url?q=http://www.bol-online.com=D=hangouts=1557908951423000=AFQjCNGMxIuHSHsD3qO6y5JddpEZ0S592A> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 forgets my changes with nsupdate
201907-b...@planhack.com wrote:
>> My solution is not to mix dynamic update with other access. Instead,
>> I put in CNAMEs in the signed zone to a sub-zone (or other zone) where
>> I do exclusive dynamic update. This isn't perfect, but it works well
>> enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my
>> certificates.
> Not perfect? What issues did you see? Thanks!
a) there are still a number of situations where systems do not follow CNAMEs
when
they should. Particularly relating to RFC2317 reverse delegations.
b) using a second zones introduces additional possibilities for DNSSEC to be
broken.
c) cruft accumulates in the second zone, and some of it does not get deleted.
d) updates to secondaries sometimes take longer than certbot is able to cope
with.
("up-arrow-return" solves the problem if interactive. Cron running a week
later usually works)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind forgets my changes with nsupdate
Paul van der Vlis via bind-users wrote: > But how could I refresh the key without loosing the IP? I was in a similar situation. I managed my zone files mostly manually, but a few records needed to be updated automatically. Either manual changes would obliterate automatically updated records, as you found, or else automatic updates would cause Bind to rearrange the zone files and lose all comments, making manual editing much harder. I have arrived at what I think is a working solution. I'm still monitoring to see how it works. I now make all changes through dynamic updates (like with nsupdate), using different TSIG keys with different privileges in update-policy. Signing and key rotation are handled automatically by Bind, using dnssec-policy. I use nsdiff (https://dotat.at/prog/nsdiff/) and nsupdate to apply manual changes. That way I still have hand-written zone files with comments, so I can keep an overview, but Bind never sees them. The zone files that Bind uses are managed by Bind and don't need to be easy to read. I have a wrapper script that calls nsdiff to compare each hand- written zone file to the corresponding zone on the server, specifying a pattern with -i to tell nsdiff which records are managed in other ways. The wrapper then displays the changes, asks for approval, and then applies the changes through nsupdate. My TSIG key for manual changes, which has much greater privileges than the keys for specific automatic updates, is stored in an encrypted keyring managed with Pass (https://www.passwordstore.org/). My wrapper requests the key from Pass – which requires me to type the master passphrase – and passes it to nsdiff and to nsupdate using pipes so that the decrypted key is never written to even a temporary file. I found that inline-signing breaks nsdiff. I recommend an explicit "inline-signing no;" in each zone to prevent problems. Bind will then not keep an unsigned version of the zone, and it doesn't need to when all changes are made through dynamic updates. Björn Persson pgpZuA42cOsQH.pgp Description: OpenPGP digital signatur -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 forgets my changes with nsupdate
> My solution is not to mix dynamic update with other access. > Instead, I put in CNAMEs in the signed zone to a sub-zone (or other zone) > where I do exclusive dynamic update. This isn't perfect, but it works > well enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my > certificates. Not perfect? What issues did you see? Thanks! -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 forgets my changes with nsupdate
In general, you don't want to mix dynamic update zones with ones that you want to edit by hand. I see that you are doing manual DNSSEC signing in your cron job. Your choices are: a) do everything with dynamic update, and turn on automatic DNSSEC management in bind9. b) do your DNSSEC signing inline. I blogged poorly about my setup: https://www.sandelman.ca/mcr/blog/sysadmin/bind9-dnssec-formula/ c) a mix of the above. My solution is not to mix dynamic update with other access. Instead, I put in CNAMEs in the signed zone to a sub-zone (or other zone) where I do exclusive dynamic update. This isn't perfect, but it works well enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my certificates. signature.asc Description: PGP signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind forgets my changes with nsupdate
Just configure named to sign the zone. -- Mark Andrews > On 6 Oct 2023, at 22:30, Paul van der Vlis wrote: > > Op 06-10-2023 om 10:39 schreef Mark Andrews: >> You need to figure out what is updating the zone. This isn’t named. > > Thanks for your answer. > It makes me find the reason. See my other message. > > With regards, > Paul > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl/ -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 forgets my changes with nsupdate
Op 06-10-2023 om 10:39 schreef Mark Andrews: You need to figure out what is updating the zone. This isn’t named. Thanks for your answer. It makes me find the reason. See my other message. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 forgets my changes with nsupdate
Op 06-10-2023 om 10:28 schreef Paul van der Vlis via bind-users:
Hello,
I try to give a dynamic IP to a name, using nsupdate. This works fine,
but after some hours the IP is gone from the master (which I update).
Something like this:
Host home.customer.nl not found: 3(NXDOMAIN)
The IP is then still available from the slaves, what gets it from the
master.
I do something like this to give the IP, using a script:
root@server:~# /usr/bin/nsupdate -k /etc/customer.key
> server ns1.vandervlis.nl
> zone customer.nl.
> update delete home.customer.nl.
> update add home.customer.nl. 3600 A 1.2.3.4
> send
> quit
I don't see anything about the removal in the logs. But I saw a "freeze"
and a "thaw" in the logs for the domain.
Any idea why the IP removes after some time?
Hmm, I see I have cronjob what causes this problem:
-
# change serial
SERIAL=`named-checkzone $domain $domain | egrep -ho '[0-9]{10}'`
sed -i 's/'$SERIAL'/'$(($SERIAL+1))'/' $domain
# sign zone
rndc freeze $domain
dnssec-signzone -S -K /etc/bind/keys/ -g -a -o $domain $domain
rndc reload $domain
rndc thaw $domain
-
But how could I refresh the key without loosing the IP?
With regards,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://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 forgets my changes with nsupdate
You need to figure out what is updating the zone. This isn’t named. -- Mark Andrews > On 6 Oct 2023, at 19:28, Paul van der Vlis via bind-users > wrote: > > Hello, > > I try to give a dynamic IP to a name, using nsupdate. This works fine, but > after some hours the IP is gone from the master (which I update). > > Something like this: > Host home.customer.nl not found: 3(NXDOMAIN) > > The IP is then still available from the slaves, what gets it from the master. > > I do something like this to give the IP, using a script: > > root@server:~# /usr/bin/nsupdate -k /etc/customer.key > > server ns1.vandervlis.nl > > zone customer.nl. > > update delete home.customer.nl. > > update add home.customer.nl. 3600 A 1.2.3.4 > > send > > quit > > I don't see anything about the removal in the logs. But I saw a "freeze" and > a "thaw" in the logs for the domain. > > Any idea why the IP removes after some time? > > With regards, > Paul van der Vlis > > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl/ > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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
Bind forgets my changes with nsupdate
Hello, I try to give a dynamic IP to a name, using nsupdate. This works fine, but after some hours the IP is gone from the master (which I update). Something like this: Host home.customer.nl not found: 3(NXDOMAIN) The IP is then still available from the slaves, what gets it from the master. I do something like this to give the IP, using a script: root@server:~# /usr/bin/nsupdate -k /etc/customer.key > server ns1.vandervlis.nl > zone customer.nl. > update delete home.customer.nl. > update add home.customer.nl. 3600 A 1.2.3.4 > send > quit I don't see anything about the removal in the logs. But I saw a "freeze" and a "thaw" in the logs for the domain. Any idea why the IP removes after some time? With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?
Hi there On 02/10/2023 11:06, Kurt Jaeger wrote: In the light of the recent exim security issues[1,2] I'm trying to find out if bind 9.18.19, if used as resolver, does enough validation to shield exim instances from CVE-2023-42119 ? I added 'check-names response fail;' to the internal view. So far this blocked a few hosts with underscore and comma in the name, which didn't break anything. I'm assuming that this will protect DNS lookups. But that's just an assumption. As details and reproducers for the CVE are not available, this is a more general question. Pointers on where I can read more about it are highly appreciated! There are probably two aspects to validation: - Validating DNSSEC (the more common use case of validation) - Validating DNS request/replies in general (bailiwick, cache polution etc). [1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html [2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/ Regards, Rob -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?
Hi Kurt, we do not ship exim in RHEL, so nobody from our team did proper work on these vulnerabilities. From the few information that I have found, I would just guess BIND9 or Unbound should help protecting exim. Dnsmasq or coredns do not create full response message from scratch, but forward original responses from upstream, unless it cached it already. So with BIND it should be better, but no guarantees given. Local validating resolver should help in any case. But without more detailed information about the vulnerability, we are just guessing. Best Regards, Petr On 02. 10. 23 11:06, Kurt Jaeger wrote: Hi! In the light of the recent exim security issues[1,2] I'm trying to find out if bind 9.18.19, if used as resolver, does enough validation to shield exim instances from CVE-2023-42119 ? As details and reproducers for the CVE are not available, this is a more general question. Pointers on where I can read more about it are highly appreciated! There are probably two aspects to validation: - Validating DNSSEC (the more common use case of validation) - Validating DNS request/replies in general (bailiwick, cache polution etc). [1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html [2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/ -- Petr Menšík Software Engineer, RHEL Red Hat, http://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 paid support subscriptions. Contact us at https://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: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?
On 02. 10. 23 11:06, Kurt Jaeger wrote: Hi! In the light of the recent exim security issues[1,2] I'm trying to find out if bind 9.18.19, if used as resolver, does enough validation to shield exim instances from CVE-2023-42119 ? As details and reproducers for the CVE are not available, this is a more general question. Pointers on where I can read more about it are highly appreciated! There are probably two aspects to validation: - Validating DNSSEC (the more common use case of validation) - Validating DNS request/replies in general (bailiwick, cache polution etc). [1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html [2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/ It's impossible to judge from the (lack of) details provided. Sorry! -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?
Hi! In the light of the recent exim security issues[1,2] I'm trying to find out if bind 9.18.19, if used as resolver, does enough validation to shield exim instances from CVE-2023-42119 ? As details and reproducers for the CVE are not available, this is a more general question. Pointers on where I can read more about it are highly appreciated! There are probably two aspects to validation: - Validating DNSSEC (the more common use case of validation) - Validating DNS request/replies in general (bailiwick, cache polution etc). [1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html [2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/ -- p...@opsec.eu+49 171 3101372Now what ? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: [EXTERNAL] bind-users Digest, Vol 4327, Issue 1
Unsubscribe From: bind-users On Behalf Of bind-users-requ...@lists.isc.org Sent: Wednesday, September 27, 2023 4:02 PM To: bind-users@lists.isc.org Subject: [EXTERNAL] bind-users Digest, Vol 4327, Issue 1 Send bind-users mailing list submissions to bind-users@ lists. isc. org To subscribe or unsubscribe via the World Wide Web, visit https: //urldefense. com/v3/__https: //lists. isc. org/mailman/listinfo/bind-users__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljXy3zF8_A$ Send bind-users mailing list submissions to bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljXy3zF8_A$<https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/bind-users__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljXy3zF8_A$> or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org<mailto:bind-users-requ...@lists.isc.org> You can reach the person managing the list at bind-users-ow...@lists.isc.org<mailto:bind-users-ow...@lists.isc.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Hyperlocal RFC8806 Root Mirror (Silva Carlos) 2. Re: Hyperlocal RFC8806 Root Mirror (Michael Richardson) 3. KSAP - How to manually rollover keys documentation? (Eddie Rowe) -- Message: 1 Date: Wed, 27 Sep 2023 12:53:54 -0300 From: Silva Carlos mailto:scarlos.4...@gmail.com>> To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: Hyperlocal RFC8806 Root Mirror Message-ID: mailto:cae0cwpqy17ea41h-cnhnz0tu5o8z33fxs0wo+i_5tztaqye...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" + Hey guys. I have two recursive servers, bind 9.18 on Debian 12. On server A I configured HyperLocal. On Server B I did NOT configure HyperLocal. I ran the command "dig @localhost EXAMPLES" on both servers. EXAMPLES: blabla.sdf.dd or teste.com.eroterrter or world.nanana Problem: Both Servers report that "Query TIme = 0 ms". I understand that Server A should result in 0ms and Server B should have a non-zero time as Server B does not have a copy of the Root Zone DB. Question: Where am I going wrong? Am I missing some basic principle? I'm following this tutorial: https://urldefense.com/v3/__https://semanacap.bcp.nic.br/files/apresentacao/arquivo/864/Implementacao*20de*20servidores*20recursivos*20guia*20de*20praticas*20semcap*20ceptro*20br.pdf__;JSUlJSUlJSUl!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljXwWDW0NG$<https://urldefense.com/v3/__https:/semanacap.bcp.nic.br/files/apresentacao/arquivo/864/Implementacao*20de*20servidores*20recursivos*20guia*20de*20praticas*20semcap*20ceptro*20br.pdf__;JSUlJSUlJSUl!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljXwWDW0NG$> Best Regards + <https://urldefense.com/v3/__https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX0QzDex6$<https://urldefense.com/v3/__https:/www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX0QzDex6$>> N?o cont?m v?rus.https://urldefense.com/v3/__http://www.avast.com__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX7CXzq1D$<https://urldefense.com/v3/__http:/www.avast.com__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX7CXzq1D$> <https://urldefense.com/v3/__https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX0QzDex6$<https://urldefense.com/v3/__https:/www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail__;!!EQ82F1lD2o0!a9msf12u5aa_Cu5f9CthZ0ZyqFBX25xWXnaU6dvdABqajXCyBM38LJ_62y1tNeOcAaEAiZoaGDzTZE_9NQljX0QzDex6$>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- next part -- An HTML attachment
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
Dnstap Re: Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)
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
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: BIND 9.18 unable to successfully transfer zone from axfrdns primary
Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this: "The AXFR server MUST copy the Question section from the corresponding AXFR query message into the first response message's Question section. For subsequent messages, it MAY do the same or leave the Question section empty." There are some older implementations out there that don't do this correctly. I have a vendor supported IPAM implementation, where I have gone back to the vendor and quoted the above, and they have fixed the implementation. michael On 8/31/23 17:34, Ian Bobbitt wrote: That gets me more information, and I think puts the problem onto axfrdns. Thanks. xfer-in: info: zone example.net/IN: Transfer started. xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of initial version from 198.51.100.1#53 xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected using 198.51.100.1#53 xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: sent request data xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: missing question section xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed while receiving responses: FORMERR xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer status: FORMERR Looks like this isn't going to be solvable on my side. https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663 Packet capture confirms that we are indeed not getting a response with the question section. I'm running the same version of dig, on the same system. Interesting that dig isn't as strict about this. -- Ian On 8/31/23 7:58 PM, Mark Andrews wrote: Set debug level 3 on the xfrin channel. There are some debug level messages that really should be set to error level in lib/dns/xfrin.c on FORMERR. Also make sure you are running dig from the same version as later versions are more strict in parsing responses from the wire. On 1 Sep 2023, at 09:23, Ian Bobbitt wrote: I have a system running BIND 9.18.17 that needs to transfer a zone from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log messages indicating the problem. xfer-in: info: zone example.net/IN: Transfer started. xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected using192.0.2.1 #53 xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed while receiving responses: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer status: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 bytes/sec) (serial 0) This replaced a long obsolete system running 9.8.2 that was able to successfully transfer the zone. I can also successfully transfer the zone with `dig -t axfr ...` from the new system, which gives no errors. named-checkzone on the resulting data also gives no errors, and BIND is able to successfully load it as a primary. How do I go about finding the cause of the FORMERR and resolve it? -- Ian -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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 9.18 unable to successfully transfer zone from axfrdns primary
That gets me more information, and I think puts the problem onto axfrdns. Thanks. xfer-in: info: zone example.net/IN: Transfer started. xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of initial version from 198.51.100.1#53 xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected using 198.51.100.1#53 xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: sent request data xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: missing question section xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed while receiving responses: FORMERR xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer status: FORMERR Looks like this isn't going to be solvable on my side. https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663 Packet capture confirms that we are indeed not getting a response with the question section. I'm running the same version of dig, on the same system. Interesting that dig isn't as strict about this. -- Ian On 8/31/23 7:58 PM, Mark Andrews wrote: Set debug level 3 on the xfrin channel. There are some debug level messages that really should be set to error level in lib/dns/xfrin.c on FORMERR. Also make sure you are running dig from the same version as later versions are more strict in parsing responses from the wire. On 1 Sep 2023, at 09:23, Ian Bobbitt wrote: I have a system running BIND 9.18.17 that needs to transfer a zone from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log messages indicating the problem. xfer-in: info: zone example.net/IN: Transfer started. xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected using192.0.2.1 #53 xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed while receiving responses: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer status: FORMERR xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 bytes/sec) (serial 0) This replaced a long obsolete system running 9.8.2 that was able to successfully transfer the zone. I can also successfully transfer the zone with `dig -t axfr ...` from the new system, which gives no errors. named-checkzone on the resulting data also gives no errors, and BIND is able to successfully load it as a primary. How do I go about finding the cause of the FORMERR and resolve it? -- Ian -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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
