> On 4 Oct 2023, at 06:31, Petr Menšík <pemen...@redhat.com> wrote:
>
> Hi Mark,
>
> I have seen this error before and I admit it is quite annoying. Especially
> when the owners of failing implementations refuse to fix their bugs. Is there
> any possibility to tune this only for set of broken servers?
>
> server prefix {} block can set different features for selected server(s),
> disabling even EDNS0 extension. But qname-minimization cannot be changed
> selectively. Be it per address or (sub)domain, it would be useful until all
> implementations fix their behaviour.
Disabling EDNS is about constructing individual queries. QNAME minimisation is
about changing the series of queries made while iterating. Very different
things.
> Would it make sense to allow disabling qname minimization in server blocks
> also? Is there specific reason, why this can be changed only per view or
> globally? Is there other workaround possible? May stub zones help with this?
Stub zones don’t disable QNAME minimisations below them. The just short
circuit the iteration process above them.
Really I don’t want to be writing code to just deal with SpamHaus’s
mis-implementation. They should fix their broken servers.
> Cheers,
> Petr
>
> On 19. 09. 23 1:53, Mark Andrews 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
>>>
>>>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> --
> 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
--
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
