New BIND releases are available: 9.18.28, 9.20.0
Thanks for the new release, and the hard work you do. I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu USN-6909-1 to preform a security update. I deployed this into production after passing some tests when installed in a lab. After the upgrade, Internal Zones that were hosted by Windows Active Directory were rejected and caused a production impact. Under Windows Active Directory, the DC's create a round robin DNS record at the apex of the zone and the number of entries approximately match the number of DC's in the domain. It is not uncommon to have hundreds of DC's in a domain, so setting a limit of 100 will likely cause a series of unexpected outages for IT administrators. Because this change restricts existing functionality, This is a breaking change and as such should be reserved to a minor release. If this feature was critical to resolve an issue a provider was having, it should be shipped with default values of 0 causing it to be effectively disabled allowing the provider to opt in. I was able to resolve this issue by adding the following directive to the affected views: max-types-per-name 1000; --James -- 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: New BIND releases are available: 9.18.28, 9.20.0
I should have said, I changed the following parameter to resolve the issue: max-records-per-type 1000; --James On 7/24/24 07:18, James Stegemeyer wrote: Thanks for the new release, and the hard work you do. I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu USN-6909-1 to preform a security update. I deployed this into production after passing some tests when installed in a lab. After the upgrade, Internal Zones that were hosted by Windows Active Directory were rejected and caused a production impact. Under Windows Active Directory, the DC's create a round robin DNS record at the apex of the zone and the number of entries approximately match the number of DC's in the domain. It is not uncommon to have hundreds of DC's in a domain, so setting a limit of 100 will likely cause a series of unexpected outages for IT administrators. Because this change restricts existing functionality, This is a breaking change and as such should be reserved to a minor release. If this feature was critical to resolve an issue a provider was having, it should be shipped with default values of 0 causing it to be effectively disabled allowing the provider to opt in. I was able to resolve this issue by adding the following directive to the affected views: max-types-per-name 1000; --James -- 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: bind-users Digest, Vol 4516, Issue 1
Veronique,
There are two restrictions:
max-types-per-name 100; (Unlikely to cause issues)
max-records-per-type 100;
So to list the counts of each each name you could use the following command:
dig -t axfr $zone @$server | awk '{print $1,$4}' | sort | uniq -c | sort -n
Where $zone is zone FQDN and $server is DNS server.
When I ran this command the following two entries had the highest counts:
NNN _ldap._tcp.DomainDnsZones.~~~.com
NNN _ldap._tcp.ForestDnsZones.~~~.com
Thanks,
--James
On 7/25/24 09:08, Veronique Lefebure wrote:
Hi,
We had the same issue as James, fortunately with no impact on production.
But I agree that , although I finally found the warning at the very
bottom of the mail announcing the new release, this MAJOR change
should have been announced more clearly.
How do you find out whether or not you have domains with more than 100
records?
I myself was not aware of that until our domain got dropped (on a
non-production server, luckily)
cheers,
Veronique
*From:* bind-users on behalf of
bind-users-requ...@lists.isc.org
*Sent:* Thursday, July 25, 2024 2:00 PM
*To:* bind-users@lists.isc.org
*Subject:* bind-users Digest, Vol 4516, Issue 1
Send bind-users mailing list submissions to
bind-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org
You can reach the person managing the list at
bind-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."
Today's Topics:
1. Re: New BIND releases are available: 9.18.28, 9.20.0 (Ond?ej Sur?)
--
Message: 1
Date: Wed, 24 Jul 2024 06:09:14 -0700
From: Ond?ej Sur?
To: James Stegemeyer
Cc: bind-users@lists.isc.org
Subject: Re: New BIND releases are available: 9.18.28, 9.20.0
Message-ID:
Content-Type: text/plain; charset=utf-8
Hi James,
I understand this has caused you some discomfort, but it was
documented both
in the release notes and in the announcement and it was necessary to
introduce
the limits because more fix would have to be intrusive refactoring of
the internals,
and that is exactly the thing that we were trying to avoid.
As for your suggestion to ship the BIND 9 in a vulnerable state - that
would be
absolutely wrong thing to do. We released the new version to make sure the
BIND 9 is not vulnerable in the default configuration and
administrators might
assess the risks when increasing the value of the max-types-per-name
for their
particular environment.
Cheers,
Ondrej
--
Ond?ej Sur? (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do
not feel obligated to reply outside your normal working hours.
> On 24. 7. 2024, at 4:18, James Stegemeyer wrote:
>
> Thanks for the new release, and the hard work you do.
>
> I recently upgraded from 9.18.24 to 9.18.28 per prompting by Ubuntu
USN-6909-1 to preform a security update. I deployed this into
production after passing some tests when installed in a lab. After
the upgrade, Internal Zones that were hosted by Windows Active
Directory were rejected and caused a production impact. Under Windows
Active Directory, the DC's create a round robin DNS record at the apex
of the zone and the number of entries approximately match the number
of DC's in the domain. It is not uncommon to have hundreds of DC's in
a domain, so setting a limit of 100 will likely cause a series of
unexpected outages for IT administrators. Because this change
restricts existing functionality, This is a breaking change and as
such should be reserved to a minor release. If this feature was
critical to resolve an issue a provider was having, it should be
shipped with default values of 0 causing it to be effectively disabled
allowing the provider to opt in.I
was able to resolve this issue by adding the following directive to
the affected views:
> max-types-per-name 1000;
>
> --James
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users
<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/
<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
<https://lists.isc.org/mailman/listinfo/bind-users>
--
Subject: Digest Footer
Re: Question about "too many records"
J,
This issue has been covered by earlier threads, and is mentioned on the
BIND 9.18.28 release notes.
Starting with BIND 9.18.28 changes were made to mitigate performance
impact CVE-2024-1737 BIND database will be slow if if a very large
number of RRs exist at the same name.
If you find yourself in this situation, you can increase the
"max-records-per-type" parameter which was introduced in bind 9.18.28.
I find that it is common for large Active Directory zone to have a large
quantity of RR with the same name which concentrates at the domain APEX
and for the LDAP SRV records. Increasing this parameter dilutes the
protection you will receive against CVE-2024-1737 the default value of
100 was chosen based on a performance knee which occurs at around 100
records.
You can use the following command, if you have access to a Linux based
system to create a histogram of number of RRs for the same name.
dig -t axfr $zone @$server | awk '{print $1,$4}' | sort | uniq -c | sort -n
Thanks,
--James Stegemeyer
On 8/1/24 17:09, J Doe wrote:
Hi,
I run my own validating recursive resolver with BIND 9.18.28.
In the resolver logs I noticed:
01-Aug-2024 10:30:22.294 query-errors: info: client @0xec879280280
127.0.0.1#14435 (bf10x.hubspotemail.net): query failed (too many
records) for bf10x.hubspotemail.net/IN/A at query.c:7842
The client in this case was my mail server software. What does "query
failed (too many records) ..." mean ?
Is this BIND saying that the client (the mail server software),
requested too many records or that the result of the query yielded too
many records or something else ?
Thanks,
- J
--
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
