Re: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?

[Petr Menšík]

Hi Kurt,

we do not ship exim in RHEL, so nobody from our team did proper work on 
these vulnerabilities. From the few information that I have found, I 
would just guess BIND9 or Unbound should help protecting exim. Dnsmasq 
or coredns do not create full response message from scratch, but forward 
original responses from upstream, unless it cached it already. So with 
BIND it should be better, but no guarantees given. Local validating 
resolver should help in any case. But without more detailed information 
about the vulnerability, we are just guessing.


Best Regards,
Petr

On 02. 10. 23 11:06, Kurt Jaeger wrote:

Hi!

In the light of the recent exim security issues[1,2]
I'm trying to find out if bind 9.18.19, if used as resolver,
does enough validation to shield exim instances from CVE-2023-42119 ?

As details and reproducers for the CVE are not available, this is a
more general question. Pointers on where I can read more about it
are highly appreciated!

There are probably two aspects to validation:
- Validating DNSSEC (the more common use case of validation)
- Validating DNS request/replies in general (bailiwick, cache polution etc).

[1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html
[2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/


--
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

Re: Is bind 9.18.19 a validating resolver to shield against CVE-2023-42119 ?

[Rob van der Putten via bind-users]

Hi there


On 02/10/2023 11:06, Kurt Jaeger wrote:


In the light of the recent exim security issues[1,2]
I'm trying to find out if bind 9.18.19, if used as resolver,
does enough validation to shield exim instances from CVE-2023-42119 ?


I added 'check-names response fail;' to the internal view.
So far this blocked a few hosts with underscore and comma in the name, 
which didn't break anything.
I'm assuming that this will protect DNS lookups. But that's just an 
assumption.



As details and reproducers for the CVE are not available, this is a
more general question. Pointers on where I can read more about it
are highly appreciated!

There are probably two aspects to validation:
- Validating DNSSEC (the more common use case of validation)
- Validating DNS request/replies in general (bailiwick, cache polution etc).

[1] https://lists.exim.org/lurker/message/20231001.165119.aa8c29f9.en.html
[2] https://www.zerodayinitiative.com/advisories/ZDI-23-1473/



Regards,
Rob


--
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

Re: Hyperlocal RFC8806 Root Mirror

[Petr Menšík]

Hi Silva,

I do not understand that tutorial language and you have not shared much 
details what it should do. But note that bind will cache both positive 
and negative (non-existent) answers, so repeated tests answers are 
delivered from cache even when local domain is not present. I would 
recommend using statistics counters of forwarded queries instead of 
response time.


Aggressive DNSSEC validation can be used to synthetize response for 
names not yet queried, if the name is in range of already negative 
answer previously received. The result might be similar to local copy of 
root zone if enough negative answers is cached.


This is enabled by default per 
https://bind9.readthedocs.io/en/v9.18.19/reference.html#namedconf-statement-synth-from-dnssec 
in version 9.18.19. If you have dnssec-validation yes or auto, then this 
would be active. So cache state can make replies instant. I think 
observing traffic using wireshark or statistics counters might be 
provide more reliable metric.


Best Regards,

Petr

On 27. 09. 23 17:53, Silva Carlos wrote:

+

Hey guys.
I have two recursive servers, bind 9.18 on Debian 12.

On server A I configured HyperLocal. On Server B I did NOT configure 
HyperLocal.


I ran the command "dig @localhost EXAMPLES" on both servers.
EXAMPLES: blabla.sdf.dd or teste.com.eroterrter or world.nanana

Problem: Both Servers report that "Query TIme = 0 ms". I understand 
that Server A should result in 0ms and Server B should have a non-zero 
time as Server B does not have a copy of the Root Zone DB.


Question: Where am I going wrong? Am I missing some basic principle?


I'm following this tutorial: 
https://semanacap.bcp.nic.br/files/apresentacao/arquivo/864/Implementacao%20de%20servidores%20recursivos%20guia%20de%20praticas%20semcap%20ceptro%20br.pdf


Best Regards +

 
	Não contém vírus.www.avast.com 
 





--
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

Re: resolver: DNS format errors

[Petr Menšík]

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  wrote:



On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews  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, A 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, A 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
;; WARNI

Re: resolver: DNS format errors

[Mark Andrews]

> On 4 Oct 2023, at 06:31, Petr Menšík  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  wrote:
>>> 
>>> 
>>> 
>>> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews  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, A 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, A 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 P