Greg, What other awesome stuff do you have on the top of your head? This makes
sense as it’s running on EC2 @AWS (I.e. poor source of randomness on VM’s).
And thanks to Grant for the haveged suggestion. Initial tests with haveged
running seem to be positive.
I’ll report back here if the
> TLD Signed? Comments
> -----
> google.comno
> gmail.com no
> youtube.com no
> apple.com no
> microsoft.com no
> amazon.comno
> walmart.com no
> outlook.com no
> 1e100.net no
> facebook.com no
> twitter.com no
> instagram.com
On 8/1/22 4:21 PM, Greg Choules via bind-users wrote:
Off the top of my head, could it be this?
random-device
...
BIND will need a good source of randomness for crypto operations.
Drive by plug: If it is lack of entropy, try installing and running
Haveged. At least as a troubleshooting
Hi Peter.
Off the top of my head, could it be this?
random-device
The source of entropy to be used by the server. Entropy is primarily needed
for DNSSEC operations, such as TKEY transactions and dynamic update of
signed zones. This options specifies the device (or file) from which to
read
I’m running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 (Extended Support
Version) on RHEL 7 in a chroot jail.
As of late, at times running some rndc commands are causing my server to lock
up. It’s usually an “rndc addzone” that triggers the issue. I’ll also mention
that I have recently started
DNSSEC is designed to be validated in the application. That applies equally to
internal zones as it does to external zones. One procedure for them all.
--
Mark Andrews
> On 1 Aug 2022, at 11:15, John W. Blue via bind-users
> wrote:
>
>
> As some enterprise networks begin to engineer
There has been lots of discussion recently about DNSSEC issues, including
whether it's desirable to sign internal zones. Independent of this most recent
issue, a couple of weeks ago I did an informal survey, using DNSVIZ, of various
TLDs. I found the following rather surprising results:
Retesting with stock Debian bullseye (with extra OpenSSL 3.0.0)
and default configuration options:
TL;DR
9.16(git): 30648752
9.18(git): 30081280
So, pretty consistent with what I’ve seen here so far. And it seems that
the extra (developer) configure options, I’ve been using before have
little/no
Let's flip this on it's head.
On 8/1/22 10:15 AM, John W. Blue via bind-users wrote:
As some enterprise networks begin to engineer towards the concepts of
ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC
signing of an internal zone.
So why shouldn't the internal zone(s) be
Don’t mix functions - separate your recursive and your authoritative (internal)
servers. Then you can have the AD from the resolver.
That said, the AD from the resolver means something only if the last mile is
trusted.
But DNSSEC also asserts the integrity of the zone in case it’s transferred
Also John .. how SSHA and TLSA be used if the internal zone fails validation?
John
-Original Message-
From: John Franklin [mailto:frank...@sentaidigital.com]
Sent: Monday, August 1, 2022 12:45 PM
To: John W. Blue
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC signing of an internal
Keep in mind that the discussion is limited to an internal zone only. Running
authoritative and recursive at the same time cannot be labeled as a “terribly
bad practice”:
https://kb.isc.org/docs/bind-best-practices-recursive
“administrators may, for convenience, choose to serve some
> On 1. 8. 2022, at 20:05, Dmitri Pavlov wrote:
> The records generation part is different though , using shell script
> basically. Unique IPs were linked with unique CNAMEs.
I would need the exact algorithm how did you generate the zones.
BTW using shell for this takes ages. Generating zone
Hmmm - might be saying the wrong thing but...
.SE was DNSSEC Signed waaay before the root, so if living in Sweden, one
would prep your DNSSEC aware resolver with the DS Key of the .SE Zone.
DNSSEC then worked for .SE domains. Perhaps do the same?
I do get confused further down in this email
Thank you very much for the swift response, Ondrej,
You are right. Local configuration is more "trivial" so to say -> it is RHEL
7.9 3.10.0-1160.71.1.el7.x86_64 with gcc-4.8.5-44.el7.x86_64.
Our installation / test flow was very basic. The records generation part is
different though , using
On 8/1/22 11:51 AM, John W. Blue via bind-users wrote:
However, the intent of the thread is to talk about the lack of an
AD flag from a non-public internal authoritative server. Based upon
what I am seeing only the AA flag is set.
There are multiple reasons to sign zones. The existence of
Also do not disagree.
However, the intent of the thread is to talk about the lack of an AD flag from
a non-public internal authoritative server. Based upon what I am seeing only
the AA flag is set.
John
-Original Message-
From: John Franklin [mailto:frank...@sentaidigital.com]
Sent:
$ wc -l gen.db
1 gen.db
generated with:
#!/bin/env python3
for x in range(0, 1):
for y in range(0, 2500):
print(f"az{x}-{y} IN A 10.53.0.1")
print(f"bz{x}-{y} IN A 10.53.0.2")
print(f"ca{x}-{y} IN A 10.53.0.3")
print(f"xh{x}-{y} IN CNAME
And that is my point .. show me your +dnssec dig against an internal
authoritative server that has AD set.
John
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Grant
Taylor via bind-users
Sent: Monday, August 1, 2022 11:29 AM
To:
On 8/1/22 10:15 AM, John W. Blue via bind-users wrote:
While that extra overhead is true, it is more accurate to say that if
internal clients are talking directly to an authoritative server the AD
flag will not be set. You will only get the AA flag. So there is
nothing to be gained from
As some enterprise networks begin to engineer towards the concepts of
ZeroTrust, one item caught me unaware: PM's asking for the DNSSEC signing of
an internal zone.
Granted, it has long been considered unwise by DNS pro's with a commonly stated
reason that it increasing the size of the zone
> On 1. 8. 2022, at 17:19, Dmitri Pavlov wrote:
>
> I’m pretty much sure you will get the same results in your lab.
I don’t want to delve into vague description of your experiment. You’ll have to
share the exact scripts.
Even this:
> just the time-consuming task is to generate 100 MIL A +
Hi,
Sorry one more thing. It is not a memory leak . In the experiment the data is
being pulled from the disk zone file and loaded into memory. Then the process
sits idle. RAM utilization is stable. In other words, it is a footprint of the
file into the cache. Easy experiment -> just the
--
Best regards
Sten Carlsen
--
Aoccdrnig to rseerach at Cmabrigde Uinervtisy,
it deosn't mttaer in waht oredr the ltteers in a
wrod are, the olny iprmoatnt tihng is taht the
frist and lsat lteter be at the rghit pclae.
The rset can be a ttoal
Thank you ISC,
New run with the same input
#9.18.5
pmap -x ... | tail -n 1
total kB 34892476 29399048 29395316
#9.16.21
pmap -x ... | tail -n 1
total kB 27935060 27341676 27338344
The diff. Is still the same ~ 2 GB.
I’m pretty much sure you will get the same results in your
Hi Doug,
I think Ondrej is referring to this post from a prior month:
https://lists.isc.org/pipermail/bind-users/2022-June/106350.html
….
For tips on how to measure memory usage you might want to look at
> On 1. 8. 2022, at 16:14, Doug Whitfield wrote:
>
> as monitored from "top" RES value
Please read the whole thread on measuring the real consumed memory.
The '“top” RES value' has little or no value at all.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working
Hi ISC,
We have run an experiment with:
1. one zone
2. basic configuration
3. ~100 MIL of A(2/3 of all records) + CNAME(1/3 of all records) records in the
zone file. Other types not tested.
RAM consumption (as monitored from "top" RES value) in RHEL 7.9 was 2 GB higher
in 9.18.5 (with
28 matches
Mail list logo
