On 21/06/2025 05:16, Florian Piekert via bind-users wrote:
Hello,
wow, that did the trick. I didn't think of this at all. It -after all-
appeared to be VERY obvious. I don't know why I overlooked this
possibilty.
THANK YOU!
Am 20.06.2025 um 19:03 schrieb Crist Clark:
Do you have a .signed f
amed, kill that file, then restart. But removing the file and just doing an rndc
reload on the zone may be enough.
On Fri, Jun 20, 2025 at 7:20 AM Florian Piekert via bind-users mailto:bind-users@lists.isc.org>> wrote:
Dear all,
I have tried some faulty ways to setup dnssec for so
Dear all,
I have tried some faulty ways to setup dnssec for some of my domains about a
month ago. This resulted in the creation of several ZSK, KSK and CSK dnssec
keys (and files) until I got a configuration that actually was working as it
should. Due to proper ignorance and non-knowledge I
Hi Luca,
This is correct: dnssec-validation auto; If you use "yes" there, then
you must supply a trust anchor. Auto is the default.
The only idea I have is this:
zone "." IN {
type hint;
file "named.ca";
};
You don't need this anymore. BIND 9.18 wil
Hello!
I run a server with Bind9.18 on Alma9.
It acts as the nameserver for two domains. (with glue records from the
registrar).
DNSSEC is enabled but somehow outbound queries are not validated?
Domains with dnssec do have the "ad" flag though. The local domains somehow
dont have t
On 4/9/25 02:29, Bagas Sanjaya wrote:
On Tue, Apr 08, 2025 at 07:38:44AM -0500, Matthijs Mekking wrote:
This time I was able to reproduce, thanks.
The reason why the key created by dnssec-keygen is retired because named
thinks it was in use already. When there is key timing metadata, the
On Tue, Apr 08, 2025 at 07:38:44AM -0500, Matthijs Mekking wrote:
> This time I was able to reproduce, thanks.
>
> The reason why the key created by dnssec-keygen is retired because named
> thinks it was in use already. When there is key timing metadata, the key is
> considered to
; On 3/26/25 14:51, Nguyen Thi Minh Tam via bind-users wrote:
> > "Hi, I'm trying version 9.18.31.
> >
> > According to the post on
> > https://kb.isc.org/docs/dnssec-key-and-signing-policy
> > <https://kb.isc.org/docs/dnssec-key-and-signing-policy>,
This time I was able to reproduce, thanks.
The reason why the key created by dnssec-keygen is retired because named
thinks it was in use already. When there is key timing metadata, the key
is considered to be in use (now or in the past).
Only not previously used keys are considered as a
to reproduce the issue.
Any logs (preferably debug level 3) would then also be greatly appreciated.
Thanks, best regards,
Matthijs
On 3/26/25 14:51, Nguyen Thi Minh Tam via bind-users wrote:
"Hi, I'm trying version 9.18.31.
According to the post on
https://kb.isc.org/docs/dnss
"Hi, I'm trying version 9.18.31.
According to the post on https://kb.isc.org/docs/dnssec-key-and-signing-policy,
the policy normally generates keys when they are needed. However, we can
generate the DNSSEC keys ourselves first, and when the policy requires a new
key, it will select
policy to setup DNSSEC on some zone.
When a KSK are "hidden" and present with "rndc dnssec -status ",
i moved it to an archive repository.
But this generate many logs :
mars 19 09:15:46 xxx named[2378461]: 19-Mar-2025
09:15:46.149 dnssec: error: zo
Hello,
I use Bind 9.20.4, with KASP policy to setup DNSSEC on some zone.
When a KSK are "hidden" and present with "rndc dnssec -status ",
i moved it to an archive repository.
But this generate many logs :
mars 19 09:15:46 xxx named[2378461]: 19-Mar-2025
09:15:
Thanks I'll try that.
-Original Message-
From: Evan Hunt
Sent: Thursday, March 6, 2025 1:46 PM
To: Chris Isaksen
Cc: bind-users@lists.isc.org
Subject: Re: Questions about "dnssec validation" statement
On Thu, Mar 06, 2025 at 12:56:08PM +, Chris Isaksen wrote:
>
Hi Chris
If you've got your global options set similarly to this
options {
dnssec-validation auto; // Global validation enabled
// ... other options ...
};
Have you been able to try something along the lines of this?
zone "no-dnssec.example" {
type forward;
forward
I was wondering if dnssec validation could be set to auto in the options
section and then set it to 'no' in a particular zone?
We would like to use "dnssec validation auto" but a few forwarding zones we
have, we know do not use dnssec and queries fail if it's not se
On Thu, Mar 06, 2025 at 12:56:08PM +, Chris Isaksen wrote:
> I was wondering if dnssec validation could be set to auto in the options
> section and then set it to 'no' in a particular zone?
>
> We would like to use "dnssec validation auto" but a few forwarding
05 AM
To: Chris Isaksen
Cc: bind-users@lists.isc.org
Subject: Re: Questions about "dnssec validation" statement
Hi Chris
If you've got your global options set similarly to this
options {
dnssec-validation auto; // Global validation enabled
// ... other options ...
};
Have
Yes, the ZSK rollover got weird when the DS had not reach omnipresent state
yet. Why is that?
-Original Message-
From: bind-users On Behalf Of Matthijs
Mekking
Sent: Friday, February 21, 2025 2:30 PM
To: bind-users@lists.isc.org
Subject: Re: Policy-dnssec timeline step by step
Hi
Hi,
The timings are based on RFC 7583 and "Flexible and Robust Key Rollover
in DNSSEC". They may help a great deal in understanding the time states.
https://datatracker.ietf.org/doc/html/rfc7583
https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf
See below for inli
Have you read:
https://kb.isc.org/docs/dnssec-key-and-signing-policy
and
https://bind9.readthedocs.io/en/latest/dnssec-guide.html
This RFC should give you some background too:
https://datatracker.ietf.org/doc/html/rfc6781
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and
Hi,
I'm trying out DNSSEC policy for the first time, and I am so confused about the
time states—how they calculate the time for the state of the records to change.
I really need help because I have a ton of questions (I'm using BIND 9.18.31,
btw). I want to understand how it works st
Hi Taavi,
It seems I was blind and didn't see the button.
Problem solved. Iterations set to 0 and salt to null. Everything green
now at DNSviz.
Best regards
Hans
--
On 07.02.25 17:05, Taavi Eomäe wrote:
Hi,
If you select the "Denial of existence" under options, then you will
see the exac
Hi,
If you select the "Denial of existence" under options, then you will see
the exact details behind those errors.
It seems like your NSEC3 iterations count is not 0, but it should be 0
to alleviate computational burdens. See RFC9276, Sec. 3.1.
Best regards
Taavi
smime.p7s
Description:
dnsviz:
ok7gd.aw5sp.iiasa.ac.at/A has errors; select the "Denial of existence"
DNSSEC option to see them.
Searching for solutions didn't really help.
Any idea how to solve this issue ? Or where to dig deeper to find a
solution ?
Kind regards
Hans
--
--
Visit https://lists.
happening
automatically because I used |dnssec-policy|. If it’s not happening, is
there something else that can help me automate this process by
withdrawing the key ?
On Fri, Nov 8, 2024 at 12:58 AM Crist Clark <mailto:cjc%2bbind-us...@pumpky.net>> wrote:
You need to tell BIND the
Hello
Thank you very much for the reply. I thought this was happening
automatically because I used dnssec-policy. If it’s not happening, is there
something else that can help me automate this process by withdrawing the
key ?
On Fri, Nov 8, 2024 at 12:58 AM Crist Clark
wrote:
> You need to t
You need to tell BIND the DS is gone from the parent. See the usage for,
rndc dnssec -checkds withdrawn
On Thu, Nov 7, 2024 at 12:04 PM Τάσος Λολότσης wrote:
> Hello all,
>
> I’m currently facing an issue with DNSSEC key management in BIND and
> would appreciate any insights or
Hello all,
I’m currently facing an issue with DNSSEC key management in BIND and would
appreciate any insights or experiences you might have.
I have configured a DNSSEC policy for my domain with the following settings:
keys {
csk key-directory lifetime P365D algorithm ecdsa256;
};
// Key
DNS...
>
> Thanks in advance for any thoughts you can provide.
>
> Robert Wagner
> From: bind-users on behalf of Robert
> Edmonds
> Sent: Friday, November 1, 2024 4:16 PM
> To: Robert Mankowski
> Cc: bind-users@lists.isc.org
> Subject: Re: DNSSEC, OpenDNS and w
for proper
configuration. Kind of a SSL checker for DNS...
Thanks in advance for any thoughts you can provide.
Robert Wagner
From: bind-users on behalf of Robert Edmonds
Sent: Friday, November 1, 2024 4:16 PM
To: Robert Mankowski
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC, OpenDNS and
From: bind-users on behalf of Robert Edmonds
Sent: Friday, November 1, 2024 4:16 PM
To: Robert Mankowski
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC, OpenDNS and www.cdc.gov
This email originated from outside of TESLA
Do not click links or open attachments unless you recognize
e have been reported
to DNS-OARC's dns-operations mailing list over the years (as well as
other forums). The most recent thread is archived here:
https://lists.dns-oarc.net/pipermail/dns-operations/2024-July/022642.html
Robert Mankowski wrote:
> I recently implemented a forward only BIND ser
+mtrace to see each individual message.
> -Evan
>
> Get BlueMail <https://bluemail.me> for Desktop
>
> Ondřej Surý wrote:
>
>
> DO flag is indication to “do DNSSEC”, it has no other meaning. You should
> be looking for AD flag.
>
> As for delv output - it prin
Sorry, I get the DO and AD flags confused. I see now that DIG is telling me
that somewhere in the chain there is an entry that is not validated. I was
doing everything manually. And yes, I saw that DELV runs the chain.
Thanks again,
Bob
--
Visit https://lists.isc.org/mailman/listinfo/bind-user
Even with a CNAME record, the delv command will validate each step of the
resolution. You can use the +vtrace option to see each validation and +mtrace
to see each individual message.
-Evan
Get BlueMail <https://bluemail.me> for Desktop
Ondřej Surý wrote:
DO flag is indication to “do DNSSE
DO flag is indication to “do DNSSEC”, it has no other meaning. You should be looking for AD flag.As for delv output - it prints out which names are validated and those that are not. I don’t see anything wrong here.--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different
main apex
CNAMEs...)
Here's the DIG and DELV output (recursive server is running bind 9.20.2 on
a raspberrypi under freeBSD 14.1-p6):
root@RaspberryPI-00:~ # dig www.irs.gov. +dnssec
; <<>> DiG 9.20.2 <<>> www.irs.gov. +dnssec
;; global options: +cmd
;; Got answer:
;
Hi there,
On Thu, 31 Oct 2024, Crist Clark wrote:
Name names. DNS is out there in public.
There are a LOT of US .gov sites where the .gov is all signed, but it ends
up in $BIGCLOUDPROVIDER that is not.
www.gsa.gov
www.state.gov
www.house.gov
www.senate.gov
www.cia.gov
www.cisa.gov (*ehem*)
ww
a lot of .mil.
On Thu, Oct 31, 2024 at 3:34 PM Mark Andrews wrote:
>
>
> > On 1 Nov 2024, at 09:15, Bob McDonald wrote:
> >
> > If a host is defined as a CNAME chain where the domain of the host is
> DNSSEC signed but the domain(S) of the target(s) in the CNAME chai
> On 1 Nov 2024, at 09:15, Bob McDonald wrote:
>
> If a host is defined as a CNAME chain where the domain of the host is DNSSEC
> signed but the domain(S) of the target(s) in the CNAME chain are not, does
> that mean that the entry really isn't DNSSEC protected?
Correc
If a host is defined as a CNAME chain where the domain of the host is
DNSSEC signed but the domain(S) of the target(s) in the CNAME chain are
not, does that mean that the entry really isn't DNSSEC protected?
I can list an example dig for the host in question but I'm reluctant to do
so
second issue is that I have multiple zones that all point
to the
same file since those domains all go to the same set of
servers. Right
now, I am using the same zone file for all of them. This works
fine
currently, but when I try to enable DNSSEC for those domains, I
get an
same file since those domains all go to the same set of servers.
Right
now, I am using the same zone file for all of them. This works fine
currently, but when I try to enable DNSSEC for those domains, I
get an
error "writable file ... already in use". The simple answer
Bowie Bailey via bind-users wrote:
> The first issue is that my server uses a few views to give different IPs
> based on which network the request comes from. I found that if I point
the
> zones in the different views to the same key directory, there are no
errors
> and all vie
obligated to reply outside your normal working hours.
> On 18. 10. 2024, at 19:50, Bowie Bailey via bind-users
> wrote:
>
> I would like to have DNSSEC active on both domains, but since they are
> sharing a file, Bind complains about it.
--
Visit https://lists.isc.org/mailman/listinf
On 19/10/2024 05:50, Bowie Bailey via bind-users wrote:
On 10/18/2024 12:07 PM, Bob Harold wrote:
On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users
wrote:
I am finally getting around to setting up DNSSEC on my server (Bind
9.16). I found some instructions online and was
isc.org>> wrote:
>> I am finally getting around to setting up DNSSEC on my server (Bind
>> 9.16). I found some instructions online and was able to set up one of
>> my zones and confirm that the keys are being returned. However, after
>> doing a bit more testing I r
ie Bailey via bind-users
>> mailto:bind-users@lists.isc.org>> wrote:
>>> I am finally getting around to setting up DNSSEC on my server (Bind
>>> 9.16). I found some instructions online and was able to set up one of
>>> my zones and confirm that the keys are being retur
On 10/18/2024 12:07 PM, Bob Harold wrote:
On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users
wrote:
I am finally getting around to setting up DNSSEC on my server (Bind
9.16). I found some instructions online and was able to set up
one of
my zones and confirm that
On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users <
bind-users@lists.isc.org> wrote:
> I am finally getting around to setting up DNSSEC on my server (Bind
> 9.16). I found some instructions online and was able to set up one of
> my zones and confirm that the keys are
I am finally getting around to setting up DNSSEC on my server (Bind
9.16). I found some instructions online and was able to set up one of
my zones and confirm that the keys are being returned. However, after
doing a bit more testing I ran into a couple of issues.
I am using the recommended
Thanks Greg. That is very helpful. Sorry I didn't find that article on my own.
Bob
From: Greg Choules
Sent: Wednesday, October 16, 2024 10:10 AM
To: Robert Mankowski
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC, OpenDNS and www.cdc.gov
Hi Bob.
See if this article helps any first, b
> to OpenDNS FamilyShield using TLS and DNSSEC at first, but I was getting a
> noticeable amount of SERVFAIL responses. I believe it is related to DNSSEC
> (see delv tests below), but I don’t believe it is my configuration because
> when I forward to Cloudflare’s Family service, or to
I recently implemented a forward only BIND server for home. I was forwarding to
OpenDNS FamilyShield using TLS and DNSSEC at first, but I was getting a
noticeable amount of SERVFAIL responses. I believe it is related to DNSSEC (see
delv tests below), but I don't believe it is my configur
dy yet, then please
keep these standards in mind for future direction when available.
RW
From: bind-users on behalf of Matthijs
Mekking
Sent: Wednesday, October 16, 2024 4:03 AM
To: bind-users@lists.isc.org
Subject: Re: DNSSEC algo rollover fails to delete ol
If you provide the output of `rndc dnssec -status` it might give a hint
why the keys are still published.
I suspect that BIND needs to be told that the DS has been withdrawn for
the parent zone (assuming you don't have parental-agents set up).
For future algorithm rollovers: You can
Restore the keys from backups and let named MANAGE the removal of the
old keys. People really need to stop being impatient with DNSSEC key
management. It is a SLOW process as there are interactions with the
parent zone that need to be co-ordinated and WAIT TIMES that need to
be observed. Named
Hello everyone,
I made a algo rollover in DNSSEC from algo 8 to algo 13.
Software version : 9.18.28-1~deb12u2-Debian
My zone configuration refers to policies :
==
dnssec-policy "algo8" {
keys {
ks
On 01. 10. 24 8:15, Terik Erik Ashfolk wrote:
Please scratch the below line previous post.
Upon detail look, they have Multi-Master support, but not with DNSSEC
support.
If you really wanted multi-master with DNSSEC you can have a look at
FreeIPA.org, their DNS integration has that.
It
> > I always had the impression that dnssec-signzone is a stand-alone
> > utility and signing is done either with dnssec-signzone or with
> > Bind's dnssec-policy. Does it really work to use dnssec-signzone on a
> > zone and journal that is managed by named?
>
>
Hi Matthijs!
I always had the impression that dnssec-signzone is a stand-alone utility and
signing is done either with dnssec-signzone or with Bind's dnssec-policy. Does
it really work to use dnssec-signzone on a zone and journal that is managed by
named?
Regards
Klaus
--
Klaus Dar
On 01. 10. 24 14:45, Klaus Darilion via bind-users wrote:
I always had the impression that dnssec-signzone is a stand-alone
utility and signing is done either with dnssec-signzone or with
Bind's dnssec-policy. Does it really work to use dnssec-signzone on a
zone and journal that is manag
only in testing.
So I am fine with the workaround of doing manual signing with dnssec-signzone.
Regards
Klaus
PS: All of nic.at/RcodeZero is using RFC 9276.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this
On 10/1/24 09:44, Klaus Darilion wrote:
Hi Matthijs!
I always had the impression that dnssec-signzone is a stand-alone
utility and signing is done either with dnssec-signzone or with
Bind's dnssec-policy. Does it really work to use dnssec-signzone on a
zone and journal that is manag
On 01. 10. 24 15:41, Klaus Darilion wrote:
Hi Petr!
It can be said that the interface pushes people to follow RFC 9276, i.e.
no salt and no extra iterations.
It is an pointless exercise which only makes servers easier to DoS for
no benefit.
I understand your decision to push people towards R
Hi Klaus,
With dnssec-policy you can specify the salt length, not a specific salt.
You can still use dnssec-signzone -3 to manually set a salt.
Best regards,
Matthijs
On 9/30/24 22:38, Klaus Darilion via bind-users wrote:
Hello!
With "auto-dnssec maintain;" I was used to specify
Please scratch the below line previous post.
Upon detail look, they have Multi-Master support, but not with
DNSSEC support.
On 9/30/24 4:00 PM, Terik Erik Ashfolk wrote:
I think i've seen another project Seen few other project also doing
similar
--
Visit https://lists.isc.org/ma
Hi Mark. THANK YOU.
sorry for delayed response.
I understood some of your response better after Matthijs also
mentioned your mail-post.
I need to look into DNSSEC activity flow again, i'm sure there are
changes since my last works on these, 5 years back.
Main domain is "e
r
I regret, i did not follow all the links in your ref in your ISC
pdf, which appeared in ggl search result earlier, & i assumed
by-now BIND has builtin Multi-Signer MODEL-2 aka
Multi-Master/Primary DNSSEC mode support.
If the "MUSIC" was in C / C++ / perl, etc that would hav
service-from their own-home/homeoffice/mobile devices (so routing,
fast-updating, etc are involved), and/or link their own server from
server-providers.
Those were main reasons to have (very) low TTL, for faster update,
And i used that (faster-update) opportunity to also update/change
DNSSEC
Hello!
With "auto-dnssec maintain;" I was used to specify the NSEC3 salt with 'rndc
signing -nsec3param'. Today I used the "dnssec-policy" and I failed to specify
the salt manually. Are there any tricks/workarounds to manually specify the
NSEC3 salt?
I know th
On Sat, Sep 28, 2024 at 11:13 AM Terik Erik Ashfolk
wrote:
>
> But 1024 or 2048 bit RSA key-pairs are considered weak.
>
Those are considered weak for _encryption_ because of the risk of future
decryption of secrets. The window for someone to brute force your keys and
fake signatures with a lim
Hi Erik,
There is no configuration option for enabling multi-signer in BIND.
BIND 9.20 is able to deal with multi-signer setups, but as Mark
mentioned earlier, all the coordination needs to be done outside the
name server.
You may consider MUSIC for this:
https://github.com/DNSSEC
dden/offline).
My project require DNSSEC validated connections+links for user's
homepage and devices, etc.
Some components are open-source, & some are partially closed &
available over API.
I could not continuously work on this project.
( i can DM you more specifics , but no
> On 28. 9. 2024, at 1:31, Terik Erik Ashfolk wrote:
>
> and during consideration i was using a dnssec-policy opPolicy2W with KSK
> changing every 20 days, & ZSK every 10 days.
>
> Now I changed to another dnssec-policy opPolicy3M : KSK changing every ~ 3
> months &
1/08/25/multi-signer-dnssec-models/
in MODEL 2.
I added an improved image as attachment.
MULTI-ZSK-SIGNING IS ONE OF THE SOLUTION, and appears to be
suitable for my case.
So, multi-signing with ZSKs from multiple nameservers would have
worked,
when nameservers were using separate "zones"
Hi Ondrej. THANK YOU.
I understand what you have suggested.
I considered that earlier : it would've increased 1 more server
rent cost, and additional setup, maintenance/update, etc times, ...
and during consideration i was using a dnssec-policy opPolicy2W
with KSK changing every 20 days,
records.
All this needs to go through the IETF.
--
Mark Andrews
> On 28 Sep 2024, at 07:54, Terik Erik Ashfolk wrote:
>
> According to the page
> https://blog.apnic.net/2021/08/25/multi-signer-dnssec-models/
> in MODEL 2.
> I added an improved image as attachment.
>
> MUL
According to the page
https://blog.apnic.net/2021/08/25/multi-signer-dnssec-models/
in MODEL 2.
I added an improved image as attachment.
MULTI-ZSK-SIGNING IS ONE OF THE SOLUTION, and appears to be
suitable for my case.
So, multi-signing with ZSKs from multiple nameservers would have
worked
Hi Erik,
whatever you did below is complicated, unnecessary, and prone to break.
Just create one hidden primary that will do the signing and two to three public
secondaries that are independent of each other.
Then setup DNSSEC in a way that it’s ok for the primary to be down for a
specified
Hello BIND Community.
Looking forward to your suggestions, advises on setup DNSSEC enabled zones on
multiple master/primary authoritative DNS server (Nameserver) with
synced/replicated common shared directories/volume.
Please skip the section(s) that you dont need to read/scan,
& goto
r Špaček wrote:
>
> Hello,
>
> and thank you for reaching out. I agree this was poorly documented.
>
> In recent versions you can use command `named -C` which prints out
> default configuration, including the default DNSSEC policy.
>
> I'm going to update document
Hello,
and thank you for reaching out. I agree this was poorly documented.
In recent versions you can use command `named -C` which prints out
default configuration, including the default DNSSEC policy.
I'm going to update documentation to reflect that:
https://gitlab.isc.org/isc-pro
macro system.)
>
> First, the official definitions are at IANA:
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
>
> Second, in working with BIND and DNSSEC over the years, it is
Ah, thanks!
Yeah, that's what I was looking to find:
https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
Alas, not in the ISC distribution tarballs,
and the document
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
Second, in working with BIND and DNSSEC over the years, it is not my
impression that BIND restricts the algorithm number in any way.
I don't think it even knows w
Link for the Debian packaged version you mentioned is at
https://bind9.readthedocs.io/en/v9.18.24/reference.html#namedconf-statement-dnssec-policy
On Thu, Jun 6, 2024 at 9:31 AM Andrew Latham wrote:
> I took a quick look
>
> *
> https://github.com/isc-projects/bind9/blob/main/doc
I took a quick look
*
https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
*
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users <
bind-users@lists.isc.org>
dnssec-policy default - where/how to determine what all its settings are?
Documentation
doc/bind9-doc/arm/reference.html#dnssec-policy-default
https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default
says:
A verbose copy of this policy may be found in the source tree, in the
SState: hidden"
If not in my registar (dig ds +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key
published )
Notify Bind(bind rndc dnssec -checkds -key
withdraw )
In my understanding, i sho
w the old DS?
Yes, the old DS should be not yet withdraw because some RRSIG could be
still valid ? or can i withdraw the old DS / KSK immediatly ?
In my logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my regi
sers@lists.isc.org
> <mailto:bind-users@lists.isc.org> <mailto:bind-users@lists.isc.org>>
> Subject: Re: Make dig and nslookup DNSSEC aware?
>
> This email originated from outside of TESLA
>
> Do not click links or open attachments unless you recognize the sender
-users@lists.isc.org
Subject: Re: Make dig and nslookup DNSSEC aware?
This email originated from outside of TESLA
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
> Doesn't dig already offer DoT using +tls and DoH using +https?
You
> Doesn't dig already offer DoT using +tls and DoH using +https?
You're right, it does.
I need to sort out my $PATH...
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 sub
Doesn't dig already offer DoT using +tls and DoH using +https ?
Don Friesen
-Original Message-
From: bind-users On Behalf Of Ondrej Surý
Sent: Wednesday, May 22, 2024 8:09 AM
To: Havard Eidnes
Cc: bind-users@lists.isc.org
Subject: Re: Make dig and nslookup DNSSEC aware?
[EXT
forget about nslookup. deprecated in my mind. use dig like so:
for DoT:
$dig @1.1.1.1 -tA +dnssec +tls www.google.com
for Doh:
dig @1.1.1.1 -ta +https +dnssec www.google.com
Make sure you have a more recent version of dig to supports this.
If you need programmatic DNSSEC access use a library
> On 22. 5. 2024, at 17:02, Havard Eidnes via bind-users
> wrote:
>
> And, no, I'm not aware of any such plans to incorporate a DNSSEC
> validator in any of those tools. Not sure it makes technical
> sense, as it's a fairly large task. That's what a validating
>> Sorry if this has already been hashed through, but I cannot
>> find anything in the archive. Is there any chance someone can
>> make dig and nslookup DNSSEC aware and force it to use DoT or
>> DoH ports - TCP 443 or 853 only?
>
> Not sure about that. However, the
> Sorry if this has already been hashed through, but I cannot
> find anything in the archive. Is there any chance someone can
> make dig and nslookup DNSSEC aware and force it to use DoT or
> DoH ports - TCP 443 or 853 only?
Not sure about that. However, the "kdig" utilit
1 - 100 of 1083 matches
Mail list logo
