Correction, they incorrectly answer the SOA query. > On 19 Sep 2023, at 09:53, Mark Andrews <ma...@isc.org> wrote: > > > >> On 19 Sep 2023, at 02:14, Alex <mysqlstud...@gmail.com> wrote: >> >> >> >> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews <ma...@isc.org> wrote: >> Spamhaus’s servers are sending back responses that do not answer the >> question. Named is doing QNAME minimisation using NS queries and rather than >> the servers sending back a NODATA response for the empty non-terminal names >> they are sending back the NS records for the top of the zone. >> >> I suggest that you ask them to fix their DNS servers to correctly answer NS >> queries. They appear to need to look at the query name as well as the query >> type. >> >> This is what often happens when you write custom DNS servers. You fail to >> handle some query you weren’t planning for. >> >> They have just recommended disabling qname-minimization altogether. Is that >> the right solution? > > No. The correct solution is for them to fix their broken servers. Their > servers give correct > answers for DS, A, TXT, SOA, AAAAA and others but not for NS (a referral back > to the same > servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they > do for DS, A, TXT, > SOA, AAAAA and others). This is behaviour that is specified in RFC 1034 that > is wrong. QNAME > minimisation (RFC 7816) is a security fix designed to prevent leaking of > query names and types > to servers closer to the root that don’t need this information and it works > with all servers > that are DNS protocol compliant. They are recommending that you turn off a > security fix. > > > RFC 1034, 4.3.2. Algorithm > > ... > > 2. Search the available zones for the zone which is the nearest > ancestor to QNAME. If such a zone is found, go to step 3, > otherwise step 4. > > 3. Start matching down, label by label, in the zone. The > matching process can terminate several ways: > > a. If the whole of QNAME is matched, we have found the > node. > > If the data at the node is a CNAME, and QTYPE doesn’t > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > Otherwise, copy all RRs which match QTYPE into the > answer section and go to step 6. > > ... > > 6. Using local data only, attempt to add other RRs which may be > useful to the additional section of the query. Exit. > > Step 2 gives zrd.dq.spamhaus.net. Step 3a matches > pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > and as there isn’t NS records at that name the answer section should be > empty. Adding referral > records is done in step 3b which is skipped. > > b. If a match would take us out of the authoritative data, > we have a referral. This happens when we encounter a > node with NS RRs marking cuts along the bottom of a > zone. > > Copy the NS RRs for the subzone into the authority > section of the reply. Put whatever addresses are > available into the additional section, using glue RRs > if the addresses are not available from authoritative > data or the cache. Go to step 4. > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ds @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ds > @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26823 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN DS > > ;; AUTHORITY SECTION: > zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. > 2309182309 3600 600 432000 1 > > ;; Query time: 194 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:11:44 AEST 2023 > ;; MSG SIZE rcvd: 151 > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' txt @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > txt @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65222 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN TXT > > ;; AUTHORITY SECTION: > zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. > 2309182309 3600 600 432000 1 > > ;; Query time: 188 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:12:05 AEST 2023 > ;; MSG SIZE rcvd: 151 > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' soa @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > soa @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29540 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN SOA > > ;; ANSWER SECTION: > zrd.dq.spamhaus.net. 900 IN SOA need.to.know.only. hostmaster.spamhaus.org. > 2309182311 3600 600 432000 1 > > ;; Query time: 188 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:12:18 AEST 2023 > ;; MSG SIZE rcvd: 151 > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ns @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ns > @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30418 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN NS > > ;; ANSWER SECTION: > zrd.dq.spamhaus.net. 3600 IN NS a.gns.spamhaus.net. > zrd.dq.spamhaus.net. 3600 IN NS b.gns.spamhaus.net. > zrd.dq.spamhaus.net. 3600 IN NS c.gns.spamhaus.net. > zrd.dq.spamhaus.net. 3600 IN NS d.gns.spamhaus.net. > zrd.dq.spamhaus.net. 3600 IN NS e.gns.spamhaus.net. > > ;; Query time: 187 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:12:23 AEST 2023 > ;; MSG SIZE rcvd: 159 > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' type1000 > @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > type1000 @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 3121 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN TYPE1000 > > ;; Query time: 201 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:12:42 AEST 2023 > ;; MSG SIZE rcvd: 75 > > % > >> It doesn't seem to be complete for me. It prints hundreds of these >> (presumably one for each DNS request necessary to process the email?): >> >> 18-Sep-2023 12:07:25.561 lame-servers: FORMERR resolving >> 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net/NS/IN': 209.222.201.139#53 >> 18-Sep-2023 12:07:25.584 resolver: DNS format error from 50.31.133.59#53 >> resolving mykey.zrd.dq.spamhaus.net/NS for <unknown>: reply has no answer >> >> ... then a strange line like this: >> >> 18-Sep-2023 12:13:31.606 lame-servers: success resolving >> 'um27qfow2knpuwx56o4otvovib2zbomydtlkuo4sktbo34cmjqvq._file.mykey.hbl.dq.spamhaus.net/A' >> after disabling qname minimization due to 'failure' >> >> btw, their support really sucks. >> >> Thanks, >> Alex >> >> > > -- > 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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
