>> So ... I can't get the glibc behaviour to mesh with the standard
>> on this particular point.
>
> It's set in RFC 6840:
I stand corrected, thanks.
- Håvard
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this l
Hi there,
I really don't know If this is the correct place to ask about Bind DLZ, but I'm
afraid that I could not have any responses from the BIND DLZ mail list and,
since this seems to be an "official" plugin and it's compiled on the bind9
package from the SuSE15 SP2 repository I will try to a
Most people like yourself that do not care about OS purity often are not
obligated (granted super broad generalization) to explain their changes to an
Enterprise Change Management Board (ECMB or similar) for deviations from a
"standard image".
That is also 100% okay too. Those types of shops/s
On 11 Feb 2021, at 16:38, John W. Blue via bind-users
wrote:
> I have found to tshark to be useful as well but the failing it has is that it
> is generally not included in a unix OS distribution.
Is bind? I mean, I have to install a bunch of stuff right off on a new bistro
just to get a useabl
I have found to tshark to be useful as well but the failing it has is that it
is generally not included in a unix OS distribution.
Assuming anything referred to as "being in production" should also be following
good change management protocols it makes sense to be fluent with tools that
are rea
On Thu 11/Feb/2021 17:44:20 +0100 Havard Eidnes wrote:
Yeah, by the time it lands on Debian's glibc we'll have grown a long
long beard. I'm still missing RES_TRUSTAD...
Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD
before, so I found
https://man7.org/linux/man-pages/man5
The internet isn’t always on and it isn’t only composed of big tech
companies with lots of resources.
like Google's gmail, which has had hours-long service outages from time to
time? ;-)___
Please visit https://lists.isc.org/mailman/listinfo/bind-use
> Yeah, by the time it lands on Debian's glibc we'll have grown a long
> long beard. I'm still missing RES_TRUSTAD...
Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD
before, so I found
https://man7.org/linux/man-pages/man5/resolv.conf.5.html
which under "trust-ad" contains th
On Thu 11/Feb/2021 14:47:13 +0100 Ondřej Surý wrote:
Mark is right. The internet isn’t always on and it isn’t only composed of big
tech companies with lots of resources.
The internet consists of lot small systems made by people like you and me and
we don’t have infinite resources to keep every
Mark is right. The internet isn’t always on and it isn’t only composed of big
tech companies with lots of resources.
The internet consists of lot small systems made by people like you and me and
we don’t have infinite resources to keep everything always on.
And honestly I find your quote about
Machines still fall over. They take the same amount of time to fix now as they
did 30 years ago.
You still have to diagnose the fault. You still have to get the replacement
part. You still have to potentially restore from backups. Sometimes you can
switch to a standby machine which makes things
On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote:
Out of curiosity, what servers have you encountered that no longer use the five
day cutoff ?
I didn't take note, but I read discussions on the topic. Users expect mail to be
delivered almost instantly. The "warning, still trying" messages sho
On Thu 11/Feb/2021 10:44:58 +0100 Havard Eidnes wrote:
Still, being able to differentiate a local network congestion from a
remote bad configuration would help.
That's true. There's
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16
which look promising, trying to make it poss
> Still, being able to differentiate a local network congestion from a
> remote bad configuration would help.
That's true. There's
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16
which look promising, trying to make it possible to distinguish
between the various reasons a recur
Thanks! That was the response I was looking for. Much appreciated!
--
Ondřej Surý (He/Him)
ond...@isc.org
> On 11. 2. 2021, at 9:03, stuart@registry.godaddy wrote:
>
> Good to know.
>
> Will attach a task to the next our next KSK roll process. Should halve the
> number of SHA1 DS's in the root
Good to know.
Will attach a task to the next our next KSK roll process. Should halve the
number of SHA1 DS's in the root.
Will also tweak some of our other DNSSEC process documentation to stop
providing them.
Stuart
On 11/2/21, 6:49 pm, "bind-users on behalf of Ondřej Surý"
wrote:
Not
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))
17 matches
Mail list logo
