Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Mark Andrews]

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 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
> Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>>> 
>>> Which is the NSEC3 hash of 'prv.se.',
>>> 
> Type: NSEC3 (50)
> Class: IN (0x0001)
> Time to live: 3600
> Data length: 43
> Hash algorithm: SHA-1 (1)
> NSEC3 flags: 0
>  ...0 = NSEC3 Opt-out flag: Additional insecure 
> delegations forbidden
> NSEC3 iterations: 50
> Salt length: 8
> Salt value: 33e9285ab62c0803
> Hash length: 20
> Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
> RR type in bit map: A (Host Address)
> RR type in bit map: NS (authoritative Name Server)
> RR type in bit map: SOA (Start Of a zone of Authority)
> RR type in bit map: MX (Mail eXchange)
> RR type in bit map: TXT (Text strings)
> RR type in bit map: DS(Delegation Signer)
>>> 
>>> which apparently has a DS at the apex of the child zone, which is
>>> somewhere between 'useless' and 'wrong'.
>>> 
> RR type in bit map: RRSIG
> RR type in bit map: DNSKEY
> RR type in bit map: NSEC3PARAM
>>> 
>>> Combined with
>>> 
 10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT:
>>> bad cache hit (_dmarc.prv.se/DS)
>>> 
>>> 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.
>>> 
>>> I recall isc.org 'recently' had a DS at the apex of the child zone; I
>>> wonder if after ISC removed that, they made BIND, as a validator,
>>> stricter about it when detected.
>>> 
>>> Kind regards,
>>> -- 
>>> Peter van Dijk
>>> PowerDNS.COM BV - https://www.powerdns.com/
>>> 
>>> ___
>>> dns-operations mailing list
>>> dns-operations@lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Mark Andrews]

> 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 presence of the DS bit in the NSEC3
> for the apex node is causing named to decide it's not valid as a closest-
> encloser proof.
> 
> RFC 5155 says:
> | Once the closest encloser has been discovered, the validator MUST
> | check that the NSEC3 RR that has the closest encloser as the original
> | owner name is from the proper zone.  The DNAME type bit must not be
> | set and the NS type bit may only be set if the SOA type bit is set.
> | If this is not the case, it would be an indication that an attacker
> | is using them to falsely deny the existence of RRs for which the
> | server is not authoritative.
> 
> We seem to have added a check for the DS bit here as well, and Mark and I
> are currently bickering in a side channel over whether that was a mistake
> that should be fixed or not. Maybe we should be asking other validators
> to flag this as an error, rather than making it work in BIND.
> 
> What's definitely true is that the DS at the zone apex is wrong. The
> zone shouldn't have loaded that way.
> 
>> I recall isc.org 'recently' had a DS at the apex of the child zone; I
>> wonder if after ISC removed that, they made BIND, as a validator,
>> stricter about it when detected.
> 
> Hm, I don't recall that, but it may be so. But, the BIND validator has
> had this restriction since NSEC3 support was first added in 2008.

5431.   [func]  Reject DS records at the zone apex when loading
master files. Log but otherwise ignore attempts to
add DS records at the zone apex via UPDATE. [GL #1798]

> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Evan Hunt]

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 causing named to decide it's not valid as a closest-
encloser proof.

RFC 5155 says:
| Once the closest encloser has been discovered, the validator MUST
| check that the NSEC3 RR that has the closest encloser as the original
| owner name is from the proper zone.  The DNAME type bit must not be
| set and the NS type bit may only be set if the SOA type bit is set.
| If this is not the case, it would be an indication that an attacker
| is using them to falsely deny the existence of RRs for which the
| server is not authoritative.

We seem to have added a check for the DS bit here as well, and Mark and I
are currently bickering in a side channel over whether that was a mistake
that should be fixed or not. Maybe we should be asking other validators
to flag this as an error, rather than making it work in BIND.

What's definitely true is that the DS at the zone apex is wrong. The
zone shouldn't have loaded that way.

> I recall isc.org 'recently' had a DS at the apex of the child zone; I
> wonder if after ISC removed that, they made BIND, as a validator,
> stricter about it when detected.

