Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?
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. I've also encountered DS in the middle of a zone -- i.e. on a name without NS, in this case also with some child names existing within the same zone. I didn't find that it's really forbidden, but on the other hand I've had no motivation to fix Knot Resolver's forwarding+validation mode to tunnel through such an obstacle. That zone got fixed eventually, too. --Vladimir ___ 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?
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: 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'. 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. - Matthijs 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, ___ 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?
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?
> 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?
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?
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?
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?
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?
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?
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