Re: New BIND releases are available: 9.18.28, 9.20.0

[Victoria Risk]

Adam,

> What is the proper mapping of "Current Stable, ESV", "Development", and "New 
> Stable" BIND versions to their respective COPR repos? I feel like it should 
> be obvious, but I am missing something.

I did consider whether we should summarize this in the announcement. Perhaps I 
should have. It is confusing but as Ondřej pointed out, it was discussed here, 
and was intentional for user benefit. We think that most users are unlikely to 
want to swap their production environment from one stable version to a new .0 
stable version the day it is released, so this design was supposed to minimize 
surprise major version upgrades.

BIND 9.20.0 is in the bind-dev repositories, because it is the least delta vs 
the last development release on 9.19. There is no new 9.19 version released 
today, so that == 9.20.0. So, IF you are using 9.19.x in a production 
environment, you should update to 9.20 to fix any CVEs that may apply in your 
situation.  

now (July 2024)
bind = 9.18
bind-esv = 9.18
bind-dev = 9.20.0

later (once we have a new 9.21 version, August?? 2024)
bind = 9.20.x
bind-esv = 9.18.x
bind-dev = 9.21.x

I hope this is a bit clearer. Sorry for not including this in the announcement.

Vicky

> On Jul 23, 2024, at 10:31 AM, Ondřej Surý  wrote:
> 
> Hi Adam,
> 
> this was discussed a month ago:
> 
> https://lists.isc.org/pipermail/bind-users/2024-June/108638.html
> 
> and we were basically asked to make the bumps in the repositories to not 
> follow the releases.
> 
> 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 23. 7. 2024, at 10:17, Adam Augustine  wrote:
>> 
>> First, thank you all for the hard work you do on BIND.
>> 
>> What is the proper mapping of "Current Stable, ESV", "Development", and "New 
>> Stable" BIND versions to their respective COPR repos? I feel like it should 
>> be obvious, but I am missing something.
>> 
>> I think I expected 9.18.28 to appear in isc/bind-esv with this release 
>> (which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as 
>> far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in 
>> isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind" 
>> directory is hidden in isc/bind, it is accessible and referenced in the 
>> respective repo xml files). I recognize that a direct upgrade from 9.18 to 
>> 9.20 for those on the isc/bind repo might be a bit surprising at this point, 
>> despite the very clear messaging about how the versioning is meant to work, 
>> but at the same time, I wouldn't expect we want people using the 
>> isc/bind-dev repo to get 9.20.0 for production use either.
>> 
>> I don't recall how this transition was handled for 9.16->9.18, but if I 
>> recall it seemed like it just magically worked for us. But back then we 
>> weren't as aggressive about updating as we are now. I probably just missed 
>> some explanation somewhere about how the transition is meant to be handled, 
>> but my searches aren't returning anything specific to this situation. 
>> Speaking of which, is there an equivalent to the 
>> https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918
>>  article for 9.18->9.20? 
>> 
>> We have already upgraded most of our systems to 9.18.28, but want to move to 
>> 9.20.0 soon, but aren't certain the right way forward.
>> 
>> Thanks again for this release. I know refactoring code is extremely 
>> challenging and doesn't get the praise it deserves.
>> 

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

New BIND releases are available: 9.18.28, 9.20.0

[Victoria Risk]

BIND users-

Our July 2024 maintenance release of BIND 9.18, as well as the new 9.20.0 
stable branch, are available and can be downloaded from the ISC software 
download page, https://www.isc.org/download.

In addition to bug fixes and feature improvements, these releases also contain 
fixes for security vulnerabilities (CVE-2024-0760, CVE-2024-1737, 
CVE-2024-1975, CVE-2024-4076), about which more information is provided in the 
following Security Advisories:

https://kb.isc.org/docs/cve-2024-0760
https://kb.isc.org/docs/cve-2024-1737
https://kb.isc.org/docs/cve-2024-1975
https://kb.isc.org/docs/cve-2024-4076

A summary of significant changes in the new releases can be found in their 
release notes:

  - Current supported stable branches:

9.18.28 - 
https://downloads.isc.org/isc/bind9/9.18.28/doc/arm/html/notes.html
9.20.0  - https://downloads.isc.org/isc/bind9/9.20.0/doc/arm/html/notes.html