Hm, I don't recall that, but it may be so. But, the BIND validator has
had this restriction since NSEC3 support was first added in 2008.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Mark Andrews]

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 +, 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)
  Time to live: 3600
  Data length: 43
  Hash algorithm: SHA-1 (1)
  NSEC3 flags: 0
   ...0 = NSEC3 Opt-out flag: Additional insecure 
 delegations forbidden
  NSEC3 iterations: 50
  Salt length: 8
  Salt value: 33e9285ab62c0803
  Hash length: 20
  Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
  RR type in bit map: A (Host Address)
  RR type in bit map: NS (authoritative Name Server)
  RR type in bit map: SOA (Start Of a zone of Authority)
  RR type in bit map: MX (Mail eXchange)
  RR type in bit map: TXT (Text strings)
  RR type in bit map: DS(Delegation Signer)
>> 
>> which apparently has a DS at the apex of the child zone, which is
>> somewhere between 'useless' and 'wrong'.
>> 
  RR type in bit map: RRSIG
  RR type in bit map: DNSKEY
  RR type in bit map: NSEC3PARAM
>> 
>> Combined with
>> 
>>> 10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT:
>> bad cache hit (_dmarc.prv.se/DS)
>> 
>> 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.
>> 
>> I recall isc.org 'recently' had a DS at the apex of the child zone; I
>> wonder if after ISC removed that, they made BIND, as a validator,
>> stricter about it when detected.
>> 
>> Kind regards,
>> -- 
>> Peter van Dijk
>> PowerDNS.COM BV - https://www.powerdns.com/
>> 
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Mark Andrews]

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
>>>   Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
> 
> Which is the NSEC3 hash of 'prv.se.',
> 
>>>   Type: NSEC3 (50)
>>>   Class: IN (0x0001)
>>>   Time to live: 3600
>>>   Data length: 43
>>>   Hash algorithm: SHA-1 (1)
>>>   NSEC3 flags: 0
>>>    ...0 = NSEC3 Opt-out flag: Additional insecure 
>>> delegations forbidden
>>>   NSEC3 iterations: 50
>>>   Salt length: 8
>>>   Salt value: 33e9285ab62c0803
>>>   Hash length: 20
>>>   Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
>>>   RR type in bit map: A (Host Address)
>>>   RR type in bit map: NS (authoritative Name Server)
>>>   RR type in bit map: SOA (Start Of a zone of Authority)
>>>   RR type in bit map: MX (Mail eXchange)
>>>   RR type in bit map: TXT (Text strings)
>>>   RR type in bit map: DS(Delegation Signer)
> 
> which apparently has a DS at the apex of the child zone, which is
> somewhere between 'useless' and 'wrong'.
> 
>>>   RR type in bit map: RRSIG
>>>   RR type in bit map: DNSKEY
>>>   RR type in bit map: NSEC3PARAM
> 
> Combined with
> 
>> 10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT:
> bad cache hit (_dmarc.prv.se/DS)
> 
> 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.
> 
> I recall isc.org 'recently' had a DS at the apex of the child zone; I
> wonder if after ISC removed that, they made BIND, as a validator,
> stricter about it when detected.
> 
> Kind regards,
> -- 
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Peter van Dijk]

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)
> >Time to live: 3600
> >Data length: 43
> >Hash algorithm: SHA-1 (1)
> >NSEC3 flags: 0
> > ...0 = NSEC3 Opt-out flag: Additional insecure 
> > delegations forbidden
> >NSEC3 iterations: 50
> >Salt length: 8
> >Salt value: 33e9285ab62c0803
> >Hash length: 20
> >Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
> >RR type in bit map: A (Host Address)
> >RR type in bit map: NS (authoritative Name Server)
> >RR type in bit map: SOA (Start Of a zone of Authority)
> >RR type in bit map: MX (Mail eXchange)
> >RR type in bit map: TXT (Text strings)
> >RR type in bit map: DS(Delegation Signer)

which apparently has a DS at the apex of the child zone, which is
somewhere between 'useless' and 'wrong'.

> >RR type in bit map: RRSIG
> >RR type in bit map: DNSKEY
> >RR type in bit map: NSEC3PARAM

Combined with

> 10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT:
bad cache hit (_dmarc.prv.se/DS)

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.

I recall isc.org 'recently' had a DS at the apex of the child zone; I
wonder if after ISC removed that, they made BIND, as a validator,
stricter about it when detected.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Matthew Richardson]

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 beforehand,
SERVFAIL is returned with the same message logged.

Running tcpdump of the traffic from the Bind server, it gets the following
response back clearly showing NXDOMAIN with NSEC3 records:-

