The crypto policy stuff ultimately creates and maintains files in
/etc/crypto-policy/backends, which has a list of acceptable or not-acceptable
crypto settings.
Whilst a "bind.config" is created, you aren't including it in your config (this
is fine), which suggests that the issue is with some
> Subject: Re: How do I debug if the queries are not getting resolved?
>
> Oh I forgot to tell you that. This is BIND RPZ and all the queries are
> recursive.
>
> Dig output just dies out and does not spit anything.
>
> And this specifically i noticed with .gov and .gov.in domain. This is the
instances) shows no issue retrieving an A record for eportal.incometax.gov.in.,
from many places around the world (nlnog ring nodes).
So, weird.
Stuart Browne
GoDaddy Registry | Eng - System IV
[signature_3682002026]
stuart@registry.godaddy<mailto:stuart@registry.godaddy>
i.e. I
As the package maintained by the Ubuntu team are “no longer” the source from
ISC (but highly modified patches onto an old 9.16.1 source tree), I’d suggest
following up with the Ubuntu maintainers of the package, as it’s likely their
back-porting of security patches from much more recent
Look in to "match-destination" in a view, i.e.
acl abcd.anycast {
10.10.10.1;
};
view "abcd" {
match-clients {
any;
};
match-destinations {
abcd.anycast;
};
...
};
The response-policy definition (and associated zone)
> From: bind-users on behalf of rams
>
> Date: Friday, 9 April 2021 at 2:56 pm
> To: bind-users
> Subject: Unable to start name
> Hi
> We are using bind 9.11.28.1 on centos7.8. We have large number of zones
> on disk. When we stop/start , we are not getting successful message and
>
On 31/3/21, 8:00 am, "bind-users on behalf of John Thurston"
wrote:
On 3/30/2021 12:30 PM, Cuttler, Brian R (HEALTH) via bind-users wrote:
> We are seeing a delay in the primary DNS server updating the secondary
and would like to shorten that interval.
Can you post the
t;
wrote:
Notice: This email is from an external sender.
> On 11. 2. 2021, at 7:01, Stuart@registry.godaddy wrote:
>
> It's one of those old compatibility things.
Also called *downgrade attack vector*.
Stuart, there’s absolutely no reason to keep any SHA1 in the DN
I was going to throw out a “Of course not”, but after having a bit of a
stressful last few hours, I decided to walk the zone manually as something
“brainless” to relax..
And found there are some..
firmdale (RSASHS256 DNSKEY algorithm (8))
gdn (RSASHS256 DNSKEY algorithm (8))
Blue via bind-users"
wrote:
Notice: This email is from an external sender.
So out of curiosity why does the us tld have a SHA1 DS in root? Should be
an easy thing to tidy up, eh?
John
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@regist
30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single d
If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ however,
is delegated to the state officials of the Commonwealth of Massachusetts and is
indeed RSASHA1NSEC3.
Stuart
... one of the guy’s that does the DNSSEC for US TLD.
From: bind-users on behalf of "John W. Blue
via
I usually just GREP them out.
dig -k axfr zone @remotehost | grep -v 'ANY[[:space:]]TSIG[[:space:]]'
Stuart
On 7/12/20, 1:32 am, "bind-users on behalf of Anand Buddhdev"
wrote:
Notice: This email is from an external sender.
Hi folks,
When I use "dig" to do a zone
Manual steps?
* Generate keys (dnssec-keygen)
* Set appropriate Publish and Activation times with the arguments
* Set appropriate de-activation and removal times on existing keys
(dnssec-settime)
BIND should do the rest. You can use rndc loadkeys to hurry up the
automation a
14 matches
Mail list logo
