Re: DNSSEC problem with our zone
Mirsad Goran Todorovac writes: > Dear All, > > In the past three days I have just made our domain DNSSEC > signed. However, I seem to be missing something. > > When I query other DNS servers, like CloudFlare 1.0.0.1, I get the > "ad" flag. > > But in my own domain, and my own domain servers, the "ad" flag is > still missing: > > root@domac:/var/cache/bind# dig -u @161.53.235.3 domac.alu.hr a > +dnssec +multiline > > ; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> -u @161.53.235.3 > domac.alu.hr a +dnssec +multiline > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5934 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 This is normal and expected. You don't get validation on the authoritative servers. So if you see aa then there will be no ad. Just check a few other signed zones and you'll see the same there. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC problem with our zone
Dear All, In the past three days I have just made our domain DNSSEC signed. However, I seem to be missing something. When I query other DNS servers, like CloudFlare 1.0.0.1, I get the "ad" flag. But in my own domain, and my own domain servers, the "ad" flag is still missing: root@domac:/var/cache/bind# dig -u @161.53.235.3 domac.alu.hr a +dnssec +multiline ; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> -u @161.53.235.3 domac.alu.hr a +dnssec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5934 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 172503ebbe7de2420100628512077e46d89b4369e3dd (good) ;; QUESTION SECTION: ;domac.alu.hr. IN A ;; ANSWER SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 domac.alu.hr. 86400 IN RRSIG A 8 3 86400 ( 20220615102400 20220516102400 46119 alu.hr. tHS58DiuHm0BTCbpyR7k9G9YRtl0iG03Sl5YBK55tBQF MqR5Bdk9t0Gz8HTFvqYd2kO7jHVRP5hBsMpETXo1PTWa FYq5WAd4NW+qNJg2giVp04ZC0agS+rPaCQZgeUXuneUk 5wle1qc5GF+R3E8rheTioWPJLw+L2V/n39LYOlQ= ) ;; Query time: 189 usec ;; SERVER: 161.53.235.3#53(161.53.235.3) ;; WHEN: Wed May 18 17:34:31 CEST 2022 ;; MSG SIZE rcvd: 251 root@domac:/var/cache/bind# Can you please help? Thank you very much. Kind regards, Mirsad On 5/18/2022 4:14 PM, Mirsad Goran Todorovac wrote: Dear Sir or Madam, According to this article: https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , I did everything right by following the APNIC article for manual signing procedure. And uploaded DS record made of zone KSK hash to the parent domain's registrar.carnet.hr : root@domac:/etc/bind/keys# dig @localhost dnskey alu.hr | dnssec-dsfromkey -f - alu.hr alu.hr. IN DS 34042 8 2 FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5885BBF08 root@domac:/etc/bind/keys# host -t ds alu.hr alu.hr has DS record 34042 8 2 FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5 885BBF08 root@domac:/etc/bind/keys# The BIND version we use is 9.16.27, latest backport on Debian buster: root@domac:/etc/bind/keys# dpkg -l | grep bind9 | grep 9.16 ii bind9 1:9.16.27-1~deb11u1~bpo10+1 amd64 Internet Domain Name Server ii bind9-libs:amd64 1:9.16.27-1~deb11u1~bpo10+1 amd64 Shared Libraries used by BIND 9 ii bind9-utils 1:9.16.27-1~deb11u1~bpo10+1 amd64 Utilities for BIND 9 ii bind9utils 1:9.16.27-1~deb11u1~bpo10+1 all Transitional package for bind9-utils However, for some reason the validation doesn't give me the "ad" authenticated data flag in dig queries. There must be something I'm missing. I would be grateful for any help. P.S. I withdraw my question. Now it automagically started working (the "ad" flag appeared): root@magrf:~# dig @127.0.0.1 domac.alu.hr +dnssec +multiline ; <<>> DiG 9.16.27-Debian <<>> @127.0.0.1 domac.alu.hr +dnssec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55024 ;; flags: qr rd ra *ad*; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: ac834aa33f88f00601006284fdf6c5738a0b6f9bde2b (good) ;; QUESTION SECTION: ;domac.alu.hr. IN A ;; ANSWER SECTION: domac.alu.hr. 86400 IN A 161.53.235.3 domac.alu.hr. 86400 IN RRSIG A 8 3 86400 ( 20220615102400 20220516102400 46119 alu.hr. tHS58DiuHm0BTCbpyR7k9G9YRtl0iG03Sl5YBK55tBQF MqR5Bdk9t0Gz8HTFvqYd2kO7jHVRP5hBsMpETXo1PTWa FYq5WAd4NW+qNJg2giVp04ZC0agS+rPaCQZgeUXuneUk 5wle1qc5GF+R3E8rheTioWPJLw+L2V/n39LYOlQ= ) ;; Query time: 39 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 18 16:08:54 CEST 2022 ;; MSG SIZE rcvd: 251 root@magrf:~# Thank you for any help. At least I was motivated to do more homework. I believe there is a future for DNSSEC, much like nowadays we do not have too many legacy sites that request password without HTTPS. I guess now our domain won't be easily spoofed :-) The next step is to make the subzone delegation and automatic DS record upload to the main zone, for maintaining half a dozen of DS delegations might become infeasible if the KSK expires every couple of months :-/ Thank you for your time reading this. You are patient if you came this far. Kind regards, Mirsad Todorovac On 5/18/2022 11:52 AM, Mirsad Goran Todorovac wrote: Dear Sir or Madam, I have tried to implement an instance of DNSSEC signed DNS zone at our Academy's server. Though we apparently got away without anything catastrophic, the DNSSEC apparently doesn't work, despite doing everything like in the tutorial: https://blog.apnic.net/2019/05/23/how-to-deploying-dnssec-with-bind-and-ubuntu-server/ I recall getting help here with dynamic ISC DHCP-updated reverse zone lookup for sub/24 rev zone. And it
Re: High memory consumption in bind 9.18.2
Hi Klarstein, Gathering the output of named statschannel should be good enough for initial assessment (json please). For 9.18, make sure the jemalloc is being used at runtime. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 18. 5. 2022, at 22:32, Klaus Darilion via bind-users > wrote: > > Can you please provide some commands whose output you are interested? I want > to collect the statistics for 9.16 before updating to 9.18. > Thanks > Klaus > >> -Ursprüngliche Nachricht- >> Von: bind-users Im Auftrag von Petr >> Špacek >> Gesendet: Mittwoch, 18. Mai 2022 18:20 >> An: bind-users@lists.isc.org >> Betreff: Re: AW: High memory consumption in bind 9.18.2 >> >> I would be very interested in hearing more! >> >> In majority of our internal testing 9.16 has higher memory consumption >> than 9.18, especially when 9.18 is compiled with libjemalloc. And the >> differences are not small, for some configurations it can be even 2x or >> 3x more on 9.16 than it is on 9.18. >> >> If you encounter it again please get back to us so we can diagnose it. >> >> Thank you! >> Petr Špaček >> >> >>> On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote: >>> I remember we had similar issues with 9.18 (isc ppa packages) and hence >> wen't back to 9.16. But I can not remember the details. >>> >>> regards >>> Klaus >>> -Ursprüngliche Nachricht- Von: bind-users Im Auftrag von >> Ondrej Surý101 71 l t1h, 18. Mai 2022 08:37 An: Raman kumar Cc: bind-users@lists.isc.org Betreff: Re: High memory consumption in bind 9.18.2 You did not provided any details, so we can’t really help you. What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from >> stats channel from named? What’s the hardware, what is the configuration, how was BIND 9 compiled (or packaged)? The more details, the better Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do >> not feel obligated to reply outside your normal working hours. > On 18. 5. 2022, at 8:32, Raman kumar wrote: > > Hello Team, > > While upgrading from BIND 9.16.10 to 9.18.2, we have observed high memory consumption. > > On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM consumption is 4.5 GB. Due to this an increase of approximately 20 % memory is observed. > > Is this the expected behaviour or any tuning is needed? > > Thanks in advance. > > Regards, > Raman > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >> from this list > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >>> >> >> >> -- >> Petr Špaček >> -- >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >> this >> list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://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
AW: AW: High memory consumption in bind 9.18.2
Can you please provide some commands whose output you are interested? I want to collect the statistics for 9.16 before updating to 9.18. Thanks Klaus > -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Petr > Špacek > Gesendet: Mittwoch, 18. Mai 2022 18:20 > An: bind-users@lists.isc.org > Betreff: Re: AW: High memory consumption in bind 9.18.2 > > I would be very interested in hearing more! > > In majority of our internal testing 9.16 has higher memory consumption > than 9.18, especially when 9.18 is compiled with libjemalloc. And the > differences are not small, for some configurations it can be even 2x or > 3x more on 9.16 than it is on 9.18. > > If you encounter it again please get back to us so we can diagnose it. > > Thank you! > Petr Špaček > > > On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote: > > I remember we had similar issues with 9.18 (isc ppa packages) and hence > wen't back to 9.16. But I can not remember the details. > > > > regards > > Klaus > > > >> -Ursprüngliche Nachricht- > >> Von: bind-users Im Auftrag von > Ondrej > >> Surý101 71 l t1h, 18. Mai 2022 08:37 > >> An: Raman kumar > >> Cc: bind-users@lists.isc.org > >> Betreff: Re: High memory consumption in bind 9.18.2 > >> > >> You did not provided any details, so we can’t really help you. > >> > >> What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from > stats > >> channel from named? > >> > >> What’s the hardware, what is the configuration, how was BIND 9 compiled > >> (or packaged)? > >> > >> The more details, the better > >> > >> Ondrej > >> -- > >> Ondřej Surý (He/Him) > >> ond...@isc.org > >> > >> My working hours and your working hours may be different. Please do > not > >> feel obligated to reply outside your normal working hours. > >> > >>> On 18. 5. 2022, at 8:32, Raman kumar > >> wrote: > >>> > >>> Hello Team, > >>> > >>> While upgrading from BIND 9.16.10 to 9.18.2, we have observed high > >> memory consumption. > >>> > >>> On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM > >> consumption is 4.5 GB. Due to this an increase of approximately 20 % > >> memory is observed. > >>> > >>> Is this the expected behaviour or any tuning is needed? > >>> > >>> Thanks in advance. > >>> > >>> Regards, > >>> Raman > >>> -- > >>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from > >> this list > >>> > >>> ISC funds the development of this software with paid support > >> subscriptions. Contact us at https://www.isc.org/contact/ for more > >> information. > >>> > >>> > >>> bind-users mailing list > >>> bind-users@lists.isc.org > >>> https://lists.isc.org/mailman/listinfo/bind-users > > > > > -- > Petr Špaček > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this > list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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: Only one DS key comes back in query
I suspect that you failed to copy the complete second record or that the registrar failed to handle the optional white space in the last field. Without you posting the contents of the dsset file and what you passed to the registrar there is no way to know. There is also no way to know if it was miscomputed unless we have a copy of the DNSKEY it was generated from. example.com. IN DS 28387 5 1 47145FCABDFC00DD9CDE1369FA6A456F0D196C11 example.com. IN DS 28387 5 2 AC92037CEB08E7AF3539D140BC3855FA32AB0055973ABC7A4FB4A49C 385E7C29 The second record could be written like below and it would still be correct. example.com. IN DS 28387 5 2 A C 9 2 0 3 7 C E B 0 8 E 7 A F 3 5 3 9 D 1 4 0 B C 3 8 5 5 F A 3 2 A B 0 0 5 5 9 7 3 A B C 7 A 4 F B 4 A 4 9 C 3 8 5 E 7 C 2 9 As for how many records there are in the dsset file that has changed over time. It started out as just type 1 (SHA1), then type 1 (SHA1) and type 2 (SHA256), and more recently just type 2 (SHA256) as the DNSSEC standards evolve based on changes in cryptographic best practice. DNSSEC is approximately 20 years old now and computing capabilities have changed a lot over that period. I know computers are not infallible but dnssec-signzone has been generating dsset files for almost all of those 20 years now. We would be getting thousands of reports of errors if it was mis-generating DS records. Named itself needs to generate 10’s of thousands of DS records a second to perform DNSSEC validations on a busy validator and dnssec-signzone uses the same code to generate the DS records it prints out. Using ‘example’ is fine until something goes wrong or it is believed to have gone wrong. At that point you need the actual real names. You don’t go to your mechanic with a different car when you have a problem with your car. Using ‘example’ is like doing that. Mark > On 17 May 2022, at 04:41, frank picabia wrote: > > I've been using open source for decades. Long enough that I rarely need to > use lists for help. > > Here's the RFC mentioning reserved domain name use: > https://www.rfc-editor.org/rfc/rfc2606.html > > I am ridiculed by an ISC member for using a reserved domain according to the > purpose in the RFC and then > a second ISC member states I am arrogant? I think there's a bunch of you > that need to check your privilege! > Or maybe these persons are the chief whips responsible for driving people > from the lists into paying customers? > > Check other lists. Postfix. Apache. Whatever. No one ever has an issue > when they see example.com > It's widely known as the boilerplate value you're leaving out of the equation > for the moment. > > In the documentation I see this: > > Once the rndc reconfig command is issued, BIND serves a signed zone. The file > dsset-example.com (created by dnssec-signzone when it signed the example.com > zone) contains the DS record for the zone’s KSK. You will need to pass that > to the administrator of the parent zone, to be placed in the zone. > > It seems the first value in dsset file is okay. The documentation doesn't > talk about the second one, and this is where > the problem is seen. I see one value on the second key (digest 2) in dsset > file, and a different value using the value > obtained by running something like: > > dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net > The digest 2 second key here seems to be what should be used with the domain > registrar. I'll soon find out. > > > > On Mon, May 16, 2022 at 2:54 PM Ondřej Surý wrote: > Well, then don’t expect people will want to help you. If you need to hide the > information and you need help then you should be prepared to pay for the > support. Coming to open source list asking for help for free and expect other > people to help you is just plain arrogant behavior. Again, Bert Hubert was > exactly right here: > > https://berthub.eu/articles/posts/anonymous-help/ > > 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 16. 5. 2022, at 19:06, frank picabia wrote: >> >> Suppose I was working on a problem for Barclays >> Bank, do you suppose they would be thrilled with me posting >> their networking innards for the world to see? > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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
Re: High memory consumption in bind 9.18.2
Also please note that proper measurement of memory consumption is needed. There’s some good (semi-accurate) stuff at SO and it needs to be correlated with the statschannel output from named. Running “free” doesn’t measure memory consumption by any program. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 18. 5. 2022, at 18:19, Petr Špaček wrote: > > I would be very interested in hearing more! > > In majority of our internal testing 9.16 has higher memory consumption than > 9.18, especially when 9.18 is compiled with libjemalloc. And the differences > are not small, for some configurations it can be even 2x or 3x more on 9.16 > than it is on 9.18. > > If you encounter it again please get back to us so we can diagnose it. > > Thank you! > Petr Špaček > > >> On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote: >> I remember we had similar issues with 9.18 (isc ppa packages) and hence >> wen't back to 9.16. But I can not remember the details. >> regards >> Klaus >>> -Ursprüngliche Nachricht- >>> Von: bind-users Im Auftrag von Ondrej >>> Surý101 71 l t1h, 18. Mai 2022 08:37 >>> An: Raman kumar >>> Cc: bind-users@lists.isc.org >>> Betreff: Re: High memory consumption in bind 9.18.2 >>> >>> You did not provided any details, so we can’t really help you. >>> >>> What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from stats >>> channel from named? >>> >>> What’s the hardware, what is the configuration, how was BIND 9 compiled >>> (or packaged)? >>> >>> The more details, the better >>> >>> Ondrej >>> -- >>> Ondřej Surý (He/Him) >>> ond...@isc.org >>> >>> My working hours and your working hours may be different. Please do not >>> feel obligated to reply outside your normal working hours. >>> On 18. 5. 2022, at 8:32, Raman kumar >>> wrote: Hello Team, While upgrading from BIND 9.16.10 to 9.18.2, we have observed high >>> memory consumption. On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM >>> consumption is 4.5 GB. Due to this an increase of approximately 20 % >>> memory is observed. Is this the expected behaviour or any tuning is needed? Thanks in advance. Regards, Raman -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >>> this list ISC funds the development of this software with paid support >>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>> information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users > > > -- > Petr Špaček > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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: AW: High memory consumption in bind 9.18.2
I would be very interested in hearing more! In majority of our internal testing 9.16 has higher memory consumption than 9.18, especially when 9.18 is compiled with libjemalloc. And the differences are not small, for some configurations it can be even 2x or 3x more on 9.16 than it is on 9.18. If you encounter it again please get back to us so we can diagnose it. Thank you! Petr Špaček On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote: I remember we had similar issues with 9.18 (isc ppa packages) and hence wen't back to 9.16. But I can not remember the details. regards Klaus -Ursprüngliche Nachricht- Von: bind-users Im Auftrag von Ondrej Surý101 71 l t1h, 18. Mai 2022 08:37 An: Raman kumar Cc: bind-users@lists.isc.org Betreff: Re: High memory consumption in bind 9.18.2 You did not provided any details, so we can’t really help you. What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from stats channel from named? What’s the hardware, what is the configuration, how was BIND 9 compiled (or packaged)? The more details, the better Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 18. 5. 2022, at 8:32, Raman kumar wrote: Hello Team, While upgrading from BIND 9.16.10 to 9.18.2, we have observed high memory consumption. On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM consumption is 4.5 GB. Due to this an increase of approximately 20 % memory is observed. Is this the expected behaviour or any tuning is needed? Thanks in advance. Regards, Raman -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: Only one DS key comes back in query
On Mon, May 16, 2022 at 2:41 PM frank picabia wrote: > I've been using open source for decades. Long enough that I rarely need > to use lists for help. > > Here's the RFC mentioning reserved domain name use: > https://www.rfc-editor.org/rfc/rfc2606.html > Those reservations are for testing and documentation examples. They're not particularly useful when requesting help for specific problems, unless you're doing something like a search/replace on detailed query output in order to redact it. Even if you do that you have to be very careful not to change things the wrong way, or it further confuses the issue. You're much better off just sharing the domain name you're concerned with. If you're asking for help about a real configuration, you're going to get limited effort back from the community if you don't provide them with enough information to help you. Since you're not providing DNS queries (even redacted ones) that show the problem, that means they can't see enough information to actually answer your questions. Also hiding the domain name in question means they can't check for themselves what the contents of your zone or your parent zone are, and so they are left with insufficient information to provide you help. It makes matters worse that you are using phrases that subtly suggest you may be making incorrect assumptions, which leads people to really want to check what the real data is. And people are absolutely right to tell you that if you're working for such a large, public company that they would be embarrassed by you asking for help publicly, then they should pay for support so that they can get that help privately. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://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: High memory consumption in bind 9.18.2
Hello, Please find the details below. Free command is used to check RAM available/used. space used is 50GB on RHEL 7.9 in bind version 9.18.2 whereas in bind version 9.16.10 RAM space used is 44 GB with the same amount of data and configuration. free -g totalusedfree shared buff/cache available Mem: 50 50 0 0 0 0 Swap: 9 0 9 starting BIND 9.18.2 (Stable Release) named[31521]: running on Linux x86_64 3.10.0-1160.59.1.el7.x86_64 #1 SMP named[31521]: built with '--prefix=/opt/bind' '--sysconfdir=/etc/opt/bind' '--with-openssl=no' '--disable-doh' 'PKG_CONFIG_PATH=/usr/lib/pkgconfig' running as: named -n 4 -c /etc/opt/bind/named.conf.0 compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44) compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017 linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017 compiled with libxml2 version: 2.9.1 linked to libxml2 version: 20901 compiled with zlib version: 1.2.7 linked to zlib version: 1.2.7 Regards, Raman On Wed, May 18, 2022 at 12:06 PM Ondřej Surý wrote: > You did not provided any details, so we can’t really help you. > > What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from stats > channel from named? > > What’s the hardware, what is the configuration, how was BIND 9 compiled > (or packaged)? > > The more details, the better > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > On 18. 5. 2022, at 8:32, Raman kumar wrote: > > > > Hello Team, > > > > While upgrading from BIND 9.16.10 to 9.18.2, we have observed high > memory consumption. > > > > On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM > consumption is 4.5 GB. Due to this an increase of approximately 20 % memory > is observed. > > > > Is this the expected behaviour or any tuning is needed? > > > > Thanks in advance. > > > > Regards, > > Raman > > -- > > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://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: Correct response to NS request in case of dual delegation when one delegation returns REFUSED
Hi, > 1) client asks Bind: what is NS for "cluster"? > 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS > cluster", one of which always returns "REFUSED" > 3) Answer of Bind to client does not contain the one that was "refused". no, I think it’s different problem. Both storage1 and storage2 need to return the full set of NS for the cluster query because the NS set from child zone will override the delegation from the parent. DNS protocol works this way, when you ask for cluster. NS record: 1. Ask for cluster to the parent zone (), both NS records are returned as delegation (and cached) 2. Ask for cluster to the child zone (cluster.), single NS record is returned and it overrides the cache, so only single record is there You can verify that by issuing these request manually using dig. Beyond that, if you need more help, you’ll need to go into more details. > My conclusion is that Windows DNS is an abomination. And relying on an > inherently faulty behavior leads straight to hell. I cannot confirm or deny this conclusion... Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 18. 5. 2022, at 9:36, Marki wrote: > > Hello, > > We are currently working with a product called Superna Eyeglass which can be > used for DR purposes on Powerscale (Dell storages). > > Quick background: Powerscale leverages DNS to create redundant and > load-balanced frontend access. Without going into many details, Powerscale > replies to DNS requests on a service IP (SSIP) indicating which node of the > cluster should be used for the incoming connection. To that end, it requires > you to delegate one (or more) zones to that SSIP. > > Now Eyeglass (the DR product) recommends using "dual delegation" for failover > purposes (there are two distinct clusters (active/passive) which are not > necessarily in-sync at any given moment in time). > > What they tell you to do is: Create a service name with two delegations/NS > records pointing to both storages' SSIPs, the one currently not active will > return REFUSED. > > i.e. you have > cluster IN NS storage1 > cluster IN NS storage2 > > Now they have "readiness" checks where they try to determine if that dual > delegation is set up correctly. > > However, Bind only seems to return one of those nameservers when asked for > it. Example: > > 1) client asks Bind: what is NS for "cluster"? > 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS > cluster", one of which always returns "REFUSED" > 3) Answer of Bind to client does not contain the one that was "refused". > > Therefore that readiness check is not working. They claim this is normal and > that they only support Windows DNS for that check. > > My conclusion is that Windows DNS is an abomination. And relying on an > inherently faulty behavior leads straight to hell. > > Am I missing something? Is Bind behaving correctly? > > Thanks, > Marki > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://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
Correct response to NS request in case of dual delegation when one delegation returns REFUSED
Hello, We are currently working with a product called Superna Eyeglass which can be used for DR purposes on Powerscale (Dell storages). Quick background: Powerscale leverages DNS to create redundant and load-balanced frontend access. Without going into many details, Powerscale replies to DNS requests on a service IP (SSIP) indicating which node of the cluster should be used for the incoming connection. To that end, it requires you to delegate one (or more) zones to that SSIP. Now Eyeglass (the DR product) recommends using "dual delegation" for failover purposes (there are two distinct clusters (active/passive) which are not necessarily in-sync at any given moment in time). What they tell you to do is: Create a service name with two delegations/NS records pointing to both storages' SSIPs, the one currently not active will return REFUSED. i.e. you have cluster IN NS storage1 cluster IN NS storage2 Now they have "readiness" checks where they try to determine if that dual delegation is set up correctly. However, Bind only seems to return one of those nameservers when asked for it. Example: 1) client asks Bind: what is NS for "cluster"? 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS cluster", one of which always returns "REFUSED" 3) Answer of Bind to client does not contain the one that was "refused". Therefore that readiness check is not working. They claim this is normal and that they only support Windows DNS for that check. My conclusion is that Windows DNS is an abomination. And relying on an inherently faulty behavior leads straight to hell. Am I missing something? Is Bind behaving correctly? Thanks, Marki -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