>Frame 106: 1081 bytes on wire (8648 bits), 1081 bytes captured (8648 bits)
>Ethernet II, Src: Xensourc_40:5c:c5 (00:16:3e:40:5c:c5), Dst: 
>Xensourc_ec:56:8d (00:16:3e:ec:56:8d)
>Internet Protocol Version 4, Src: 80.80.64.49, Dst: 193.201.42.59
>Transmission Control Protocol, Src Port: 53, Dst Port: 33761, Seq: 1, Ack: 57, 
>Len: 1027
>Domain Name System (response)
>Length: 1025
>Transaction ID: 0xf5c2
>Flags: 0x8483 Standard query response, No such name
>1...    = Response: Message is a response
>.000 0...   = Opcode: Standard query (0)
> .1..   = Authoritative: Server is an authority for domain
> ..0.   = Truncated: Message is not truncated
> ...0   = Recursion desired: Don't do query recursively
>  1...  = Recursion available: Server can do recursive 
> queries
>  .0..  = Z: reserved (0)
>  ..0.  = Answer authenticated: Answer/authority portion 
> was not authenticated by the server
>  ...0  = Non-authenticated data: Unacceptable
>   0011 = Reply code: No such name (3)
>Questions: 1
>Answer RRs: 0
>Authority RRs: 8
>Additional RRs: 1
>Queries
>_dmarc.prv.se: type TXT, class IN
>Name: _dmarc.prv.se
>[Name Length: 13]
>[Label Count: 3]
>Type: TXT (Text strings) (16)
>Class: IN (0x0001)
>Authoritative nameservers
>prv.se: type SOA, class IN, mname dns1.prv.se
>Name: prv.se
>Type: SOA (Start Of a zone of Authority) (6)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 39
>Primary name server: dns1.prv.se
>Responsible authority's mailbox: postmaster
>Serial Number: 2020111898
>Refresh Interval: 1200 (20 minutes)
>Retry Interval: 600 (10 minutes)
>Expire limit: 1209600 (14 days)
>Minimum TTL: 3600 (1 hour)
>prv.se: type RRSIG, class IN
>Name: prv.se
>Type: RRSIG (46)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 154
>Type Covered: SOA (Start Of a zone of Authority) (6)
>Algorithm: RSA/SHA-256 (8)
>Labels: 2
>Original TTL: 3600 (1 hour)
>Signature Expiration: Mar 20, 2021 00:30:42.0 GMT Standard 
> Time
>Signature Inception: Mar  9, 2021 23:30:42.0 GMT Standard 
> Time
>Key Tag: 16321
>Signer's name: prv.se
>Signature: 65005703e9ddebaeeb4b3b9441b0eee96207c2ad7fd51e2c...
>9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
>Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>Type: NSEC3 (50)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 43
>Hash algorithm: SHA-1 (1)
>NSEC3 flags: 0
> ...0 = NSEC3 Opt-out flag: Additional insecure 
> delegations forbidden
>NSEC3 iterations: 50
>Salt length: 8
>Salt value: 33e9285ab62c0803
>Hash length: 20
>Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
>RR type in bit map: A (Host Address)
>RR type in bit map: NS (authoritative Name Server)
>RR type in bit map: SOA (Start Of a zone of Authority)
>RR type in bit map: MX (Mail eXchange)
>RR type in bit map: TXT (Text strings)
>RR type in bit map: DS(Delegation Signer)
>RR type in bit map: RRSIG
>RR type in bit map: DNSKEY
>RR type in bit map: NSEC3PARAM
>9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type RRSIG, class IN
>Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>Type: RRSIG (46)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 154
>Type Covered: NSEC3 (50)
>Algorithm: RSA/SHA-256 (8)
>Labels: 3
>Original TTL: 3600 (1 hour)
>Signature Expiration: Mar 20, 2021 00:30:42.0 GMT Standard 
> Time
>Signature Inception: Mar  9, 2021 23:30:42.0 GMT Standard 
> Time
>Key Tag: 16321
>Signer's name: prv.se
>Signature: 

[dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Stephane Bortzmeyer]

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 probes' resolvers have the problem:

% blaeu-resolve -r 100 --displayvalidation  --type TXT _dmarc.prv.se
[ERROR: NXDOMAIN] : 86 occurrences
[ERROR: SERVFAIL] : 12 occurrences
Test #29281287 done at 2021-03-10T14:28:09Z

