On Mon, May 9, 2022 at 7:27 PM Fred Morris wrote:
> On Mon, 9 May 2022, Alex K wrote:
> > [...]
> > The problem now is that I see sometime 700MB of DNS traffic for 2GB of
> > Internet browsing within one month.
>
> That's an eyebrow raiser. Tunneling, antivirus (or some other database
> using DNS
Hi Tony
Many thanks for your explanation!
Tom
On 10.05.22 10:46, Tony Finch wrote:
Tom wrote:
I'm wondering about the value of the "Length"-field in the dnssec-policy
state-file output, which results in "Length: 256" for domains, which are
signed with algorithm 13 (ECDSAP256SHA256)
That's
Hi list
After switching from "semi-automatic"-signing to dnssec-policy
(everything identical, except new ZSK rollover) I have the following
rndc output:
$ rndc dnssec -status example.ch
dnssec-policy: 60d_zsk_rollover
current time: Wed May 11 09:54:55 2022
key: 45819 (ECDSAP256SHA256), KSK
Signature-refresh determines when the RRSIGs will be replaced by looking at the
expiration time and working backwards. New RRSIGs are generate Using
signature-interval.
--
Mark Andrews
> On 11 May 2022, at 18:15, Tom wrote:
>
> Hi list
>
> After switching from "semi-automatic"-signing to
Hello,
we observed a strange behaviour for the domain foryoudecor.com,
when trying to resolve it using bind 9.18.2, using
dig -t mx foryoudecor.com
The bind log for 9.18.2 says:
May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
May 11 12:00:14 ns named[96774]: DNS format error from 61.
> we observed a strange behaviour for the domain foryoudecor.com,
> when trying to resolve it using bind 9.18.2, using
>
> dig -t mx foryoudecor.com
>
> The bind log for 9.18.2 says:
>
> May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
> May 11 12:00:14 ns named[96774]: DNS format erro
On 11.05.22 11:26, Mark Andrews wrote:
Signature-refresh determines when the RRSIGs will be replaced by looking at the
expiration time and working backwards. New RRSIGs are generate Using
signature-interval.
Ah, perfect. Thx.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to un
It's always an architectural choice to use anycast with your authoritative
zones. I'm speaking from purely a private network (inside) viewpoint. I
typically only use anycast for recursive DNS servers on my
private (internal) network.
That said, here are some thoughts. (This is my understanding onl
On 5/11/22 11:24 AM, Bob McDonald wrote:
It would seem that using an anycast cloud name (An anycast cloud
of the NS device IPs) for the MNAME might provide the same level of
distribution as per Windows. However, again, you run into the issues
of forwarded updates.
Another thing that I've see
On Wed, May 11, 2022 at 1:50 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 5/11/22 11:24 AM, Bob McDonald wrote:
> > It would seem that using an anycast cloud name (An anycast cloud
> > of the NS device IPs) for the MNAME might provide the same level of
> > distribution as
On 5/11/22 2:19 PM, Bob Harold wrote:
Not sure who set it up, but my DHCP servers have for some zones:
zone x.y.z.in-addr.arpa
{
primary 10.2.3.4;
}
I'm assuming that is BIND's named.conf syntax.
Which I believe overrides the MNAME lookup.
Doesn't that just tell BIND where to initiate
Dear Jason,
Thank you for your support.
Could you tell me the progress on my question below?
Can I understand following options do not work in BIND9.16.27?
・resolver-nonbackoff-tries
・resolver-retry-interval
Best Regards,
Shinichiro Shimada
From: 嶋田信一郎 / SHIMADA，SHINICHIRO
Sent: Friday, May 6,
12 matches
Mail list logo
