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’m one
> 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
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 o
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 li
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 transfe
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 b
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 domain. (OT
sers on behalf of John W. 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.goda
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))
ý"
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
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 pertinen
> 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
> seeing
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) can
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 releases
14 matches
Mail list logo
