Re: Correct response to NS request in case of dual delegation when one delegation returns REFUSED

[Tony Finch]

Ondřej Surý  wrote:
>
> > 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.

And, Marki, if you need a pointer to where this behaviour is specified,
look at https://www.rfc-editor.org/rfc/rfc2181#section-5.4.1

In particular,

 + The authoritative data included in the answer section of an
   authoritative reply.

In your case this is the single-record NS answer from one of the clusters,
and it outranks:

 + Additional information from an authoritative answer,
   Data from the authority section of a non-authoritative answer,
   Additional information from non-authoritative answers.

In your case this is the two-record NS in the referral from your parent
zone.

If these devices allow you to configure DNS servers for readiness checks
separately from general-purpose DNS, then you might be able to work around
the problem by pointing the readiness checks at an authoritative-only
server, if the devices are willing to find their answer in the AUTHORITY
section of the response. If. Maybe.

-- 
Tony Finch(he/they)  Cambridge, England
Trafalgar: In southeast, northerly, but easterly in far southeast, 4
to 6, increasing 7, perhaps gale 8 later, near gibraltar strait. In
northwest, variable 2 to 4, becoming northerly 5 later in southeast.
In southeast, moderate, occasionally rough. in northwest, rough
becoming moderate. In southeast, fair. In northwest, showers later. In
southeast, good. In northwest, good.-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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

[frank picabia]

Thanks for this detailed information, Mark.

I'll blame it on the antibiotics and old age but I had never noticed the
key is actually complete in my dsset file
if I don't interpret the space as a delimiter.

So there are two ways to get the DS keys: from the dsset file while
ignoring the space between the two values of digest 2,
or by using the dnssec-dsfromkey method while querying one's DNS server.

My domain registrar has the values now and we're good.  Thanks for the
assistance.


On Wed, May 18, 2022 at 2:16 PM Mark Andrews  wrote:

> 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 fo

AW: High memory consumption in bind 9.18.2

[Klaus Darilion via bind-users]

Hi Petr!

Thanks for the commands. But it seems I do not need them. I have updated 2 of 
our RcodeZero nameservers and on both servers the memory consumption is now 
lower than it was with 9.16. So I am not sure any more if memory was the 
problem why we went back to 9.16. I will check again in a few days.

Meanwhile I think the problem with 9.18 was a different one: we use bind as 
"distribution" name server with several hughe zones. So XFR from customer in, 
and XRF out to 20+ slaves. When we upgraded to 9.18, suddenly the slaves (Bind, 
Nsd...) needed longer to update their zones. As we did not had time to 
investigate we went back to 9.16 and suddenly slaves updated fast again. If 
this is still an issue we will see when we upgrade our distribution master to 
9.18 and if yes, I will start another thread.

Thanks
Klaus

> -Ursprüngliche Nachricht-
> Von: Petr Špaček 
> Gesendet: Donnerstag, 19. Mai 2022 12:22
> An: Klaus Darilion 
> Cc: bind-users@lists.isc.org
> Betreff: Re: High memory consumption in bind 9.18.2
> 
> On 18. 05. 22 22:39, Ondřej Surý wrote:
> > 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.
> 
> Here are commands you asked for:
> 
> 1. when running ./configure, make sure the output at the end has this:
> 
> Configuration summary:
> ---
> Optional features enabled:
>  Memory allocator: jemalloc
> 
> 
> 2. Then, configure statistics channel in named.conf like this:
> 
> statistics-channels {
>   inet 127.0.0.1 port 8080;
> };
> 
> 
> 3. With that in place you can grab stats from this URL:
> http://127.0.0.1:8080/json/v1
> 
> Configuration for v9.16 is the same, just skip the jemalloc part.
> 
> 4. Bonus points for grabbing /proc//statm content at the same time
> as content of the JSON stats endpoint (if you are on Linux).
> 
> I hope it helps.
> Petr Špaček
> 
> 
> 
> >
> > 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  us...@lists.isc.org> 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
>

Re: High memory consumption in bind 9.18.2

[Petr Špaček]

On 18. 05. 22 22:39, Ondřej Surý wrote:

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.


Here are commands you asked for:

1. when running ./configure, make sure the output at the end has this:

Configuration summary:
---
Optional features enabled:
Memory allocator: jemalloc


2. Then, configure statistics channel in named.conf like this:

statistics-channels {
inet 127.0.0.1 port 8080;
};


3. With that in place you can grab stats from this URL:
http://127.0.0.1:8080/json/v1

Configuration for v9.16 is the same, just skip the jemalloc part.

4. Bonus points for grabbing /proc//statm content at the same time 
as content of the JSON stats endpoint (if you are on Linux).


I hope it helps.
Petr Špaček





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



--
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