resolver: DNS format errors
Petr Menšík
pemensik at redhat.com
Tue Oct 3 19:31:56 UTC 2023
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.
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?
Cheers,
Petr
On 19. 09. 23 1:53, Mark Andrews wrote:
>
>> On 19 Sep 2023, at 02:14, Alex <mysqlstudent at gmail.com> wrote:
>>
>>
>>
>> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews <marka at 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
More information about the bind-users
mailing list