It seems limited to some (?) versions of BIND. All the other resolvers
I tested are fine. Here, with BIND:


; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @192.168.1.1 TXT _dmarc.prv.se
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22448
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a5d317b0ecd877372d40f20b6048d7eeb17f96fd42e1cd5b (good)
;; QUESTION SECTION:
;_dmarc.prv.se. IN TXT

;; Query time: 36 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Mar 10 15:30:06 CET 2021
;; MSG SIZE  rcvd: 70




; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +cd @192.168.1.1 TXT _dmarc.prv.se
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5521
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a202795cfd0e59e942562a706048d7f38ae88ad6b4988c85 (good)
;; QUESTION SECTION:
;_dmarc.prv.se. IN TXT

;; AUTHORITY SECTION:
prv.se. 3243 IN SOA dns1.prv.se. postmaster. (
2020111898 ; serial
1200   ; refresh (20 minutes)
600; retry (10 minutes)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)
prv.se. 3243 IN RRSIG SOA 8 2 3600 (
20210320003042 20210309233042 16321 prv.se.
VwPp3euu60s7lEGw7uliB8Ktf9UeLEMufsLVoalKCZ8G
i6Y5SL6u045fT2S//XpNwFZoFaJER1JtlOo5s97utv9k
gi2PFNWQ6VtfcMpYLcuvwuQ0xdwBUWBnmit7n0diZRzB
1KMSvzs7ur/+KBeGNcqqd4D2pjvxwYIHadDoQLY= )
9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
ESiImHBFB3n+cS/bm/5FFE4KiB1pZ3norVyytnXdd4pv
LrtnJyhXcdgipneyozq2+0c1iwzaLUzLFKnC8yeIjvXB
pB6JQwFXYNOQXjnZOB30nX/PU3hfrgGuODJrjargXkCl
69sUaYMwK+uW2J3NAofjFOMizAK7by1bWCe9b3Q= )
9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
9U28UGFJH153VH0IT0GU0CEDR2SQ93MA
A NS SOA MX TXT DS RRSIG DNSKEY NSEC3PARAM )
hup1us667e5fsc26ltim32tpkio8r12b.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
N/aPN5MuDY04vnfAU2SG/1ISeEcIAnpd6F6ufX4uwMrx
J/R/FP+fzp0mn3zuseu124aMFBzX8SG9rRDt1keVmCaH
9rqooFuPZvbCr2WKmTi9OAWIzJSOzVcfimNnrNNU0J5C
By7dkt0umlzoKt73S9M0dVdjkoSUwxsyt9kYtos= )
hup1us667e5fsc26ltim32tpkio8r12b.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
J20QA6CUD21FG9V4A6P6IEFNOURK87JC
CNAME RRSIG )
lh8nso9jvk3fcgelcakjp266mb0vctj5.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
D04hQjopnJoQJB3mPU+2fiECQcWdGDKpADFdbYF0SvYK
B2WbMgOdHV3aOTSnkNnWX0QDTyarJ8JWpIQnq1wfaAbD
n7AlF3eOWYWNolClRIchvY4dIBwBbYVHLRQ6f/Hul1ww
D17xe6SmUOaLGyYNlLrXSuYHHRAeGY/XwZLNTlc= )
lh8nso9jvk3fcgelcakjp266mb0vctj5.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
Q16A55QV24JJ8VKLC4U0DU1HGBA0QCM7
A RRSIG )

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Mar 10 15:30:11 CET 2021
;; MSG SIZE  rcvd: 1047


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] incapdns.net dnssec issue

[Sven Van Dyck via dns-operations]

--- Begin Message ---
Imperva/Incapsula which hosts a web application firewall (WAF) with many 
customers having a CNAME configured towards a record in their domain, 
incapdns.net. Incapsula had very recently DNSSEC configured on this 
zone; but last night the RRSIG on the DNSKEY record has expired; leaving 
every website behind incapdns.net unreachable for users of a validating 
DNS resolver. As a quick solution, Incapsula has removed the DS record 
from the parent zone, .net.  But, this record is still in many DNS 
caches (TTL=1 day).
Therefore, the question if it is possible for validating resolver 
maintainers to clear the cache of this DS record for the domain 
incapdns.net.

Thanks

--
*Sven Van Dyck*
*System Engineer*
+32 16 28 49 74
*www.dnsbelgium.be* 


--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations