On 3/11/21 9:21 AM, Matthijs Mekking wrote:
which apparently has a DS at the apex of the child zone, which is
somewhere between 'useless' and 'wrong'.
It is more wrong than useless: From RFC 4035:
All DS RRsets in a zone MUST be signed, and DS
RRsets MUST NOT appear at a zone's apex.
On 10-03-2021 20:29, Peter van Dijk wrote:
On Wed, 2021-03-10 at 16:44 +, Matthew Richardson wrote:
9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
Which is the NSEC3 hash of 'prv.se.',
Type:
Done via the web page.
> On 11 Mar 2021, at 09:42, Mark Andrews wrote:
>
> And has anyone reported this to them?
>
>> On 11 Mar 2021, at 09:37, Mark Andrews wrote:
>>
>> So who is correctly rejecting DS at top of zone at load time? There is no
>> way
>> to query for this RRset.
>>
>>> On
> On 11 Mar 2021, at 10:03, Evan Hunt wrote:
>
> On 11 Mar 2021, at 06:29, Peter van Dijk wrote:
>> My vague suspicion is that BIND is flagging this as an impossible
>> situation, because a DS should live in the parent, and only in the
>> parent.
>
> Your vague suspicion is correct - the
On 11 Mar 2021, at 06:29, Peter van Dijk wrote:
> My vague suspicion is that BIND is flagging this as an impossible
> situation, because a DS should live in the parent, and only in the
> parent.
Your vague suspicion is correct - the presence of the DS bit in the NSEC3
for the apex node is
And has anyone reported this to them?
> On 11 Mar 2021, at 09:37, Mark Andrews wrote:
>
> So who is correctly rejecting DS at top of zone at load time? There is no way
> to query for this RRset.
>
>> On 11 Mar 2021, at 06:29, Peter van Dijk wrote:
>>
>> On Wed, 2021-03-10 at 16:44 +,
So who is correctly rejecting DS at top of zone at load time? There is no way
to query for this RRset.
> On 11 Mar 2021, at 06:29, Peter van Dijk wrote:
>
> On Wed, 2021-03-10 at 16:44 +, Matthew Richardson wrote:
>> 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
>>>
On Wed, 2021-03-10 at 16:44 +, Matthew Richardson wrote:
>9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
> >Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
Which is the NSEC3 hash of 'prv.se.',
> >Type: NSEC3 (50)
> >Class: IN (0x0001)
Testing on two separate (but similarly configured) Bind 9.11.22 servers, I
also get SERVFAIL. The logs show entries like:-
>10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT: bad cache
>hit (_dmarc.prv.se/DS)
On a test machine running 9.11.8, and having cleared the cache
Some resolvers cannot resolve the DMARC record _dmarc.prv.se/TXT. They
reply SERVFAIL (the correct answer is NXDOMAIN). Running with checking
disabled solves the problem.
I see nothing that explains this problem. Zonemaster and DNSviz do not
see it either.
RIPE Atlas probes show that some
10 matches
Mail list logo