We also have a nice blog post from Ondřej Surý on the 9.20.0 release, including 
performance testing results (https://www.isc.org/blogs/2024-bind920/).

---
Please Note:

To create an effective mitigation for CVE-2024-1737 we have introduced two new 
configurable limits that prevent the loading (into zones or into cache) of DNS 
resource records (RRs) that exceed them. We therefore recommend reading this KB 
article,
https://kb.isc.org/docs/rrset-limits-in-zones, in case you need to change the 
defaults to suit your specific operational environment.

We recommend that users planning to upgrade from the EOL 9.16 branch read the 
following document first:


https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918

-- 
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: tryisc.com is not an isc.org domain

[Victoria Risk]

Update: 

This was not the fraud we thought it was 

We have learned that emails we originally identified as abuse were sent by an 
external contractor engaged by ISC to conduct a focussed and short-term lead 
generation campaign. We have instructed the vendor to halt that campaign.

We clearly suffered some communications failures here. Our communication with 
the vendor should have made it clear that we would not be comfortable with the 
approach they adopted. Plus, our internal communication failed as we lacked 
sufficient awareness of the campaign to respond in a more appropriate fashion 
when we received questions about the emails.

We have been assured by the vendor that this was not a bulk unsolicited email 
campaign. We affirm our stance that bulk unsolicited email is counter to our 
mission in support of Internet infrastructure.

We apologize for any inconvenience or disruption this event may have caused. We 
promptly canceled our abuse complaint concerning the domain name, and we ask 
any of you who have taken any filtering or blocking or complaint action against 
the domain name or the originating IP addresses to do the same. We appreciate 
the outpouring of sympathy from our community, many of whom have emailed us 
with helpful suggestions. We thank you for your continued support.



> On Jun 25, 2024, at 10:42 AM, Victoria Risk  wrote:
> 
> BIND-users,
> 
> Someone is sending emails from tryisc.com, pretending to be from Internet 
> Systems Corporation, and offering information about undisclosed BIND software 
> vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
> are not authorized by ISC.
> 
> If you feel you have received illegitimate communications from someone 
> purporting to be an ISC staff member, please report it 
> (https://www.isc.org/security-report/). If someone other than ISC.org is 
> offering to provide software vulnerability information about ISC software, 
> this is suspicious and probably fraudulent. ISC does offer professional 
> support services, which includes advance notification of security 
> vulnerabilities in our software but we have not authorized anyone else to 
> disclose that information prior to public disclosure.
> 
> Be safe out there, and check the domain name if you are not sure about the 
> sender. ISC.org <http://isc.org/> is signed, so you can also validate it 
> (since you are all operating resolvers, right?).
> 
> Vicky Risk (working at the actual ISC.org <http://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

tryisc.com is not an isc.org domain

[Victoria Risk]

BIND-users,

Someone is sending emails from tryisc.com, pretending to be from Internet 
Systems Corporation, and offering information about undisclosed BIND software 
vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
are not authorized by ISC.

If you feel you have received illegitimate communications from someone 
purporting to be an ISC staff member, please report it 
(https://www.isc.org/security-report/). If someone other than ISC.org is 
offering to provide software vulnerability information about ISC software, this 
is suspicious and probably fraudulent. ISC does offer professional support 
services, which includes advance notification of security vulnerabilities in 
our software but we have not authorized anyone else to disclose that 
information prior to public disclosure.

Be safe out there, and check the domain name if you are not sure about the 
sender. ISC.org  is signed, so you can also validate it (since 
you are all operating resolvers, right?).

Vicky Risk (working at the actual 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

Re: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records

[Victoria Risk]

Karl,

We have a knowledgebase article on the topic of ‘alias’ records: 
https://kb.isc.org/docs/aa-01640. The article is a bit out of date, but still 
basically valid.  It is not specific to the implementation you mention however. 

Vicky

> On Mar 26, 2024, at 7:49 AM, Karl Auer  wrote:
> 
> I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone
> knows how it is handled "under the hood"?
> 
> It seems to be a non-standard extension that some DNS providers
> support. It seems to work similarly to, but not quite the same way as,
> a CNAME. Its big advantage over a CNAME is that it can coexist with
> other records of the same name (LHS). However, it seems to be non-
> standard.
> 
> - when you look up the LHS, you do not get the ALIAS RHS back
> 
> - it seems to internally look up the RHS, and return those results
> 
> - if you make an A query, you get any matching A records back, as well
> as the results from any ALIAS records with the same LHS
> 
> - the TTLs of records obtained via the ALIAS are inherited from the TTL
> of the ALIAS record
> 
> - the real TTLS of the A records behind the ALIAS are lost. This seems
> to be risky
> 
> Same providers say it is faster to resolve than a CNAME; I can't see
> why that would be.
> 
> Regards, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au, he/him)
> http://www.biplane.com.au/kauer
> 
> 
> -- 
> 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

-- 
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 9.16 is approaching EOL in April, 2024

[Victoria Risk]

> On Mar 11, 2024, at 4:09 PM, John Thurston  wrote:
> 
> I assume the day is approaching when the packages in the COPR repositories 
> will be changed; isc/bind-esv will have 9.18 (instead of 9.16), and ics/bind 
> will have 9.20
> 
> So that we might start weaving this into our maintenance plans, is there a 
> projected date on which this will happen?
> 

I think this will happen in May - because we plan to release our last 9.16 
package in April.

> --
> Do things because you should, not just because you can. 
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov <mailto:john.thurs...@alaska.gov>
> Department of Administration
> State of Alaska
> On 2/26/2024 7:35 AM, Victoria Risk wrote:
>> The BIND 9.16 release branch is approaching EOL as of April, 2024. We 
>> encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. 
>> 
>> The 9.18 branch has consistently out-performed the 9.16 branch, and we are 
>> confident that it is more stable than 9.16. One of our support engineers has 
>> prepared a helpful knowledgebase article on updating from 9.16 to 9.18 
>> (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918)
>>  which may be useful to you as you plan your migration.
>> 
>> For an overview of our release plan, we maintain another knowledgebase 
>> article (https://kb.isc.org/docs/aa-00896). This was updated earlier this 
>> month, to move the start of future new stable branches from Q1 to Q2. The 
>> problem with starting a new stable branch in Q1 is, after the long holiday 
>> quiet period, we always have a number of important fixes and changes we need 
>> to release *before* we can start a new stable branch. We are currently 
>> projecting that our next stable branch, BIND 9.20, will be released in Q2.
>> 
>> For your convenience, we also maintain our planned EOL dates listed next to 
>> each software release on https://www.isc.org/download/.
>> 
>> Vicky Risk
> -- 
> 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

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

BIND 9.16 is approaching EOL in April, 2024

[Victoria Risk]

The BIND 9.16 release branch is approaching EOL as of April, 2024. We encourage 
users running 9.16 or (gasp) 9.11, to upgrade to 9.18. 

The 9.18 branch has consistently out-performed the 9.16 branch, and we are 
confident that it is more stable than 9.16. One of our support engineers has 
prepared a helpful knowledgebase article on updating from 9.16 to 9.18 
(https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918)
 which may be useful to you as you plan your migration.

For an overview of our release plan, we maintain another knowledgebase article 
(https://kb.isc.org/docs/aa-00896). This was updated earlier this month, to 
move the start of future new stable branches from Q1 to Q2. The problem with 
starting a new stable branch in Q1 is, after the long holiday quiet period, we 
always have a number of important fixes and changes we need to release *before* 
we can start a new stable branch. We are currently projecting that our next 
stable branch, BIND 9.20, will be released in Q2.

For your convenience, we also maintain our planned EOL dates listed next to 
each software release on https://www.isc.org/download/.

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

ISC is hiring a Technical Support Engineer

[Victoria Risk]

ISC is hiring a Technical Support Engineer to help BIND 9, Kea and DHCP users. 
This is a 100% remote working opportunity, with flexible hours. The team spans 
the US and Europe, but right now need someone who can help cover US business 
hours. This is an interesting job with a lot of variety and fun and supportive 
colleagues. If you like helping people, and you have experience as a system 
adminstrator that would equip you to advise other sysadmins, we would love to 
hear from you. ISC has a generous health insurance benefit for US staff.

Please apply with the link below, it helps us to keep track of your application 
so we don’t forget to get back to you.

https://isc.recruitee.com/o/support-engineer-for-isc-bind-and-kea-dhcp-2
Support Engineer for ISC BIND, and Kea DHCP
isc.recruitee.com

-- 
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: DoT forwarding from BIND9

[Victoria Risk]

> On Dec 14, 2022, at 10:12 AM, Petr Menšík  wrote:
> 
> Hello,
> 
> I tried to find a way how to configure queries forwarding over encrypted 
> channel. But unlike zone transfer and notifications, I have not found a way 
> to configure query forwarding over DNS over TLS even in latest 9.18.9 version.
> 

Petr,

You didn’t miss it, we don’t have it yet. 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3726

Vicky-- 
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: High memory consumption in bind 9.18.2

[Victoria Risk]

Hi Doug,

I think Ondrej is referring to this post from a prior month: 
https://lists.isc.org/pipermail/bind-users/2022-June/106350.html

….
For tips on how to measure memory usage you might want to look at 
https://stackoverflow.com/questions/131303/how-can-i-measure-the-actual-memory-usage-of-an-application-or-process
 

 …..

Also note the comment about ignoring ’total’ memory.

Vicky

> On Aug 1, 2022, at 10:32 AM, Ondřej Surý  wrote:
> 
>> On 1. 8. 2022, at 16:14, Doug Whitfield  wrote:
>> 
>> as monitored from "top" RES value
> 
> Please read the whole thread on measuring the real consumed memory.
> 
> The '“top” RES value' has little or no value at all.
> 
> 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.
> 
> 
> -- 
> 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

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

Reminder about moderation and the code of conduct

[Victoria Risk]

Many of you have been members of the bind-users mailing list for many years, 
and have both given and received advice to/from other participants. So you 
understand what a helpful and caring community it can be. 

We appreciate all of you who generously share your expertise here, and we want 
to protect the list for everyone. We have taken the difficult decision to ban 
one participant who has repeatedly belittled or scorned others who, in his 
judgement, lacked expertise or understanding. Even though he often gave good 
technical advice, his harsh tone was making the environment feel hostile for 
others.

If a few posters are unpleasant to users who are confused, misinformed, or 
inexpert, it can discourage many others reading the list from participating.  
At this time we want to remind everyone to please:

   - Be friendly and patient.
   - Be welcoming.
   - Be considerate.
   - Be respectful.
   - Choose your words carefully. Remember that many list subscribers are not 
native English-speakers.
   - Understand that posters are looking for advice and help, not criticism. 
Excessive criticism merely discourages people from asking for help. 

We realize it can be difficult to be patient when you think the poster is 
wasting your time, is lazy, or is obscuring their data unnecessarily, but it is 
always an option to not reply if you cannot maintain a helpful attitude. 
Remember that every post has many other readers and that you are not required 
to answer.  

We would like to remind all participants on this list that this community has a 
code of conduct. 
The code of conduct is at 
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CODE_OF_CONDUCT.md 
, and 
it is linked in the description of the bind-users mailing list 
(https://lists.isc.org/mailman/listinfo/bind-users 
).

If you see a post on this list that you think is in violation of the code of 
conduct, please alert one of the moderators by emailing cond...@isc.org. We do 
periodically moderate discussions that get overheated, and repeated violators 
will be banned permanently.

- The moderators (Ondrej Sury, Chuck Stearns, Vicky Risk)

-- 
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: Only one DS key comes back in query

[Victoria Risk]

Hi Frank,

The use of example.com and the like on this list is provocative specifically 
because people are frustrated that they then cannot help you. It is something 
of a special situation that since you are not a regular participant here, you 
were unaware of. 

The people on this list will often go to great lengths to help people who post 
problems here, by diagnosing the domain that is having an issue. The way that 
is done is by querying the domain, perhaps closely related domains (parents, 
children, etc), looking at signatures, other fields in the response, etc. This 
very often leads quickly to an answer that helps the poster. This kind of 
active help in troubleshooting your DNS issue cannot be done if you obscure the 
domain name, and that can be frustrating for people on the list who then cannot 
help you. 

This is why it says in the list information: 
(https://lists.isc.org/mailman/listinfo/bind-users)
- If you are debugging an active issue with an externally published domain, 
providing the full domain name allows others to query it in order to help you. 
Omitting, changing, or obscuring the domain can make it harder or impossible 
for others to help you. 

Regards,

Vicky Risk

> On May 16, 2022, at 8:41 PM, frank picabia  wrote:
> 
> I've been using open source for decades.  Long enough that I rarely need to 
> use lists for help.
> 
> Here's the RFC mentioning reserved domain name use:  
> https://www.rfc-editor.org/rfc/rfc2606.html 
> 
> 
> I am ridiculed by an ISC member for using a reserved domain according to the 
> purpose in the RFC and then
> a second ISC member states I am arrogant?   I think there's a bunch of you 
> that need to check your privilege!
> Or maybe these persons are the chief whips responsible for driving people 
> from the lists into paying customers?
> 
> Check other lists.  Postfix. Apache.  Whatever.  No one ever has an issue 
> when they see example.com 
> It's widely known as the boilerplate value you're leaving out of the equation 
> for the moment.
> 
> In the documentation I see this:
> 
> Once the rndc reconfig 
> 
>  command is issued, BIND serves a signed zone. The file dsset-example.com 
>  (created by dnssec-signzone 
> 
>  when it signed the example.com  zone) contains the DS 
> record for the zone’s KSK. You will need to pass that to the administrator of 
> the parent zone, to be placed in the zone.
> 
> It seems the first value in dsset file is okay.  The documentation doesn't 
> talk about the second one, and this is where
> the problem is seen.  I see one value on the second key (digest 2) in dsset 
> file, and a different value using the value
> obtained by running something like:
> 
> dig @localhost dnskey irrashai.net  | dnssec-dsfromkey 
> -f – irrashai.net 
> The digest 2 second key here seems to be what should be used with the domain 
> registrar.  I'll soon find out.
> 
> 
> 
> On Mon, May 16, 2022 at 2:54 PM Ondřej Surý  > wrote:
> Well, then don’t expect people will want to help you. If you need to hide the 
> information and you need help then you should be prepared to pay for the 
> support. Coming to open source list asking for help for free and expect other 
> people to help you is just plain arrogant behavior. Again, Bert Hubert was 
> exactly right here:
> 
> https://berthub.eu/articles/posts/anonymous-help/ 
> 
> 
> Ondrej
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 16. 5. 2022, at 19:06, frank picabia > > wrote:
>> 
>> Suppose I was working on a problem for Barclays
>> Bank, do you suppose they would be thrilled with me posting
>> their networking innards for the world to see?
> -- 
> 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

-- 
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: Reminder: BIND 9.11 is going EOL in March 2022

[Victoria Risk]

> On Apr 5, 2022, at 12:37 PM, John Thurston  wrote:
> 
> We've reached April, 2022. I expect, in the next 30-days or so, we'll be 
> seeing an announcement regarding the change of contents of bind-esv, bind, 
> and bind-dev
> 
> Is it reasonable to expect these changes will occur in about the middle of 
> the month?

Yes - good question. We will replace the contents of the repos when we post the 
next version. We usually post the BIND releases on the third Wednesday of the 
month, so the changeover should happen on April 20th.

Regards,

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

Reminder: BIND 9.11 is going EOL in March 2022

[Victoria Risk]

Hello bind-announce,

BIND 9.11 is now in its last quarter of support. We are fixing critical 
security issues only at this point. It is time to start making plans to update 
if you are still running a 9.11 version. (The current release plan is published 
at https://kb.isc.org/docs/aa-00896 .)

BIND 9.11.0 was published in October of 2016. A *lot* has happened since then. 
Also, we have refactored some significant functions in BIND and 9.16 has quite 
a few changes compared to 9.11.

One of our support engineers analyzed the differences in options between the 
versions, and wrote this KB article for people migrating: 
https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916 
 .

We also have updated the ‘BIND Significant Features Matrix’ with the major 
feature differences between releases. This is not as detailed as the KB 
mentioned above. https://kb.isc.org/docs/aa-01310 
.  

While we don’t have current performance tests that compare the latest 9.11 
version to the latest 9.16 version, we did quite a bit of performance testing 
on the 9.16 branch in 2021 and we do not expect any loss of performance moving 
from 9.11 to 9.16. (see 
https://www.isc.org/blogs/bind-resolver-performance-july-2021/ 
 for 
performance results for resolver operations) There may be some changes in 
memory utilization, which we have tried to minimize in the latest versions. 
(see https://kb.isc.org/docs/bind-memory-consumption-explained 
 for more details).

For those using the ISC BIND packages:  

Because we are still patching 9.11, and we haven’t yet issued a new development 
branch, we are putting 9.18.0 into the bind-dev repositories, for now.

In April, we plan to do a version rollover:
- bind-esv will go from 9.11 to 9.16
- bind will go from 9.16 to 9.18
- bind-dev will go from 9.18.1 to 9.19.0 

BIND 9.19.0 will be the new development branch.

Regards,

Vicky Risk___
Please 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: 9.11, 9.16 and ESV designation

[Victoria Risk]

Hi John,

> 
> That document was last updated on Jan 5, 2022, so this news is at least three 
> weeks old. I don't recall seeing anything on the "Announce" mailing list 
> regarding the change in ESV designation.

…..
> Nor do I see any difference in the COPR packages:
> 
> https://copr.fedorainfracloud.org/coprs/isc/bind-esv/
> 
> which continue to offer 9.11.
> 
> A) Where was the ESV-switch announced? (I though I had my bases covered by 
> subscribing to 'announce' and 'user' mailing lists. I need to find and plug 
> this communication hole.)

This is my fault. I am sorry. 

I posted a blog last June, in which we declared 9.16 ESV (and started marking 
it that way on the downloads page and in the release notes). 
https://www.isc.org/blogs/bind-update-summer2021/ 


We do try to keep the matrix showing EOL dates current here: 
https://kb.isc.org/docs/aa-00896 , and that 
hasn’t been changed since last summer, when we finally declared 9.16 ESV, 6 
months after the point at which we would normally have done so. 

Normally, we would also send some reminders to the list(s) when we are at T-3 
months from EOL. 2021 was a difficult year in more ways than one, and 
apparently, we didn’t do this. My only excuse, which is a weak one, is that I 
was reluctant to pull the plug on 9.11 until we were more confident that 9.16 
was really solid, so I put it off. However, even though we failed to remind the 
list, we haven’t changed the 9.11 EOL date, it has been set for ages. 

I will send a note to bind-announce pointing out that it is time to move off of 
9.11.

> 
> B) What are the plans for the 'bind-esv' COPR? (Will it soon start serving 
> 9.16? Do I need to manually switch from 'bind-esv' to 'bind'? Is COPR dead?)

Good question. This is admittedly confusing. 

We already have 3 BIND versions in our packages, bind, bind-dev and bind-esv. 
We have just a brief overlap here between 9.11 and 9.18, but we don’t want to 
create yet another repo.  Because we are still patching 9.11, and we haven’t 
yet issued a new dev branch, we are putting 9.18.0 into the bind-dev repo, for 
now.

In April, we plan to do a version rollover:
- bind-esv will go from 9.11 to 9.16
- bind will go from 9.16 to 9.18
- bind-dev will go from 9.18.1 to 9.19.0

I hope this helps.

Regards,

Vicky Risk

___
Please 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: Notice of plan to deprecate map zone file format

[Victoria Risk]

>>> After all the "other improvements in performance" that you cited, what is 
>>> the performance difference between map and the other formats?
>> 
>> I don’t know that, to be honest. We don’t have the resources to benchmark 
>> everything. Maybe someone on this list could?  We would also like to be able 
>> to embark on a wholesale update to the rbtdb next year and this is the sort 
>> of thing that might complicate refactoring unnecessarily. 


I was wrong, and in fact we have benchmarked it. See 
https://gitlab.isc.org/isc-projects/bind9/-/issues/2882 
 for details. Map 
format is still faster than raw, but not so much faster that it warrants 
retaining it, given it is riskier, harder to maintain and we have no feedback 
from users that it is important to them.  It also seems not to work with large 
numbers of zones, (>100K) at least in current versions of 9.11 and 9.16, which 
is further indication that it isn’t in wide use or we would have had 
complaints. 

We also have discussed internally that there are other factors, other than 
loading the zone files, that may have more impact on the time it takes a BIND 
server to restart.

If anyone out there is using it successfully, and wants us to keep this 
feature, this would be the time to speak up!

Thank you,

Vicky___
Please 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: Notice of plan to deprecate map zone file format

[Victoria Risk]

> On Sep 10, 2021, at 7:24 AM, Timothe Litt  wrote:
> 
> Clearly map format solved a big problem for some users.  Asking whether it's 
> OK to drop it with no statement of what those users would give up today is 
> not reasonable.
> 
Actually, we are not sure there ARE any users. In fact, the one example I could 
come up with was Anand, who has replied to the list that he is in fact NOT 
using map zone.  I should have asked directly - is anyone on this list USING 
MAP ZONE format?

> After all the "other improvements in performance" that you cited, what is the 
> performance difference between map and the other formats?

I don’t know that, to be honest. We don’t have the resources to benchmark 
everything. Maybe someone on this list could?  We would also like to be able to 
embark on a wholesale update to the rbtdb next year and this is the sort of 
thing that might complicate refactoring unnecessarily. 
> For a case which took 'several hours' before map was introduced, what would 
> the restart time be for named if raw format was used now?
> 
>> If I knew that I would have said. 'Raw’ was much faster than the text 
>> version. Map was faster than raw. Raw is apparently not a problem to 
>> maintain.  I believe the improvement with raw was ~3x.
>> 

> It's pretty clear to me that if map format saves a few seconds in the worst 
> case, it's not worth keeping.  If it saves hours for large operators, then 
> the alternative isn't adequate.  Maybe "map" isn't the answer - how might 
> 'raw' compare to a tuned database back end?  (Which has other advantages for 
> some.)  What if operators specified a priority order for loading zones?  Or 
> zones were loaded on demand during startup, with low activity zones added as 
> a background task?  Or???

Well, back when we added map zone format, startup time was a major pain point 
for some users. Now, it seems as though large operators are updating their 
zones all the time (also updating RPZ feeds) and efficiency in transfers seems 
to be a bigger issue. 

We don’t have any direct data on what features are being used, we can only 
judge based on complaints we receive via bug tickets or posts on this list. 
> A fair question for users would be what restart times are acceptable for 
> their environment - obviously a function of the number and size/content of 
> zones.  And is a restart "all or nothing", or would some priority/sequencing 
> of zone availability meet requirements?
> 
That is a good question. Can you answer it for yourself?

Thank you!

Vicky


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

Notice of plan to deprecate map zone file format

[Victoria Risk]

Greetings bind-users,

The `map` zone file format was introduced in BIND 9.10. 
https://bind9.readthedocs.io/en/v9_16_20/reference.html?highlight=map%20zone#additional-file-formats
 


At the time, this format significantly sped up a named restart, which could 
take several hours in some situations. This new file format is very 
complicated, and maintaining it has proven difficult. Meanwhile, the 
performance advantage versus the `raw` format, or the default text files, has 
decreased as we have made other improvements in performance. 

We would like to deprecate the `map` zone file format in future branches of 
BIND. The proposal is to deprecate the feature in the 9.16 branch, (users will 
see a warning when this feature is used but it will still work through the end 
of the 9.16 branch), and to disable the feature in 9.20.0 (it will no longer 
work in this and subsequent versions). 

Per our policy on deprecating named options, we are notifying the user mailing 
list.  You are welcome now to howl in protest or point out something we haven’t 
considered.  ;-)

Regards,

Vicky Risk
Product Manager___
Please 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-Forum Link is down

[Victoria Risk]

Hi Harshith,

ISC doesn’t operate Nabble, it is an independent service on the Internet. I was 
notified 2 weeks ago that they are ‘consolidating to a single server', and 
wanted to know if they should move our forum. ("Yes, please!") I think this 
consolidation could be a sign that they may be struggling to support this 
(free) service and you might want to consider reading via the ISC archives at 
https://lists.isc.org/mailman/listinfo/bind-users 
.

For those who didn’t know the Nabble forum existed, it is subscribed to 
bind-users and presents this user group in a forum-type display, in a simple 
GUI that I had embedded on our old web site and which some users subscribe to. 

Vicky


> On Aug 6, 2021, at 3:02 AM, Harshith Mulky  wrote:
> 
> Hi
> 
> I am sorry if this question is posted elsewhere
> But I am not able to access this link
> Bind-Users forum
> http://bind-users-forum.2342410.n4.nabble.com 
> 
> 
> Is it down?
> 
> Thanks
> Concerned user
> ___
> Please 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 
> 
___
Please 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

New BIND releases are available: 9.16.18, and 9.17.15

[Victoria Risk]

Hello BIND-users,

The updated June maintenance releases of BIND 9.16 and 9.17 are available and 
can be downloaded from the ISC software download page, 
https://www.isc.org/download .

These contain the fix for the previously announced “W” typo issue in BIND 
9.16.17 and 9.17.14 (https://gitlab.isc.org/isc-projects/bind9/-/issues/2779 
). 

We delayed announcing these versions while we investigated two other issues, 
GL#2783 (https://gitlab.isc.org/isc-projects/bind9/-/issues/2783 
) and GL#2786 
(https://gitlab.isc.org/isc-projects/bind9/-/issues/2786 
), which are not fixed 
in these versions.  If you are using dnssec-policy with the same zones in 
multiple views (this includes in-view configuration option) and you experience 
deadlocks on startup with 9.16.18, you are advised to downgrade to 9.16.16.
A summary of significant changes in these releases can be found in their 
release notes.
current stable version
  9.16.18  - 
https://downloads.isc.org/isc/bind9/9.16.18/doc/arm/html/notes.html 


experimental development branch:

  9.17.15  - 
https://downloads.isc.org/isc/bind9/9.17.15/doc/arm/html/notes.html 


___
Please 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: A question on logging

[Victoria Risk]

Also…

Logging is the topic most often searched on in our knowledge base. We have one 
article on logging that is read more often than any other, that we are planning 
to migrate to the ARM. 

https://kb.isc.org/docs/aa-01526
That article also references a webinar Carsten Strotmann presented earlier this 
year on how to use and manage logs that I would also recommend. He had a lot of 
practical tips.

Vicky


___
Please 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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported

[Victoria Risk]

> On Jun 2, 2021, at 3:24 PM, Peter via bind-users  
> wrote:
> 
> Well that sucks no more bind for windows...:(

We are supporting BIND 9.16 on Windows, and we are supporting 9.16 through the 
end of 2024, so we are not at the end of the road yet!

https://kb.isc.org/docs/aa-00896

Vicky
___
Please 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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Victoria Risk]

> On Jun 2, 2021, at 1:36 PM, Richard T.A. Neal  wrote:
> 
> Could I ask if a conclusion has been reached regarding this? I know there was 
> quite a bit of chatter in April/May but it's not clear to me whether any 
> conclusions were reached.

We are pretty well decided that we will not support Windows with BIND 9.18.  I 
see Ondrej replied on this point. 

> 
> If 9.16 is to be the last officially supported Windows version then have you 
> decided yet which features from 9.17 will be  backported into 9.16 and thus 
> receive official support?

We are not going to backport more features to 9.16 after this coming June 
release, because the priority is stabilizing 9.16.  We want to declare 9.16 to 
be ‘ESV’ and put it into a more quiescent maintenance mode with the June 
release so users on 9.11 can migrate to 9.16.

> 
> Easy example: DNS over HTTPS which I believe was initially hoped to be 
> backported into BIND 9.16 around the April/May timeframe this year.

We are probably at this point ready to announce that we have decided NOT to 
backport DoH to 9.16. We wanted to first check with our support customers, to 
see what impact this would have on them - but we feel at this point backporting 
DoH to 9.16 is not going to help stabilize 9.16, and 9.18 is not very far in 
the future, so we want to wait until 9.18 for a stable version with DoH in it.  

However, we are also discussing, in response to the discussion here, creating a 
separate image for dig on Windows.  This could be based on 9.17 and therefore 
could include dig for DoH.  This is TBD but it seems like a reasonable 
possibility.  

I hope this is a good compromise. 

Vicky
___
Please 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: Status of zytrax.com "DNS for Rocket Scientists" website

[Victoria Risk]

Ron Aitchinson called me this afternoon. He is fine, and he promised to try to 
resurrect his site. He has been struggling with his hosting provider and he 
said he *might* be looking for new hosting, but he hasn’t thrown in the towel 
yet.  

I will report back if I get further updates. I told him that a lot of users 
still find his site very useful and to let ‘us’ know if he ever plans to pull 
the plug. 

Vicky

> On Apr 19, 2021, at 8:49 AM, Victoria Risk  wrote:
> 
> I will contact Ron and see what is up.
> 
> Thank you for pointing it out Carsten!
> 
> Vicky
> 
>> On Apr 19, 2021, at 7:21 AM, Richard T.A. Neal  
>> wrote:
>> 
>> Carsten Strotmann wrote:
>> 
>>> does anyone know about the status of the zytrax.com website and the 
>>> excellent "DNS for Rocket Scientists" guide?
>> 
>>> The webpage first had a x509 certificate error (expired) in December
>>> 2020 and now the web server is unreachable.
>> 
>>> I (and colleagues) have tried to reach Ron Aitchison by mail and other 
>>> communication means, but no success.
>> 
>> Unfortunately I don't but if anyone is able to make contact with Ron I'd be 
>> very happy to offer to host an archive of the site at no cost.
>> 
>> Best,
>> Richard.
>> 

___
Please 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: Status of zytrax.com "DNS for Rocket Scientists" website

[Victoria Risk]

I will contact Ron and see what is up.

Thank you for pointing it out Carsten!

Vicky

> On Apr 19, 2021, at 7:21 AM, Richard T.A. Neal  
> wrote:
> 
> Carsten Strotmann wrote:
> 
>> does anyone know about the status of the zytrax.com website and the 
>> excellent "DNS for Rocket Scientists" guide?
> 
>> The webpage first had a x509 certificate error (expired) in December
>> 2020 and now the web server is unreachable.
> 
>> I (and colleagues) have tried to reach Ron Aitchison by mail and other 
>> communication means, but no success.
> 
> Unfortunately I don't but if anyone is able to make contact with Ron I'd be 
> very happy to offer to host an archive of the site at no cost.
> 
> Best,
> Richard.
> ___
> Please 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

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

Can you share some real-world queries with ISC?

[Victoria Risk]

Hello again BIND-users,

Sorry for asking for help twice in one day.

We are setting up a new resolver performance test bed, one that we hope will be 
a better simulation of real-world deployment.  Once we have this working, we 
should be able to profile BIND performance using DoH and DoT as well as Do53. 
We are using the DNS Shotgun tool for this purpose. 
(https://dns-shotgun.readthedocs.io/en/stable/ 
)

Anyway, we need to feed this test bed with some PCAPS. We have only a few 
samples right now, and if we could get a few more, our test bed would be more 
representative of the actual Internet.

We don’t want to publish how to upload files to us, because that will 
immediately be filled with spam, so if you are willing to submit some of your 
resolver packet captures, please email me and I will give you instructions on 
where to put your file so that we can retrieve it.  I have included some 
instructions on capturing the packets below so you can see what is involved.

Thank you for considering this.

Vicky
-


If you are able to share some pcaps, here are some generic instructions. 

dnscap \
-z 192.0.2.1 \
-z 2001:db8::1 \
-i any \
-p \
-s i \
-w /output/pcap \
-C 1073741824 \
-k 'xz -9' \
-B '2021-01-08 11:40:00' \
-E '2021-01-08 21:40:00' \
-S \
-6 \
-P /usr/lib/dnscap/anonaes128.so \
-4 \
-K /dev/urandom \
-I /dev/urandom

Explanation:
dnscap - https://www.dns-oarc.net/tools/dnscap 


-z # IP address of the DNS resolver uses to receive client queries, duplicate 
-z if it has more IP addresses - this is crucial to filter queries from BIND 
itself to the Internet

-i any # network interface name receiving client queries ("any" should be fine 
so they do not need to bother with explicit names)

-p # ask for interface not be put into promiscuous mode, it's not needed as we 
capture only the traffic directed to this server

-s i # capture only queries but not answers (thus
making the output file smaller) - has to be combined with -z above

-w # output file name base

-C # maximum individual file size in bytes, 1 GB recommended

-k 'xz -9' # compression command, feel free to change

-B -E # starts/stops capture times, please do not forget to modify

-S # print statistics, optional

-6 # enable IPv6 support, omit for dnscap version 2.0.0 and newer

-P -4 ... # anonymizing IPv6 and also IPv4 addresses using random AES key, i.e. 
key is forgotten when process exits


A good sample size is 10 hours but shorter samples can be also useful, we can 
eventually combine samples from multiple submitters.


Bonus points if we can get the command running in parallel on multiple servers, 
e.g. on 10 servers for 1 hour, or 5 servers for 2 hours, etc.

If running on multiple servers please replace
-K /dev/urandom -I /dev/urandom
with
-k putrandomkeyhere -i putrandomkeyhere
and use the same 16-character string on all servers.

-k -i specify explicit anonymization keys so the same clients are anonymized in 
the same way across all servers. They should not tell us what values they were 
using during capture otherwise we could partially deanonymize the data.___
Please 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

Plan to remove ISC custom SPEGNO from BIND

[Victoria Risk]

Hey there BIND Users-

We have removed the ISC custom SPEGNO implementation from the development 
branch (9.17.x). We intend to also remove it from BIND 9.16 and 9.11. This is 
very old and fragile code and it is provides extra risk for everyone, while 
being useful for (we think) almost nobody.

- First what it is: SPNEGO  is some black 
magic which helps to negotiate how a client authenticates to a server 
(basically find intersection of sets of supported mechanisms on both sides) 
(https://en.wikipedia.org/wiki/SPNEGO 

- Normally it is provided by libraries installed in the operating system, but 
for historical reasons BIND carries its own copy of that library. (back when 
there were more operating systems that didn’t have this support)

- Support for BIND was introduced in 2006, and in the same year support for the 
same was introduced into MIT Kerberos 1.5 
. 
(https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.html 
)

- Systems with the MIT Kerberos library (which is open-source) newer than 15 
years can use that system library version, and ignore whatever BIND ships.

- The MIT Kerberos version has been patched many times over the years while the 
ISC implementation has not been well maintained.

We wouldn’t normally remove something from an old stable extended support 
version (9.11) but since this code seems to be obsolete and risky, we plan to 
do so. If anyone can think of a good reason not to, please let us know asap. SW 
Engineering’s fingers are quivering over the delete key.

Thank you!

Vicky
-
Vicky Risk
Product Manager

___
Please 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 through COPR after CentOS

[Victoria Risk]

> On Dec 18, 2020, at 10:15 AM, John Thurston  wrote:
> 
> We have been using the ISC COPR packages for BIND on CentOS. With the demise 
> of CentOS, we (along with a few other people on the planet) need to consider 
> where we will move our applications.
> 
> We have been completely happy with the packages provided by ISC through COPR. 
> Does anyone want to offer up other linux distributions on which they have had 
> unqualified success with these same packages?



I have been worrying about whether we would see BIND users shift away from 
CentOS, although I think it is too soon to declare CentOS ‘dead’. 

This might be a good time to remind people that we also publish packages for 
Debian (https://packages.debian.org/source/sid/bind9) and Ubuntu 
(https://launchpad.net/~isc). We also maintain a Docker image 
(https://hub.docker.com/r/internetsystemsconsortium/bind9). 

Vicky


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please 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: Catalog zones version 2 support

[Victoria Risk]

> On Nov 10, 2020, at 11:29 PM, Jan Drobil  wrote:
> 
> Hi,
> will BIND support catalog zones version 2 - 
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones-00 ?
> Knot DNS introduces them in version 3 - 
> https://www.knot-dns.cz/docs/3.0/singlehtml/#catalog-zones

Jan,

We have an open ticket for a Catalog Zones update 
(https://gitlab.isc.org/isc-projects/bind9/-/issues/987) but nobody has so far 
upvoted it or commented asking for it. If you want it I would encourage you to 
comment on the Gitlab issue to raise the priority. 

Regards,

Vicky Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please 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: forwarders used in order or based on RTT ?

[Victoria Risk]

The ARM was updated in 9.16.6.  Sorry it took us so long!

from https://gitlab.isc.org/isc-projects/bind9/-/issues/2030
Forwarders are typically used when an administrator does not wish for
all the servers at a given site to interact directly with the rest of
the Internet. For example, a common scenario is when multiple internal
DNS servers are behind an Internet firewall. Servers behind the firewall
forward their requests to the server with external access, which queries
Internet DNS servers on the internal servers' behalf.

Another scenario (largely now superseded by Response Policy Zones) is to
send queries first to a custom server for RBL processing before
forwarding them to the wider Internet.

There may be one or more forwarders in a given setup. The order in which
the forwarders are listed in ``named.conf`` does not determine the
sequence in which they are queried; rather, ``named`` uses the response
times from previous queries to select the server that is likely to
respond the most quickly. A server that has not yet been queried is
given an initial small random response time to ensure that it is tried
at least once. Dynamic adjustment of the recorded response times ensures
that all forwarders are queried, even those with slower response times.
This permits changes in behavior based on server responsiveness.

Vicky
___
Please 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

ISC is looking for dns geeks

[Victoria Risk]

Hello BIND-users,

We have two full-time job openings at ISC. We are so busy these days, we are 
adding another customer support engineer, and another developer to the BIND 
development team. 

Those of you on this list know better than anyone how challenging, and 
satisfying, it can be to solve DNS problems. Both of these positions will be 
helping other open source users maintain stable and successful DNS services 
using BIND.  To view the job descriptions and or to apply, see 
https://isc.recruitee.com/

Both of these are 100% remote working jobs, with some requirement to travel for 
infrequent team meetings once the pandemic is over. We insist that you have 
excellent Internet access, but otherwise we are quite flexible.  Neither of 
these jobs is easy, but ISC is a supportive, ethical employer and you will have 
a good group of colleagues. We warmly welcome applicants from non-traditional 
backgrounds. 

Please don't apply by replying to this message! Feel free to email me directly 
if you have questions, else go directly to https://isc.recruitee.com/

Thank you!!

Vicky Risk
___
Please 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

Upcoming talk on VinylDNS

[Victoria Risk]

Back in June I posted a Doodle poll here asking about interest in webinars on 
DNS zone management tools. The topic that got the most votes was VinylDNS, a 
project Comcast has sponsored and open-sourced. 
https://github.com/VinylDNS/vinyldns <https://github.com/VinylDNS/vinyldns> is 
Apache-licensed, with an active team of 5 core maintainers. It is a relatively 
substantial zone provisioning system, with a zone database and a GUI portal.

We have scheduled the talk for October 7th, a Wednesday, at 17:00 UTC. (It will 
be recorded and the recording posted on ISC’s YouTube channel.)  To register, 
go to: https://us02web.zoom.us/webinar/register/WN_xTx3UnnBSLaMwpY5MXWnag

Joe Crowe, Senior DNS/Network Engineer at Comcast and Paul Cleary, Principal 
Software Engineer for the VinylDNS system will give the talk jointly. They have 
promised mini-demos illustrating key features. 

——
Two other tools I would still like to get presentations on are:
OctoDNS - maintained by Github. Manages zonefiles across multiple DNS 
providers. (https://github.com/github/octodns 
<https://github.com/github/octodns>)

DNS Control - maintained by Stack Exchange. Manages zonefiles across multiple 
DNS providers (https://stackexchange.github.io/dnscontrol/ 
<https://stackexchange.github.io/dnscontrol/>)


Vicky

Victoria Risk
Product Manager
Internet Systems Consortium
vicky at isc.org <https://lists.isc.org/mailman/listinfo/bind-users>


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

Help us weed out the old crap in the ISC KB

[Victoria Risk]

BIND-users,

I am doing a review of the older articles in our Knowledgebase, updating those 
I can and unpublishing those I cannot update. I am sure everything in there was 
accurate when it was written, but of course the software, and the overall 
Internet, have evolved. I found articles in there that were last updated in 
2011, yet some of them still seem useful, and articles from much more recently 
that are so out of date as to be misleading to current users.

However, I am really not a BIND-user and I need help from actual users. If you 
have a little time to spare, consider reading an article and rendering your 
opinion on whether to keep or discard it.

I have made a list of articles in a Google sheet, ordered from oldest to 
newest, with a url link to the article. There is a column to pick one of a few 
review comments:

keep - confirmed accurate
keep - looks useful but not verified
keep - with minor updates in the comments
discard - inaccurate
discard - obsolete

The reason I have included several variations on ”Keep" is just in case you 
want to indicate a lower confidence in the ‘keep’ decision.  I realize this is 
a pretty unsophisticated review process, but IMHO it is better than nothing. 
Our current KB implementation isn’t amenable to community editing, so if anyone 
wants to volunteer more extensive edits to an article, email me the diff and I 
will apply it. 

Here is the Google sheet with the list of articles:

https://docs.google.com/spreadsheets/d/1yn1XjbY6SMwfDuON2aCwRBOsHlcFU5W6QmTqWqcicpc/edit?usp=sharing
 
<https://docs.google.com/spreadsheets/d/1yn1XjbY6SMwfDuON2aCwRBOsHlcFU5W6QmTqWqcicpc/edit?usp=sharing>

Just look for an article with nothing in the Review column. Please provide an 
email address if you are giving substantive comments I might need to 
subsequently clarify with you.

Thank you for your contributions.

Vicky

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please 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: distribution of Bind software through our website

[Victoria Risk]

Hi Shubham,

As Michael said, BIND is open source and as long as you comply with the MPL 2.0 
license, you can redistribute it freely. We do have a ‘current’ directory at 
https://ftp.isc.org/isc/bind9/cur/ <https://ftp.isc.org/isc/bind9/cur/>, you 
might want to just mirror that. We would prefer if you didn’t redistribute the 
end-of-life ancient versions that we are no longer maintaining.

The text of the MPL2.0 license is here: https://www.mozilla.org/en-US/MPL/2.0/

Vicky

> On Aug 24, 2020, at 5:36 AM, Michael De Roover  wrote:
> 
> The BIND software is released under the Mozilla Public License 2.0. You can 
> refer to the LICENSE file to learn about your rights in BIND or most other 
> open source projects. The only exception to my knowledge would be projects 
> with no license - those are all rights reserved by default to protect authors 
> who do not wish to grant additional rights for their software.
> 
> I'm also hosting a mirror of BIND at git.ghnou.su/mir/bind 
> <https://git.ghnou.su/mir/bind> without issues.
> 
> 

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





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

Request for review of performance advice

[Victoria Risk]

 general, more 
smaller RPZ zones will transfer faster than a few very large RPZ zones. 

4f) Consider enabling prefetch on your resolver, unless you are running 9.10 
(which is EOL) https://kb.isc.org/docs/aa-01122 
<https://kb.isc.org/docs/aa-01122>

Fix your transport network. 
Transport network issues cause BIND to keep retrying, which is a performance 
drain.
4a) Disable (in some cases, completely remove in order to prevent ongoing 
interference) outbound firewalls/packet-filters (particularly that maintain 
state on connections). These are a frequent cause of problems in the DNS that 
can cause your DNS server to do a lot of extra work. 

4b) Set an appropriate MTU for your network. Ensure that your network 
infrastructure supports EDNS and large UDP responses up to 4096. Ensure that 
your network infrastructure allows transit for and reassembly of fragmented UDP 
packets (these will be large query responses if you are DNSSEC signing)

4c) Ensure that your network infrastructure allows DNS over TCP.

4d) Check for, and eliminate any incomplete IPv6 interface set-up (what can go 
wrong here is that BIND thinks that it can use IPv6 authoritative servers, but 
actually the sends silently fail, leaving named waiting unnecessarily for 
responses)

Any further suggestions, corrections or warnings are very welcome. 

Thank you!
Vicky

-

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please 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: Latest BIND ARM is missing from docs page?

[Victoria Risk]

> On Jun 15, 2020, at 3:24 PM, Brett Delmage  wrote:
> 
> On Mon, 15 Jun 2020, Evan Hunt wrote:
> 
>> On Sun, Jun 14, 2020 at 06:38:38PM -0400, Brett Delmage wrote:
>>> Is this ARM the most recent version?
>> 
>> No, the current stable release is 9.16. The "primary" and "secondary"
>> keywords were added in 9.12.
> 
> Then is the ISC ARM directory page https://kb.isc.org/docs/aa-01031 outdated? 
> The most recent version listed here is 9.14 - which is now EOL according to 
> your own page at https://www.isc.org/bind/


Brett,

Thank you for pointing this out. We seem to have forgotten to update the ARMs 
in the Knowledgebase. I know why this is - we thought that we would be entirely 
migrated to the ReadTheDocs.io on-line docs by 9.16.0, but we hadn’t. In any 
case, I updated the main ‘about the BIND documentation’ article, and added 
another one with links to the 9.16 ARMs. They are always available on our ftp 
server in the directory with the BIND source (ex 
https://ftp.isc.org/isc/bind9/9.16.3/doc/).

Vicky


___
Please 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 Masters and slaves

[Victoria Risk]

We have decided to put the list into general moderation because it feels like 
there is nothing substantive to add on this topic and it seems like we might 
benefit from a cooling off period before anyone gets more upset. We will push 
through any posts on any other topic (about BIND anyway), and will remove the 
moderation flag in a day or two.

If anyone wants to object, they can email me directly, or just mail to the list 
and I will see it even if it isn’t posted. 

Vicky
___
Please 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 Masters and slaves

[Victoria Risk]

Wow. This topic has generated a lot of comment. 

We at ISC decided in 2017 to provide aliases for the master/slave terminology 
in BIND so users who don’t wish to use those terms don’t have to.  It was not a 
burden to make this change in the source code. 

Back when we made that initial change, I personally received several private 
emails from actual BIND users who had felt triggered, offended or otherwise 
distracted by the master/slave terminology, thanking us for making this change. 
 If even one or two users were upset by the old terms, that is enough, and 
surely there are more users who were impacted who didn’t speak up.  

We are now in the process of updating the terminology used in the BIND ARM. 
These edits are in review now (along with many other updates to the ARM.)

At the time we made the initial change we didn’t have a process for removing 
obsolete features so we just added an alias. Now that we do(1), we would like 
to implement that process to gradually deprecate the master/slave terms in 
favor of primary/secondary.  We would introduce a warning in 9.18, mark the old 
terms as deprecated in 9.20, and remove them in 9.21 (development branch). So, 
the master/slave terms will still work in the 9.20 Extended Support Version 
through its lifetime, which ends at the end of 2025. This constitutes an 8-year 
period for this change, which should be enough for even the most change-averse 
among us to adapt. 

We are trying to ensure that this project is as inclusive as possible. BIND and 
the DNS are complicated enough without adding additional barriers. This seems 
like a reasonable accommodation. If this change (over the next 6 years) will 
cause you a signficant problem, please say so, but we don’t need to continue 
discussing whether it is worth the effort any more, because we are already 
convinced it is worth the effort on our part. 

Vicky Risk


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org

(1) https://kb.isc.org/docs/policy-for-removing-namedconf-options



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

Interest in a webinar on any of these DNS mgmt tools?

[Victoria Risk]

There are a number of open source tools for managing BIND zonefiles. The three 
below (at least) seem currently maintained and popular.  Is there interest in a 
presentation on any of these? If there seems to be interest, I would be willing 
to try to recruit someone who is either a member of the core team developing 
the tool, or perhaps an operator/user of the tool (if those are different) to 
give a webinar.

VinylDNS - created and used by Comcast. https://github.com/VinylDNS/vinyldns

OctoDNS - maintained by Github. Manages zonefiles across multiple DNS 
providers. (https://github.com/github/octodns)

DNS Control - maintained by Stack Exchange. Manages zonefiles across multiple 
DNS providers (https://stackexchange.github.io/dnscontrol/)

Reply on this Doodle poll - https://doodle.com/poll/i8vf3tmi6p5ity6q or email 
me directly if you have other suggestions/requests.


Thanks,

Vicky

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please 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: DoH plugin for BIND

[Victoria Risk]

> On Apr 29, 2020, at 11:06 AM, Michael De Roover  wrote:
> 
> On that subject, how about DoT? I have mixed feelings about using 443 as a 
> kitchen sink port but encrypting DNS seems like a good idea.

We are planning to have DoT on the same timeline as DOH, so nobody has to 
choose one or the other based on availability.

> 
> On 4/29/20 9:40 AM, Evan Hunt wrote:
>>> Does BIND have a DoH plugin official?
>>> Or is there any guide to customize that one?
>> Not yet, but we plan to have a DoH implementation in named by the end of
>> this year.
>> 
>> In the meantime, there are DoH proxies that can run BIND as the back-end.
>> 
> -- 
> Met vriendelijke groet / Best regards,
> Michael De Roover
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-lookaside auto key expiration

[Victoria Risk]

We apparently let our signatures on dlv.isc.org expire. We are fixing it now. 
We apologize for this.

This was an accident - we did *not* do this on purpose - but infact, this is a 
good time for anyone who still has dlv.isc.org configured to REMOVE it from 
your BIND configuration. The zone is empty, lookups to the zone do nothing 
beneficial, and as has just been demonstrated, when the zone is bogus, it can 
have a negative impact.

I expect we will have some message here or on Twitter when the issue is finally 
resolved, but I don’t want to interrupt the person who is currently working on 
fixing it. 

As we are removing other obsolete features, we are tracking them along with the 
newly added features on the BIND Significant Features Matrix. 
https://kb.isc.org/docs/aa-01310  The DLV was actually removed from 9.16 so as 
later versions are adopted, it will no longer even be possible to run named 
with the dlv configured. 

Vicky Risk


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Advice on balancing web traffic using geoip ACls

[Victoria Risk]

> On Feb 23, 2020, at 6:57 AM, @lbutlr  wrote:
> 
> On 22 Feb 2020, at 18:25, Scott A. Wozny  wrote:
>> I’m setting up hot-hot webserver clusters hosted on the west and east coasts 
>> of the US and would like to use Bind 9.11.4
> 
> I’d consider changing that version. While Bind 9.11 *is* still supported, it 
> is EOL at the end of this year. If you really really want to run 9.11, at 
> least run the latest patch level (9.11.6 should be coming really soon).

We will continue with security patches for 9.11 through the end of 2021, so 
9.11 is not a bad choice for someone who doesn’t want to migrate for a long 
time. 

> 
> 9.14.10 is the current stable release and 9.11.15 is the current extended 
> support release. Unless you know something is broken in 9.14.10 (unlikely) 
> that would be the version to look at.

9.14 has just been replaced by 9.16, released just this past week. We will 
continue offering security releases for 9.14 for a 3-month period to support 
migration to 9.16. Someone doing a migration today should look at 9.16 rather 
than 9.14.


> You absolutely should not be running a bind version several years old, as 
> 9.11.4 is.
> 

agreed


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OT: Reminder: DNSSEC series starts in 1 day

[Victoria Risk]

Sorry, I hadn’t done a series of webinars before and hadn’t realized the 
constant reminders are the default setting. I just turned them off. Thank you 
for letting us know these are annoying.

Vicky

> On Feb 11, 2020, at 10:32 AM, Jim Popovitch via bind-users 
>  wrote:
> 
> First, I love it that ISC does these informative sessions.
> 
> However, why send out iCal/Calendar instructions AND then send me emails
> 1 day and 1 hour before each session?
> 
> I don't want to cancel my registration, but I do want to cancel the
> constant email reminders.  Help!
> 
> -Jim P.
> 
>  Forwarded Message 
> From: Vicky Risk 
> Reply-To: no-re...@zoom.us
> To: Jim Popovitch 
> Subject: Reminder: DNSSEC series starts in 1 day
> Date: Tue, 11 Feb 2020 18:14:12 +
> 
>   
>
> Hi Jim Popovitch, 
> 
> This is a reminder that "DNSSEC series" will begin in 1 day on:
> Date Time: Feb 12, 2020 10:00 AM Pacific Time (US and Canada) 
> 
> Join from a PC, Mac, iPad, iPhone or Android device: 
> Click Here to Join 
> Note: This link should not be shared with others; it is unique to you.
> Add to Calendar   Add to Google Calendar   Add to Yahoo Calendar  
> 
> 
> 
> You can cancel your registration at any time.
> 
>
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inquiry re: DNS over HTTPS

[Victoria Risk]

> On Nov 4, 2019, at 10:38 AM, LeBlanc, Daniel James 
>  wrote:
> 
> Hello All.
>  
> I am interested in whether ISC BIND intends to directly support DNS over 
> HTTPS in the near future, or whether it is expected that users will create an 
> environment to accept the HTTPS request and convert it into a DNS query.

Daniel,

We do plan to develop support for both DoH and DoT (DNS over TLS) natively in 
BIND. Both will appear in development releases in 2020. We have a kb article 
that explains one way to do DoT today with stunnel 
https://kb.isc.org/docs/aa-01386.  

Vicky Risk
Product Manager

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CloudSmith repository missing

[Victoria Risk]

Matt,

We have a stable set of packages now. I just published a Knowledgebase article 
on our packages which we are committed to keeping up to date.

https://kb.isc.org/docs/isc-packages-for-bind-9 


Vicky


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RHEL, Centos, Fedora rpm 9.14.6

[Victoria Risk]

> On Sep 30, 2019, at 7:08 AM, Lightner, Jeffrey  
> wrote:
> 
> I can't speak for him but will say Carl has been providing these packages and 
> announcing them on this list for quite some time now and it is valuable to 
> those who would like to use later upstream packages on RHEL/CentOS/Fedora.
> 

I would like to add that ISC very much appreciates Carl’s work over the years 
packaging BIND for CentOS users. He has been meticulous about updating his 
packages promptly every time we have a CVE and I expect quite a few users have 
come to rely on his packages. ISC only recently began providing packages.  I 
reached out to Carl at the time we were planning the ISC packages for advice, 
because of his experience. 


> What's the purpose with these builds, what problems do they solve which are 
> unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS
> ) and why announcing you are building it and how long are you intending to 
> supporting those builds ( encase someone decides to use those builds instead 
> of ISC or downstream distribution maintained ones )?

The ISC packages are different from Carl’s CentOS package and the official 
RedHat packages in several ways:
- the ISC packages start from the ISC tarball, and do not incorporate any 
additional downstream RedHat bug fixes.  (I believe Carl’s packages are also 
built this way.)  ISC can’t support the RedHat packages because they have 
different code, and different bugs from the official ISC releases. 
- the ISC packages provide the most up to date BIND versions. The RedHat 
support policy does not allow them to update applications in a stable OS 
branch.  This is why they cherry-pick things to backport, as Jeffrey explained, 
but this approach has its limits. (Carl’s packages are up to date, of course.)
- the ISC packages specifically incorporate the additional dependencies 
required to enable dnstap support. (I don’t know whether Carl’s packages 
incorporate this or not)

ISC also has respect for and a good relationship with the RedHat team that 
maintains BIND in the RedHat distribution. We each have our own user base we 
are responsible for, and we each have different policies about what sort of 
changes we allow in a stable branch. It is a good thing there are several 
distributions to choose from when deciding on a BIND package.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Status of experimental COPR packages

[Victoria Risk]

>> We did recently start setting up another site, Cloudsmith.io, for
>> some of our packages. We need a site we can control for non-public
>> stuff, like the BIND subscription edition, and private patches, and
>> Cloudsmith allows us to put packages for multiple different OSes in
>> one repo.  I need to find out whether we plan to continue updating
>> the COPR site or not.  I think we do,(because of course it is easier
>> to ‘find’ than Cloudsmith) but we haven’t discussed it explicitly.
> 
> Which makes it sound like the future of the COPR distribution isn't yet 
> clear. This is a pretty important topic to us, and I'd welcome any 
> information you can offer. I'm not trying to drive your product offerings, 
> just trying to divine which way the wind is blowing.
> 
> From my perspective, I'm quite pleased with how the COPR distribution is 
> working out. It was only a little bit of work to make the "software 
> collection" concept meet our needs, and I'd dearly like to be able to 
> consider it stable.


Thanks for that feedback. I have a clarification. 

ISC plans to continue updating the ISC BIND 9 packages on COPR and Launchpad 
for the forseeable future. You should consider those to be stable and 
non-experimental. 

We are ALSO putting packages for Debian up on Cloudsmith.io, because Debian 
doesn’t provide a repo like COPR or Launchpad for projects to update their own 
packages. The ISC Debian packages on Cloudsmith.io use the same configuration 
as the official Debian packages, but are updated more frequently than the 
official Debian packages.  So, if you are looking for fresher Debian packages, 
or for packages for the development and current stable branches of BIND 9, you 
might try the ones on Cloudsmith. (https://cloudsmith.io/~isc/repos/)


Vicky
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Status of experimental COPR packages

[Victoria Risk]

> On Sep 6, 2019, at 10:18 AM, John Thurston  wrote:
> 
> Back in Sept, 2018 we got word of packages published by ISC for a few common 
> linux distributions.
>  https://www.isc.org/blogs/bind-9-packages/
> 
> There have been a couple of trickles of news on this mailing list since then. 
> I'm interested in the prospects, plans, etc for these packages.
> 
> I really like what I'm seeing with the COPR distribution:
>  https://copr.fedorainfracloud.org/coprs/isc/
> The description there still states "..USE AT YOUR OWN RISK.”

John- Do you still see those messages? I don’t see them. I thought I removed 
all those comments about ‘experimental’ and ‘use at your own risk’ a while ago. 


> I see the August update to 9.11.10 is available there.
> Where do I go to learn the planned path for this?
> 
> Are there plans to stabilize it?
> Are there outstanding feature requests to be addressed?
> Is there a timeline somewhere?

The reason these were marked as experimental was, we were waiting to get more 
feedback from users. It seems as if we aren’t going to get any, which is why I 
reventually removed those comments. 

The main package ‘feature’ we were trying to implement, was support for the 
software collections approach to managing dependencies (we have quite a few due 
to wanting to provide support for DNSTAP). That work is finished, and i am not 
aware of any other ‘outstanding feature requests.’   So I think the packages 
are pretty stable.

We did recently start setting up another site, Cloudsmith.io, for some of our 
packages. We need a site we can control for non-public stuff, like the BIND 
subscription edition, and private patches, and Cloudsmith allows us to put 
packages for multiple different OSes in one repo.  I need to find out whether 
we plan to continue updating the COPR site or not.  I think we do,(because of 
course it is easier to ‘find’ than Cloudsmith) but we haven’t discussed it 
explicitly.

I should have a more complete answer next week - the people working on this are 
already on their weekend. 

Vicky

> 
> -- 
>   Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Explicit Code of Conduct for this list established

[Victoria Risk]

Hey there BIND-users,

A few weeks ago I posted a message here asking for feedback about establishing 
some sort of guideline for behavior on this list. I suggested an email sent by 
Cathy Almond of ISC Technical support to this list a few years ago, asking for 
civility and patience.

A few people replied on-list, and several also replied directly to me. People 
expressed sadness that such a thing was necessary, but nobody voiced an 
objection. The upshot is, we have decided to adopt a formal Code of Conduct for 
this list, as well as for discussions on the BIND 9 Gitlab project site.  We 
looked at several well-known statements from other open source projects, and 
selected the one the Django project uses as our baseline. We have adapted it 
slightly and posted it in the BIND 9 Gitlab 
(https://gitlab.isc.org/isc-projects/bind9/blob/master/CODE_OF_CONDUCT.md 
). I 
will also put a link to it in the information about this list on 
https://lists.isc.org/mailman/admin/bind-users/general 
.  

We also added a page to our web site on how to report violations of the Code of 
Conduct (https://www.isc.org/conductreporting/ 
). I hope we never have to use it, but 
we now have an explicit policy to refer to when moderating this list.

Regards,

Vicky Risk
Product Manager
Internet Systems Consortium
vi...@isc.org
———

Text added to Information on this list:

This list is provided for the purpose of discussing the deployment and usage of 
BIND DNS software. Developers and contributors may solicit input from users 
here and users are welcome to ask for, and give help and advice here.

Participation on this list is governed by a Code of Conduct 
(https://gitlab.isc.org/isc-projects/bind9/blob/master/CODE_OF_CONDUCT.md 
). If 
you believe that you are the target of behavior in violation of the Code of 
Conduct, please alert the list administrators rather than retaliating on the 
mailing list. Report these concerns to cond...@isc.org 
. Insulting and derogatory posts will not be tolerated 
and will result in future posts from those list members who are posting in this 
manner being held for moderation or suspended indefinitely from this community.

We should like to remind list users that irrespective of the basic levels of 
experience or knowledge of some of the posters here, that they are asking for 
community help and that advice should be given politely and with respect shown 
both towards the original poster and other contributors to a thread.

Please remember that:

- English is not the first language for all - this can lead to misunderstandings

- Beginners don't always 'get it' from the start (but with gentle guidance may 
become the experts of the future.)

- If you are seeking help debugging an active issue, don’t alter the domain 
name so that people can query it in order to advise you. This tends to 
frustrate your intended helpers. 






___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Proposal to adopt a Code of Conduct for the list

[Victoria Risk]

This list is a tremendously helpful and generous group that has provided really 
invaluable assistance to many new and experienced users.  I would like to thank 
all of you who share your time and expertise with random users on the Internet, 
as well as giving feedback to ISC via this list.

We had some discussion within ISC and there are mixed opinions about the need 
for and utility of adopting a Code of Conduct (CoC) to ensure that this list 
remains welcoming, useful and tolerant.  We have considered statements used by 
other projects, lists and open source communities. We agreed that I would begin 
by reiterating a statement posted on this list back in 2016, asking for respect 
and civility, to see what people think of that as a code of conduct for this 
list. 

Here it is:

https://lists.isc.org/pipermail/bind-users/2016-October/097925.html 
<https://lists.isc.org/pipermail/bind-users/2016-October/097925.html>
We should like to remind list users that irrespective of the basic
levels of experience or knowledge of some of the posters here, that they
are asking for community help and that advice should be given politely
and with respect shown both towards the original poster and other
contributors to a thread.

The same courtesy and respect is also expected of list members towards
others when discussing more advanced and complex topics.  Please
remember that:

- English is not the first language for all - this can lead to
misunderstandings

- Beginners don't always 'get it' from the start (but with gentle
guidance may become the experts of the future and surprise us all)

If you disagree with another poster on a technical matter, please
explain your position clearly, thoughtfully, and with appropriate
support for your viewpoint.

If you believe that you are the target of an insulting or inappropriate
post, please alert the list administrators* rather than retaliating on
the mailing list.

If you have any other concerns about a poster, please bring them to the
attention of the list administrators.

Insulting and derogatory posts will not be tolerated and will result in
future posts from those list members who are posting in this manner
being held for moderation or suspended indefinitely from this community.

Cathy Almond
ISC Support
* contact the list administrators directly by emailing to 
bind-users-ow...@lists.isc.org <mailto:bind-users-ow...@lists.isc.org>

--
Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org <mailto:vi...@isc.org>


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 9.14.0 filter-aaaa

[Victoria Risk]

Sorry Carl,

I see you ARE trying to use the new syntax. I saw filter- and kind of 
skipped over the rest… I was so excited that finally I thought I could answer 
something, but, it was the *wrong* answer!

Vicky

> On Apr 15, 2019, at 10:49 AM, Victoria Risk  wrote:
> 
>> On Apr 14, 2019, at 5:35 PM, Carl Byington via bind-users 
>> mailto:bind-users@lists.isc.org>> wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> view "normal" {
>>plugin query "filter-.so" {
>>filter--on-v4 yes;
>>filter- { "brokenv6"; };
>>};
>> 
>> 
>> named-checkconf likes that, but named gets a segfault in filter-.so.
>> Anyone using filter-.so in a working configuation? The log shows:
>> 
> 
> Hi Carl,
> 
> I think I know what the problem is. We added a new ‘feature’ in BIND 9.14.0, 
> support for plug-in modules to modify query processing. The first module we 
> created was to support the filter- function.
> 
> As a result, you have to change the syntax for configuring this feature. This 
> was release-noted, but I see it was not clearly stated in the release note 
> that this is a non-backwards compatible change, and requires a configuration 
> update.  






___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 9.14.0 filter-aaaa

[Victoria Risk]

> On Apr 14, 2019, at 5:35 PM, Carl Byington via bind-users 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> view "normal" {
>plugin query "filter-.so" {
>filter--on-v4 yes;
>filter- { "brokenv6"; };
>};
> 
> 
> named-checkconf likes that, but named gets a segfault in filter-.so.
> Anyone using filter-.so in a working configuation? The log shows:
> 

Hi Carl,

I think I know what the problem is. We added a new ‘feature’ in BIND 9.14.0, 
support for plug-in modules to modify query processing. The first module we 
created was to support the filter- function.

As a result, you have to change the syntax for configuring this feature. This 
was release-noted, but I see it was not clearly stated in the release note that 
this is a non-backwards compatible change, and requires a configuration update. 
 

5106.   [experimental]  A new "plugin" mechanism has been added to allow
extension of query processing functionality through
the use of dynamically loadable libraries. A
"filter-.so" plugin has been implemented,
replacing the filter- feature that was formerly
implemented as a native part of BIND.

The "filter-", "filter--on-v4" and
"filter--on-v6" options can no longer be
configured using native named.conf syntax. However,
loading the filter-.so plugin and setting its
parameters provides identical functionality.

Note that the plugin API is a work in progress and
is likely to evolve as further plugins are
implemented. [GL #15]
From the ARM:
DESCRIPTION

filter-.so is a query plugin module for named, enabling named to omit some 
IPv6 addresses when responding to clients.

Until BIND 9.12, this feature was implemented natively in named and enabled 
with the filter-  ACL and the filter--on-v4 and filter--on-v6 
options. These options are now depre- cated in named.conf, but can be passed as 
parameters to the filter-.so plugin, for example:

This module is intended to aid transition from IPv4 to IPv6 by withholding IPv6 
addresses from DNS clients which are not connected to the IPv6 Internet, when 
the name being looked up has an IPv4 address available. Use of this module is 
not recommended unless absolutely necessary.

Note: This mechanism can erroneously cause other servers not to give  
records to their clients. If a recursing server with both IPv6 and IPv4 network 
connections queries an authori- tative server using this mechanism via IPv4, it 
will be denied  records even if its client is using IPv6.

OPTIONS

filter-

Specifies a list of client addresses for which  filtering is to be applied. 
The default is any.

filter--on-v4
If set to yes, the DNS client is at an IPv4 address, in filter-, and if the 
response does not include DNSSEC signatures, then all  records are deleted 
from the response. This filtering applies to all responses and not only 
authoritative responses.

If set to break-dnssec, then  records are deleted even when DNSSEC is 
enabled. As suggested by the name, this causes the response to fail to verify, 
because the DNSSEC protocol is designed to detect deletions.

This mechanism can erroneously cause other servers not to give  records to 
their clients. A recursing server with both IPv6 and IPv4 network connections 
that queries an authoritative server using this mechanism via IPv4 will be 
denied  records even if its client is using IPv6.

filter--on-v6
Identical to filter--on-v4, except it filters  responses to queries 
from IPv6 clients instead of IPv4 clients. To filter all responses, set both 
options to yes. 



Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Victoria Risk]

Regarding allow-update:

- We do try to avoid ‘breaking existing deployments’ with this sort of change. 
We do also have to balance maintaining existing deployments with making 
improvements in security and usability. 

- When we ‘clarified’ behavior of BIND in 9.13.5 preventing the use of 
allow-update as an inherited option, apparently it was not entirely clear from 
code examination what the current behavior was.  Therefore, we made a more 
invasive change than we would normally make on purpose, without a fair amount 
of public notice, and possibly even some sort of open poll.

- We had no idea how common a configuration leveraging the inherited 
allow-update might be among users that we have no direct support relationship 
with. We have heard from several of you that this is an important feature for 
you:  I think we were surprised at this. Thank you for the feedback. This is 
the purpose of having development releases, so that early adopters can try 
upcoming changes and give us feedback. 

- We have decided to treat this change as a regression bug, and to fix it in 
9.14.1.  Alan argued that we should hold 9.14.0 and fix it there: however we 
have decided to go ahead with 9.14.0 with the change we already made in 
allow-update, which we will highlight in the release notes as a ‘known issue'.  
People who rely on a global-allow-update will simply have to wait for 9.14.1 
where we will attempt to restore the prior behavior.   This is not a ’neat’ 
resolution, as it violates our normal policy of not changing configuration 
defaults in the middle of a stable branch, but it should be an adequate 
solution. 

- Reasonable people (some of my colleagues at ISC) feel that users may 
’self-foot-shoot’ with an inherited allow-update, and that the inherited 
behavior may not be obvious (similar options such as update-policy are not 
inherited). At ISC we hear not infrequently from people who have inherited a 
BIND implementation after the original administrator left, and they are 
maintaining a configuration they don’t understand. This experience, coupled 
with a generally increasing concern about DNS security makes a reasonable 
argument for limiting opportunities to ‘accidentally’ allow updates when adding 
new zones. 

We may still implement this or a similar change in the future, but only after 
more discussion and communication and advance warning.  We have noted the 
suggestions for some sort of zone templating, and for a log of the full zone 
configuration, reflecting inherited options as well as explicitly configured 
options. 

Regards,

Vicky Risk
Product Manager for BIND


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS flag day

[Victoria Risk]

> On Jan 18, 2019, at 9:18 AM, Ben Croswell  wrote:
> 
> I shouldn't have posted so closely to responding to the other user.

Oh, my mistake.  How is this for a definitve statement?

BIND 9 was designed to be EDNS compliant from very beginning. All 
currently-supported branches of BIND 9 are EDNS-compliant. That includes 9.11, 
9.12 and 9.13.  We strongly advise running a version supported by ISC or the 
vendor as there could be bugs related to EDNS in earlier versions.

I realize a lot of ppl on bind-users are running eol versions anyway. 
We did poke around a bit here, and found we fixed some minor EDNS issue with 
change #3949 in 2014. That was also about the time we added dig +ednsopt. I 
don’t know what the issue was or if it is significant, but I am sure that any 
version issued since 2014 would be compliant vs the ednscomp tool.

 
> 
> I am not running 9.8. I was replying to them about firewalls in regards to 
> their 9.8 issues.
> 
> Was just hoping for a statement of 9.x or greater supports the needed badvers 
> signaling etc.
> 
> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk  <mailto:vi...@isc.org> wrote:
> 
>> On Jan 18, 2019, at 9:09 AM, Ben Croswell > <mailto:ben.crosw...@gmail.com>> wrote:
>> 
>> Has ISC released minimum viable BIND version for flag day?
> 
> Most versions of BIND authoritative servers, going back years, are EDNS 
> compatible. Certainly ALL currently supported versions are compatible. I see 
> you are running 9.8, which has been EOL since September, 2014.  I think that 
> is probably fine, as far as EDNS, however.
> 
> The change in BIND related to DNS Flag Day is removing workarounds from 
> resolvers, that will retry without EDNS or otherwise try to proceed even when 
> EDNS fails. This change came in the BIND 9.13 development version, and will 
> be in BIND 9.14, which is not yet released.
> 
> The problem you are seeing is most likely firewall-related.
> 
> Vicky
> 
>> 
>> I looked around and couldn't find anything. 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
>> <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe from this 
>> list
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/bind-users 
>> <https://lists.isc.org/mailman/listinfo/bind-users>
> 
> 
> _______
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS flag day

[Victoria Risk]

> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
> 
> Has ISC released minimum viable BIND version for flag day?

Most versions of BIND authoritative servers, going back years, are EDNS 
compatible. Certainly ALL currently supported versions are compatible. I see 
you are running 9.8, which has been EOL since September, 2014.  I think that is 
probably fine, as far as EDNS, however.

The change in BIND related to DNS Flag Day is removing workarounds from 
resolvers, that will retry without EDNS or otherwise try to proceed even when 
EDNS fails. This change came in the BIND 9.13 development version, and will be 
in BIND 9.14, which is not yet released.

The problem you are seeing is most likely firewall-related.

Vicky

> 
> I looked around and couldn't find anything. 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNSSEC Negative Trust Anchor report

[Victoria Risk]

We have had a couple of requests for a log message warning that an NTA has just 
expired. The use case is, there is a help desk that needs to know when 
validation might be failing because of an NTA that was just removed.

Anyway, in response, Evan wrote a Python script that takes the output of rndc 
nta -d and lists the NTA's that are expiring in the next 24 hours. If you ran 
rndc nta -d and this script this daily, you would have a daily report. 

It gives you the full list of ntas, an indicator of whether they're already 
expired or yet to expire,  and the time of expiration.  
The python script filters out any that are already expired or whose expiration 
is more than a day in the future.

#!/bin/python
import sys, time, re

print ('Negative trust anchors expiring in the next 24 hours:')
found = False

for line in sys.stdin.readlines():
r = re.compile('^([^ ]*): (expir[^ ]*) (.*)')
m = r.match(line)
try:
(name, status, date) = m.groups()
except:
continue

now = time.time()
then = time.mktime(time.strptime(date, '%d-%b-%Y %H:%M:%S.%f'))
if status == 'expiry' and then <= now + 86400:
print ('  %s at %s' % (name, date))
found = True

if not found:
print ('  None')

I thought this might be useful to someone else out there.

Vicky





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND 9.13.x is the BETA version of BIND 9.14.0

[Victoria Risk]

Hello BIND-users,

Prior to BIND 9.13, new feature development releases were tagged as "alpha" and 
"beta", leading up to the first stable release for a given development branch, 
which always ended in ".0".
Now, however, BIND has adopted the "odd-unstable/even-stable" release numbering 
convention. There will be no "alpha" or "beta" releases in the 9.13 branch, 
only increasing version numbers. The first stable release from this development 
branch will be renamed as 9.14.0. We plan to pull a 9.14.0 stable branch at the 
end of 2018.

Therefore, we are already in the ‘Beta’ test period for 9.14.0. Major new 
features include the Local copy of the root zone feature and QNAME 
minimization, in particular, as well as IDNA2008 support. We want the 9.14 
branch to be stable with the .0 release, and we want these new features to be 
well-tested and deployable.

So far we have gotten two very welcome beta test reports:
- Test feedback on the root zone mirror feature from Tony Finch 
(https://gitlab.isc.org/isc-projects/bind9/issues/375)
- Thomas Jach reported an issue with QNAME minimization 
(https://gitlab.isc.org/isc-projects/bind9/issues/361)

If you have the time and want to help us out, please consider testing 9.13 and 
giving us your feedback. We welcome anyone to open a BIND issue at 
https://gitlab.isc.org/isc-projects/bind9.

Thank you,

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tool for finding undelegated children in your DNS

[Victoria Risk]

I have been told this is a very poor description of the problem.

What I am concerned about is, how people with a sort of lazy zone file can 
assess the potential impact of QNAME minimization on their ability to answer 
for all of their zones.

I have gotten two suggestions off list:
- I would use named-checkzone to print the zone with all owner names printed 
out and then use text processing tools
- “dig ds -f list-of-zones”, Those that return NXDOMAIN are likely missing NS 
records.

Any other ideas?
Has anyone done this kind of housekeeping on their own zones?


> On Jul 26, 2018, at 11:41 AM, Victoria Risk  wrote:
> 
> Does anyone know of a good tool that you can run on your DNS records to find 
> parent + child pairs where there is no NS record for the child in the parent?
> 
> Someone must have a perl script for that, right?
> 
> Thank you for any suggestions.
> 
> Vicky
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

tool for finding undelegated children in your DNS

[Victoria Risk]

Does anyone know of a good tool that you can run on your DNS records to find 
parent + child pairs where there is no NS record for the child in the parent?

Someone must have a perl script for that, right?

Thank you for any suggestions.

Vicky





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we bundle the MaxMind GeoIP db?

[Victoria Risk]

> On May 30, 2018, at 3:15 PM, Rick Dicaire  wrote:
> 
> Hi, would this conflict with any similar pkg installed by an OS's pkg 
> management system?

The package manager could choose whether or not to include the database - if 
they include it today, they wouldn’t include two copies, certainly. Even if 
they don’t include it today, they might not include it even if we bundle it.  
So this would not necessarily have any impact on what a particular package 
offers.

> 
> On Wed, May 30, 2018 at 5:27 PM, Victoria Risk  <mailto:vi...@isc.org>> wrote:
> Hello GeoIP users,
> 
> We are aware that Maxmind is discontinuing their older free GeoLite location 
> database and replacing it with a new database with a new format (GeoLite2). 
> https://dev.maxmind.com/geoip/geoip2/geolite2/ 
> <https://dev.maxmind.com/geoip/geoip2/geolite2/>
> 
> We have an issue open in the BIND gitlab to update our Geo-IP support to use 
> the new database api.  https://gitlab.isc.org/isc-projects/bind9/issues/182 
> <https://gitlab.isc.org/isc-projects/bind9/issues/182>
> 
> The question is, would it be useful if we included the GeoLite2 database with 
> the BIND distribution? Since we update at least twice a year, we could keep 
> it fairly well up to date, and it would save users having to go get and 
> update the db themselves. It would add about 1.5MB to the BIND distribution 
> (depending on whether we use the country or city level).
> 
> Votes, comments welcome. 
> 
> Thank you,
> 
> Vicky
> -
> Product Manager
> Internet Systems Consortium
> vi...@isc.org <mailto:vi...@isc.org>
> 
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
> <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe from this 
> list
> 
> bind-users mailing list
> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
> https://lists.isc.org/mailman/listinfo/bind-users 
> <https://lists.isc.org/mailman/listinfo/bind-users>
> 
> 

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Should we bundle the MaxMind GeoIP db?

[Victoria Risk]

Hello GeoIP users,

We are aware that Maxmind is discontinuing their older free GeoLite location 
database and replacing it with a new database with a new format (GeoLite2). 
https://dev.maxmind.com/geoip/geoip2/geolite2/

We have an issue open in the BIND gitlab to update our Geo-IP support to use 
the new database api.  https://gitlab.isc.org/isc-projects/bind9/issues/182 


The question is, would it be useful if we included the GeoLite2 database with 
the BIND distribution? Since we update at least twice a year, we could keep it 
fairly well up to date, and it would save users having to go get and update the 
db themselves. It would add about 1.5MB to the BIND distribution (depending on 
whether we use the country or city level).

Votes, comments welcome. 

Thank you,

Vicky
-
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND 9.13.x supported platforms

[Victoria Risk]

We are getting ready to release our first development release, following our 
new release model. (https://www.isc.org/blogs/bind-release-strategy-updated/ 
<https://www.isc.org/blogs/bind-release-strategy-updated/>)
One thing we wanted to improve, was to publish an explicit list of supported 
platforms. 

If you have comments, you can make them here or add them to the Gitlab issue 
(https://gitlab.isc.org/isc-projects/bind9/issues/72 
<https://gitlab.isc.org/isc-projects/bind9/issues/72>)

Supported Platforms
These are platforms we will regularly test on. 

Debian 8, 9 / amd64, i386, armhf
Ubuntu 16.04, 18.04 / amd64, i386, armhf
Fedora 27, 28 / amd64, i386, armhf
Red Hat/CentOS 6, 7 / amd64, i386, armhf
FreeBSD 10.4-10.x, 11.6-11.6 / amd64, i386, armhf
OpenBSD 6.3 / amd64, i386, armhf


Best Effort

Other Linux distributions
Other architectures (mips, mipsel, arm64)
Ubuntu 14.04, 18.10+
Gentoo 
ArchLinux 
Alpine Linux (non-glibc)
OpenWRT/LEDE 17.0
Solaris 10
Windows 10 / x64
Windows Server 2012 R2, 2016 / x64
macOS 10.12+
FreeBSD 12+
OpenBSD 6.2
NetBSD


Not Supported (explicitly listing)

Platforms without CC11 (without standard atomics)
Platforms without OpenSSL >= 1.0.2
Windows 10 / x86
Windows Server 2012


Thank you!

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Release Strategy Clarification

[Victoria Risk]

> On Apr 26, 2018, at 5:53 AM, Matthew Pounsett  wrote:
> 
> This is a question for ISC about the new BIND release plan which I thought 
> might be a useful clarification for others as well.
> 
> I didn't notice this when the new plan was first presented in March, but the 
> key text in the legend of the Example Release Plan[0] for the red blocks is 
> "a release that is no longer supported."  This implies that 9.12 will go from 
> being the most recent supported stable version of BIND to unsupported 
> literally overnight.  It doesn't appear there is a period where 9.12 and 9.14 
> are both supported, as 9.12 approaches end of life.
> 
> Is this an oversight, where the legend text needs updating to "a release that 
> is approaching end of life," or do we really all have to plan to do our 
> upgrades on January 1st every year?

Hi Matt,

You have correctly interpreted the chart in the blog post, but you don’t have 
to update in January, just when there is a bug you need a fix for.  If that bug 
is a security bug, the red block means, we will issue a security patch even 
though we are no longer issuing regular maintenance on that branch. So, 
effectively there is a quarter, 3 months, of overlap.

We want to do much more frequent releases, with new branches every year. We 
can’t create more branches AND support all of them for years like we used to. 
We believe that if the delta from one version to another is smaller, because 
the releases are closer together, then if you are say, running 9.12.3, and you 
want a bug fix, and we put that bug fix into 9.14.0, that will not be a big 
leap to upgrade to that.

Not everyone wants to update every year though, and that is why we also have 
the Extended Support Version. We are committed to supporting 9.11.x through the 
end of 2021. That will allow people to stay on that branch for something like 5 
years, which seems like plenty.  

It is true that you have to make a choice about whether to hang out with the 
ESV or follow the annual stable releases.

Vicky

> 
> Thanks,
>Matt
> 
> 
> [0]: <https://www.isc.org/blogs/bind-release-strategy-updated/ 
> <https://www.isc.org/blogs/bind-release-strategy-updated/>>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS Privacy Interest and Concerns

[Victoria Risk]

We are taking a poll of DNS administrators to determine the level of interest 
in DNS privacy and to find out what are the significant concerns. So far, 
respondents have taken only 5 minutes on average to complete the survey.  We 
would like to get a lot more responses so the results are reasonably 
representative of the overall DNS community, not just the privacy advocates.

Please take a few minutes and complete this short survey: 
https://www.surveymonkey.com/r/dnsprivacy

We are NOT collecting any personally identifying information (names, companies, 
or IP addresses).  We WILL report the summary results publicly.

Thank you!

Vicky
---
Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Interest in sharing operational experience with other users?

[Victoria Risk]

ISC does not pretend to have all the answers when it comes to operation of 
BIND-based services.

Is there interest in having a series of user-to-user presentations on 
experience with BIND systems administration?  Anyone who feels they have a 
clever or easily reusable solution to a common problem, or who has come up with 
a useful open source monitoring or provisioning tool could volunteer to do a 
short presentation with some Q&A, open to any other interested users. ISC would 
advertise these and ‘host’ them.

I know that enthusiasm about live webinars varies widely, but we can also 
commit to archiving all the slides and recordings for those who prefer to scan 
and skip ahead.

I have managed to recruit one user to start this off. 

Presenter: Felipe Espinoza of NIC Chile
Topic: Felipe Espinoza of NIC Chile will share his experience reviewing and 
benchmarking different open source software to generate an integrated 
monitoring system for DNS, from the capture of the DNS packets, their storage, 
visualization and alerting of abnormalities.  
Date, Time: Mar 27, 2018 10:00 AM iPACIFIC TIME)
Register: https://zoom.us/webinar/register/WN_p8inqvcCRlCEk-k_2hwcnw

Is anyone else willing to give this a try? You can ask on list whether anyone 
is interested in your proposed topic, and/or unicast back to me to try to 
schedule something.

Vicky
------
Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bugs with BIND 9.11.0-P3 edns client subnet

[Victoria Risk]

> On Oct 12, 2017, at 10:00 AM, Shawn Zhou via bind-users 
>  wrote:
> 
> Hello all,
> 
> Does anyone use BIND 9.11.0-P3 in recursive setup with edns client subnet 
> support?
> When I dig against a local recursive resolver (BIND 9.11.0-P3) with 
> '+subnet=' option, it doesn't send 'Client subnet' option to the 
> authoritative server which also runs the same version of BIND; however, if I 
> dig directly against the authorize server with '+subnet=' option and it works 
> fine. Is this a known bug with client subnet implementation in BIND?

Hi Shawn,  

The resursive support for EDNS client-subnet is only in our subscription 
edition.  It is not in any version of 9.11.0. The subscription edition is 
available to support subscribers but is not posted publicly.  The company that 
sponsored the work required that we embargo it from the open source to give 
them a chance to market it in their own version of BIND.  If you have any more 
questions about this, I invite you to unicast to me at vi...@isc.org.

Regards,

Vicky Risk
Product Manager

> 
> 
> Thanks,
> Shawn
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Internet Systems Consortium
vi...@isc.org




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: filter-aaaa-on-v4 not available in Windows binary?

[Victoria Risk]

> On Aug 30, 2017, at 8:55 AM, pLAN9  wrote:
> 
> Apologies all, I missed an Event Viewer entry:
> 
> "C:\Program Files\ISC BIND 9\etc\named.conf:19: option 'filter--on-v4' 
> was not enabled at compile time"
> 
> So it appears I DO have to recompile…

I see that Mark has made a ticket to turn on filter--on-v4 support in our 
windows builds in the future.
https://bugs.isc.org/Ticket/Display.html?id=45883 


Vicky

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Guest access to the BIND and ISC DHCP bug database

[Victoria Risk]

Hello BIND and DHCP users,

We have wanted to open ISC's BIND and ISC-DHCP bug database for a long time, 
and now we are finally ready to do it.
As of July 7th, 2017, ISC’s internal bug database will offer read-only access 
to anonymous guest users.  Guest users will be able to read issues in a new 
‘public issues’ queue.

We are committed to protecting the confidentiality of information previously 
submitted by users with an expectation of privacy.  Therefore, we are not going 
to publish pre-existing issues by default.  We do plan to publish some existing 
issues that we think are particularly useful to users to see, such as those 
resolved in our most recent releases, or significant open bugs, after first 
reviewing them for confidential information.  This review will happen gradually.

We would like to publish all new issues by default. Unless you specifically ask 
us to keep your issue confidential, your bug reports will be published, 
including your email address and any attachments submitted.  We don’t want 
anyone to be discouraged from reporting an issue because of a concern about 
privacy: all you have to do is mention in the body of your report that you want 
us to keep the report confidential, and we won’t put it into the public queue.  
We will also not publish any report that we are evaluating as a potential 
security vulnerability.  We don’t think feature requests are likely to include 
confidential information, so requests sent to bind-sugg...@isc.org 
 or dhcp-sugg...@isc.org 
 will go into the public queue automatically.

You may continue to report issues via email (mailto: bind9-b...@isc.org 
, or mailto: dhcp-b...@isc.org 
) or to use the form on our web site 
https://www.isc.org/community/report-bug/ 
.  After July 7th, when you are able 
to browse issues reported by other users, you will also be able to add your 
comments, by quoting the subject header of the existing bug in your email. We 
hope that this added transparency will be useful to us both in maintaining and 
using these open source applications.

We are announcing this change a month ahead of the planned implementation date 
to allow the user community plenty of time to think about it and give us 
feedback. We will post instructions on accessing the database as we get closer 
to availability.

Please let us know if you have any concerns about this, or suggestions for a 
better implementation. 

Vicky Risk
ISC Product Manager

PS - I posted a blog post about this too, with a bit more detail at 
https://www.isc.org/blogs/bind-and-isc-dhcp-bug-db-opening-for-guest-users/ 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Guest access to the BIND and ISC DHCP bug database

[Victoria Risk]

Hello BIND and DHCP users,

We have wanted to open ISC's BIND and ISC-DHCP bug database for a long time, 
and now we are finally ready to do it.
As of July 7th, 2017, ISC’s internal bug database will offer read-only access 
to anonymous guest users.  Guest users will be able to read issues in a new 
‘public issues’ queue.

We are committed to protecting the confidentiality of information previously 
submitted by users with an expectation of privacy.  Therefore, we are not going 
to publish pre-existing issues by default.  We do plan to publish some existing 
issues that we think are particularly useful to users to see, such as those 
resolved in our most recent releases, or significant open bugs, after first 
reviewing them for confidential information.  This review will happen gradually.

We would like to publish all new issues by default. Unless you specifically ask 
us to keep your issue confidential, your bug reports will be published, 
including your email address and any attachments submitted.  We don’t want 
anyone to be discouraged from reporting an issue because of a concern about 
privacy: all you have to do is mention in the body of your report that you want 
us to keep the report confidential, and we won’t put it into the public queue.  
We will also not publish any report that we are evaluating as a potential 
security vulnerability.  We don’t think feature requests are likely to include 
confidential information, so requests sent to bind-sugg...@isc.org or 
dhcp-sugg...@isc.org will go into the public queue automatically.

You may continue to report issues via email (mailto: bind9-b...@isc.org 
, or mailto: dhcp-b...@isc.org 
) or to use the form on our web site 
https://www.isc.org/community/report-bug/ 
.  After July 7th, when you are able 
to browse issues reported by other users, you will also be able to add your 
comments, by quoting the subject header of the existing bug in your email. We 
hope that this added transparency will be useful to us both in maintaining and 
using these open source applications.

We are announcing this change a month ahead of the planned implementation date 
to allow the user community plenty of time to think about it and give us 
feedback. We will post instructions on accessing the database as we get closer 
to availability.

Please let us know if you have any concerns about this, or suggestions for a 
better implementation. 

Vicky Risk
ISC Product Manager

PS - I posted a blog post about this too, with a bit more detail at 
https://www.isc.org/blogs/bind-and-isc-dhcp-bug-db-opening-for-guest-users/___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: views

[Victoria Risk]

> On Apr 19, 2017, at 8:47 AM, Nico CARTRON  wrote:
> 
>> Nor did I see
>> details on how to have BIND send ECS with queries when it's a recursive
>> server.
> 
> As far as I know, ECS for Recursive queries is not yet implemented by ISC, or
> at least it is not publicly available.

We have implemented ECS for recursive queries in 9.10.5-S, the subscriber 
preview edition of BIND, which will be released today. For now, ECS recursion 
is available only to users with a support contract with ISC. Development of 
this feature was a significant effort, sponsored by an OEM user of BIND. As 
part of the agreement with the sponsor, we agreed to embargo the feature from 
the open source until 2018.

Victoria Risk
Internet Systems Consortium
vi...@isc.org






signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Comments on Root Key Rollover impact on BIND users

[Victoria Risk]

You all are probably aware of the plans for rolling the root dnssec key in 
2017.  ICANN is trying to ensure this goes smoothly and we are of course 
looking for ways ISC can help.

There is a draft blog post on the topic of the 2017 Root Key Rollover, kind of 
hidden on ISC’s web site here: 
https://www.isc.org/blogs/2017-root-key-rollover-what-does-it-mean-for-bind-users/
 

   We had to turn off comments on the web site because the spam was out of 
hand, but I welcome corrections, examples, or further suggestions from 
bind-users and will add them to the blog.

Towards the end of the blog, there is a short list of possible ‘corner cases’ 
that could trip people up during the rollover.  If you folks can think of 
others, please do share them.  ISC’s BIND test engineer, Curtis, is planning a 
thorough test of the BIND support for the root dnssec key rollover in 2017 Q1 
and he would appreciate any input into the test plan.

Please either post discussion here or unicast to vi...@isc.org 
 or c...@isc.org . 

Thank you,

Vicky Risk
Product Manager, isc.org



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: replicate a whole master

[Victoria Risk]

> On Sep 19, 2016, at 8:40 AM, Tony Finch  wrote:
> 
> /dev/rob0  wrote:
>> 
>> If you're thinking that you can do this replication to improve DNS
>> performance, you're right, it will do that.  But it certainly will
>> not scale (if it's even possible to get axfr/ixfr), and it won't
>> handle modern CDN systems properly.
> 
> BIND 9.10 and later will keep popular domains in the cache by prefetching
> them if they are looked up shortly before they will expire. So trying to
> keep local copies of popular zones is less helpful than it used to be.
> 
> (Unfortunately the prefetch option isn't mentioned in the HISTORY file so
> I had to dig through the CHANGES to remind myself when it was introduced!)
> 

We do have a matrix that shows when significant new features were added. Of 
course not every change is on there, but pre-fetch is.

https://kb.isc.org/article/AA-01310/109/BIND9-Significant-Features-Matrix.html

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
> Tyne, West Dogger: Northerly 4 or 5. Slight. Occasional rain. Moderate or
> good, occasionally poor.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Victoria Risk
Internet Systems Consortium
vi...@isc.org




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ISC considering a change to the BIND open source license

[Victoria Risk]

Hi Robert,

> It looks like this was announced today:
> 
> https://www.isc.org/blogs/bind9-adopts-the-mpl-2-0-license-with-bind-9-11-0/
> 
>> The MPL license requires that anyone redistributing the code who has changed 
>> it must publish their changes (or pay for an exception to the license). It 
>> doesn’t impact anyone who is using the software without redistributing it, 
>> nor anyone redistributing it without changes – so most users will not see 
>> any change.
> 
> Can you clarify what "or pay for an exception to the license" means?
> I also see a similar statement in these slides:
> 
> https://ripe72.ripe.net/presentations/150-Relicensing-BIND.pdf
> 
>• Probably Mozilla (MPL 2.0), possibly adding hosting clause
>  • Contribute changes or pay for exception license
>  • Not commercial software, just charging for exception
> 
> I don't think the MPL-2.0 has a "pay for an exception" clause, so this
> would seem to imply that you plan to dual license BIND, or license BIND
> under a modified license based on the MPL-2.0. Is that correct?

You are correct. We expect that some of the commercial vendors, many of whom 
who have invested years in BIND modifications, will not be able or willing to 
open source all their modifications, so we plan to negotiate a dual license 
with those that want this. I think it was Richard Stallman who coined the term 
‘license exception’, maybe it is not a precise legal characterization.  

We don’t have a model for what this license might look like yet. We did get 
some suggestions along those lines while we were soliciting comments, including 
one creative suggestion that we try to extract patches with a promise that we 
will delay incorporating them.  (which some would say is an awful lot like what 
we do already!)

The general idea is, helping to support a core maintainer can be as useful to 
the project as submitting patches, or more useful.  We end up substantially 
re-writing quite a few of the patches we receive, often because they don’t work 
under every OS we support. The commercial vendors in particular tend to 
optimize for a single OS.   

> There is also this statement in your blog post:
> 
>In addition, we will be updating our contributor guidelines so
>technical contributors are aware of how their contributions will be
>licensed.  We are considering other changes to the way people
>contribute code changes.  We do not plan to add a contributor
>agreement, based on the significant feedback we received against it.
> 
> Your contributor guidelines now read:
> 
>https://www.isc.org/git/guidelines/
> 
>ISC does not require an explicit copyright assignment for patch
>contributions. However, by submitting a patch to ISC, you implicitly
>certify that you are the author of the code, that you intend to
>reliquish exclusive copyright, and that you grant permission to
>publish your work under whichever is the standard license agreement
>for the project you are submitting it for. (The license agreement
>depends on the project and also the version, since we have changed
>two projects from the ISC license to the Mozilla Public License 2.0)
> 
> It looks like that paragraph formerly read:
> 
>
> https://web.archive.org/web/20160329142948/https://www.isc.org/git/guidelines/
> 
>ISC does not require an explicit copyright assignment for patch
>contributions. However, by submitting a patch to ISC, you implicitly
>certify that you are the author of the code, that you intend to
>reliquish exclusive copyright, and that you grant permission to
>publish your work under the ISC license.
> 
> Can you clarify what "...that you intend to relinquish exclusive
> copyright" means? This sounds vaguely like an implicit contributor
> license agreement.

I did not write that, I think probably Evan did. Yes, I think it is intended as 
an implicit contributor agreement.  

We did get a number of explicit requests that we not require contributors to 
sign a form before submitting a patch, so I think what we will have to do is 
have a more thorough ‘implicit contributor agreement’ and do a better job of 
ensuring submitters actually see it.  The contributor information on our web 
site is in a half-and-half state, kind of like beta right now.  I just whacked 
in that sentence about having different licenses for different versions as a 
starting place, we are not done yet.

> I'm also confused as to how you plan to not require a contributor
> agreement, while still being able to sell exceptions to the restrictions
> in the MPL-2.0. E.g., suppose an external contributor writes 1000 lines
> of new code, and licenses it under MPL-2.0 by putting a copyright notice
> and license grant at the top:

We don’t have all the answers. 
A 1000-line contribution would be an exceptional one for BIND.  Most of the 
contributions I have seen are more like 20 lines.  In the case of Kea, where we 
were offered a large contribution

Re: ISC considering a change to the BIND open source license

[Victoria Risk]

> 
> What are the underlying reasons for wanting to make this change?

Hi Lars,

As you know, ISC is a non-profit. Our funding comes from software support 
contracts and small donations from users. We like this model because our 
funding is aligned with what we see as doing our core job.  

As people opt for versions of BIND from commercial vendors, we lose them as 
potential support customers, so the pool of people supporting the core project 
shrinks.  A few commercial vendors do have software support contracts with ISC, 
which helps, but others neither share their fixes with us nor help support us.  
Some of them even market their applications as “BIND, but without the bugs”, 
and seem not to realize what is wrong with this.  (One commercial vendor told 
us they would not consider contributing patches because those would help their 
competitors.)  It seems unfair to those who do support ISC, many of whom are 
not large or rich organizations themselves, to allow others to profit off of 
commercializing the open source without sharing anything.  

We can’t ignore this because it is a trend.  Fewer people are willing and able 
to build from source, perhaps some people prefer graphical tools, and many 
people with larger installations need management tools and security add-ons 
that commercial vendors provide. We don’t want to deny anyone these things, but 
if those applications are built on top of our open source, we want to encourage 
their vendors to support the core projects.

BIND has been free in every sense for a very long time. During this time, the 
open source world has evolved.  We no longer need a permissive license in order 
to encourage reuse of BIND, we need a community-oriented license to encourage 
contributions to the open source.   This change will not automatically ensure 
that commercial vendors modifying BIND will support ISC, but it will at least 
communicate that this would be appropriate. 

Vicky
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ISC considering a change to the BIND open source license

[Victoria Risk]

Hello BIND users-

ISC published BIND under a very permissive open source license 
 
(https://www.isc.org/downloads/software-support-policy/isc-license/ 
) nearly 
two decades ago.  ISC is the organizational steward for BIND; in order to 
preserve the software for the long term, we are considering a move to the more 
restrictive Mozilla Public License (MPL 2.0) 
 
(https://www.mozilla.org/en-US/MPL/2.0/ 
).

The MPL license requires that anyone redistributing the code who has changed it 
must publish their changes (or pay for an exception to the license). It doesn’t 
impact anyone who is using the software without redistributing it, nor anyone 
redistributing it without changes – so most users will not see any change. 

In the event we do proceed with the change in license, we will announce this 
with the 9.11.0 beta and it will take effect with the BIND 9.11.0 release.

We welcome comments from BIND users, including statements of support or 
concern.  Email Vicky Risk, Product Manager at vi...@isc.org 
 if you want to discuss privately, Tweet at us at 
@ISCdotORG , or discuss on 
bind-users@lists.isc.org.

Regards,

Vicky Risk, 
Product Manager

Jeff Osborn, President of ISC, announcing we are considering this change at 
RIPE72 in Copenhagen May 26th, https://ripe72.ripe.net/archives/video/206 
.





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: rndc (and now nsupdate too)

[Victoria Risk]

This recent thread, in which people are describing their scripts and GUI 
provisioning systems makes me think we should recruit a few of you who think 
you have a sweet provisioning system, to do a WebEX and describe it for 
everyone else who is looking for a better system.

At the RIPE meeting in Poland I saw a GUI front end for updating resource 
records that a French university network team had created and a very impressive 
system using Ansible to rapidly transform a NSD auth server into a BIND auth 
server and back again (including translating zone files). There are a number of 
tools and cookbooks out there, if the tool you use is not one you developed, 
but it is public domain, open source or otherwise freely available and you 
think it is really helpful, it would be useful for others to hear about that 
too.

If you have a reasonably full-featured, effective, free provisioning system 
that could be shared and successfully used in another environment, and you are 
willing to do a presentation on it (perhaps share an hour slot with one other 
person), please email me unicast.  If we get any volunteers, we’ll schedule 
something and advertise it back here on bind-users.

Vicky 
Product Manager, isc.org

On Aug 1, 2014, at 9:09 AM, Tony Finch  wrote:

> Mike Hoskins (michoski)  wrote:
>> Tony Finch  wrote:
>>> 
>>> In our setup, changes made in the database are turned into an nsupdate
>>> script, so we don't need to bounce the name server and we can use
>>> BIND's automatic signing.
>> 
>> no argument on nsupdate, but even if you copy files around...you don't
>> need to bounce the nameserver, unless rndc reload is what you mean (when i
>> hear bounce i think stop/start).
> 
> Sorry, I was being imprecise. When I said "bounce" I meant any kind of
> config change action that makes named do more work than is necessary to
> change the contents of the zone.
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> FitzRoy: Westerly or southwesterly veering northwesterly, 4 or 5, increasing 6
> or 7 for a time in east. Slight or moderate, becoming moderate or rough in
> east. Rain or thundery showers. Good, occasionally poor.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dns firewall, proof of concept howto published, rpz. request for feedback

[Victoria Risk]

I posted the pdf of the How-To on this page, down towards the bottom:

http://www.isc.org/community/tools/

Vicky Risk
ISC
On May 11, 2014, at 3:21 PM, G.W. Haywood  wrote:

> Hi there,
> 
> On Sun, 11 May 2014, Hans-Cees Speel wrote:
> 
>> Feedback is welcome!
>> ...
>> pdf at: https://app.younited.com/...
> 
> Put it somewhere else?
> 
> --
> 
> 73,
> Ged.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users