On 24.02.25 11:51 AM, Bernd Naumann wrote:
>
> Mhm. But *how* is *everyone else* using DNSSEC then?
>
https://www.ripe.net/manage-ips-and-asns/dns/dnssec/dnssec-policy-and-practice-statement/#DNSSECPolicyandPracticeStatement-KeySigningKeyRoll-over
Does someone know any other good DNSSEC Practic
Hi,
I started to get these messages, when some secondary tries to fetch
a zonefile from a primary. So I looked into it -
The primary is running:
# ps ax | grep named
13667 - IsJ 0:00.39 /usr/local/sbin/named -n 1 -u bind -c
/usr/local/etc/namedb/named.conf
It has ports configured:
On 24-Feb-25 17:54, Peter 'PMc' Much wrote:
tcpdump was friendly enough to tell me I should use -vv option,
only I didn't read that at first.
Then it clearly shows that these packets have invalid checksums. :(
And that is apparently reason enough to just drop them without
notice.
Now how they a
On Tue, Feb 18, 2025 at 08:40:53AM +0100, Rainer Duffner wrote:
> > ECS is not supported in the open source version of BIND so I guess
> > it might not get logged.
The open source version doesn't *send* client-subnet requests,
or cache the responses differently depending on client-subnet data
incl
Another thing to consider, especially if you are playing wild games routing
through tunnels and such, is to verify the server has a route back to the
client. If something in the LAN can reach it, like the first dump, but
off-net gets no response, like the second, that’s a classic cause.
On Mon, Fe
On Mon, Feb 24, 2025 at 10:01:49PM +0100, Peter 'PMc' Much wrote:
! Packets do arrive, but are ignored.
! The local firewall is switched to pass-thru.
!
! I don't know what else could selectively swallow packets without
! notice.
Okay, I figured it out.
tcpdump was friendly enough to tell me I
Hi Bernd,
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
In 9.18, I would suggest to disable inline-signing and just add the
DNSKEY record to the zone. Don't put the key files for the stand-by key
in the 'key-directory', this should o
Hi Matthijs, thanks for your response.
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
> Hi Bernd,
>
> Non-signing keys (for example a stand-by key), is a bit tricky in
> dnssec-policy and not fully supported.
>
Yeah I figured that in the mean time :/
But what I don't understand; RFC 7583 explic
Hi Bernd,
On 24-02-2025 10:12, Bernd Naumann wrote:
Hi Matthijs, thanks for your response.
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
Hi Bernd,
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
Yeah I figured that in the mean time :
On 24.02.25 11:22 AM, Matthijs Mekking wrote:
>> But what I don't understand; RFC 7583 explicit mentioned pre-publish of
>> DSDATA of ZSK, but not for KSK (IIUC)?
>
> And I am confused about the phrase "DSDATA of ZSK".
Sorry I'm not fully confident yet about the wording here and there...
I thing
Hello,
apparently one shouldn't use CNAMEs for 'delegating' _domainkey records
to another DNS server, but I see that some email service vendors use
that - they have their customers add a CNAME pointing to their TXT
record (one recent example that I was dealing with is atlassian.net
(https://
My 2p is...
You *shouldn't* do a lot of things, but people do anyway, because they can.
If you maintain your own DKIM records then deliberately adding a CNAME
upfront seems unnecessarily complicated. KISS.
If someone else hosts them and CNAME is a pragmatic way to achieve that
"ask them" behaviou
12 matches
Mail list logo
