Re: Unable to Query DoH with `tls none` and Plain HTTP
On 2024-01-01 16:38, Ondřej Surý wrote: On 1. 1. 2024, at 15:19, r1wcp...@bbqporkmccity.com wrote: Thank you very much, I was unaware of the HTTP/2 requirement and was assuming it is a bug. Is there any reason for omitting the HTTP/1.1 upgrade part of the protocol? It would be additional complexity that's really not needed. The HTTP/2 library (libnghttp) doesn't provide HTTP/1.1 implementation, so we would have to bolt something own for a little gain. And it would increase an attack surface as it would be yet another protocol open to the world that can have bugs in it. Funny, given that HTTP/2 (the spec) had a CVE against it last October, while HTTP/0.9 and HTTP/1.x did not. Having the DoH server as a standalone process talking to DNS/TCP would be a solid implementation given the constant flow of changes made to HTTP(S) by the Big 5. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-07-07 12:17, Emmanuel Fusté wrote: Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. It is at the core of delegation and trust model of DNS, now possibly enforced by DNSSEC. Peer centric resolvers are lax on this checking for all but the security of their users. So in your opinion it is purely useless, and bad data it better than nodata/error. I am saying that the SOA copy in the authority section of responses is purely informational, unlike the data that provides DNSSEC signatures or even the data that provides IP addresses for servers in responses to MX queries. So from that perspective, if bind code checks that this informal copy of an SOA record is for the wrong zone, it should simply filter out that SOA record instead of filtering out the entire response to the actual query. In the special case of using that SOA copy to get the negative response TTL, that special use should only check that the SOA copy was provided in the same DNS response as the negative response to be cached, not the diagnostic data about the origin server's zone files. In a similar way, bind should not object to the SOA mail contect being valid, as a surprising number of zones actually fail to handle mail to that address (I personally had to go through hoops with support people when trying to coordinate a small change with another zone that I no longer had a business relationship with, so validating this is useful in a compliance checker, but not in a caching resolver). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
I know, but that's routine if the build system is any good. On 2022-02-17 18:42, Danny Mayer wrote: You have to run the debug-enabled code as a service otherwise you will get nowhere. It's complicated and it's time consuming to set up right. Danny On 2/17/22 12:30 PM, Jakob Bohm via bind-users wrote: I know this, and I am quite familiar with low level debugging techniques on Windows, though my favorite tool for the job was ruined by unfortunate business decisions to bundle it with irrelevant software that would be needed only in a completely different license count, if at all. I could probably set up a debugging scenario with a private compilation (to get debug symbols) and an artificial installation of more recent toolchain to work with the official ISC build instructions, though I strongly suspect a clean process exit with a return code of 0 (Depending, how good Windows is at capturing the return code of the exited product). But I was hoping there was a way to find out directly, such as an option to make the entire startup sequence non-parallel and verbose, thus revealing the exact point of failure. On 2022-02-17 17:15, Danny Mayer wrote: I can short-cut that a little! :) A 1067 error is always the Windows named service failing to start. The reasons behind it are much harder to figure out. I've seen these over the years but I don't know off the top of my head why. Danny On 2/17/22 9:26 AM, Ondřej Surý wrote: Log isn’t going to help here if named is crashing. Getting a backtrace or anything that closely resembles one would help. Running debug build under MSVS would help. Or doing git bisect and pinpoint the breakage to a commit or at least Merge commit would help. This is part of the problem - debugging on Windows is extremely painful and requires expertise with extremely high learning curve. -- 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 17. 2. 2022, at 15:08, Jakob Bohm via bind-users wrote: On 2022-02-12 01:06, Richard T.A. Neal wrote: I run BIND on Windows as well but I've been unable to upgrade to 9.16.25 - I get an error stating "Error Validating Account. Unable to install service using this account.". So I'm presently running 9.16.21. What are the last few things in the Application Event Log (Source: named) before it terminates? Richard. -Original Message- From: bind-users On Behalf Of Jakob Bohm via bind-users Sent: 11 February 2022 12:19 pm To: bind-users Subject: Windows 9.16.25 fails to start (1067 Terminated unexpectedly) Dear list, When recently trying to upgrade some secondary-only authoritative servers running on Windows machines, I found that Bind 9.16.25 (x86_64) binaries from isc.org failed to completely startup, causing Windows to report that "1067 The process terminated unexpectedly.", with 0 process exit code. Attempting to up the debug level all the way to "-d 100" failed to log a reason, but downgrading to the 9.16.21 binaries resumed operation. Is there a known issue and workaround for this, or is there any additional information to extract? The latest in the log (I directed it to a file, as the Event Viewer wrapping in the port was badly done) were the mentioned fetch of ./NS etc. interspersed with zone loading messages for default zones (I temporarily commented out the real zones to shorten the config, but it still failed). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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 Enjoy Jakob Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is there a community product maintaining Windows support?
On 2022-02-17 18:01, Reindl Harald wrote: Am 17.02.22 um 17:36 schrieb Jakob Bohm via bind-users: This is truly tragic, and quite counterproductive action by ISC. no, it's just stop wasting time for things not really used in the real production world Messing about with docker virtualization inside an already virtual machine seems like a recipe for disaster nobody said that when you already have a virtualization infracstructure the far better question is why you did install named on a windows guest to begin with Because it is leased VMs at commercial cloud providers, which implies an economic benefit to reuse a single VM for multiple daemons. BTW: docker is *not* virtualization and i would *always* install any containers inside virtual machines because on production hardware the only thing which belongs to bare-metal is the hypversior (yes, there are *very few* expections, contgainers are non of them) To me, containers are a simplified virtualization technology that shares the kernel and kernel state, virtualizing only the user space. That it is marketed with contrary words means nothing. why? because there is redundancy, hot migration, backup-infrastructure and so on - the only usecase for containers is lightweight isolation for the few cases a systemd-unit with proper namespaces and cgroups isn't enough So back to Linux-exclusive concepts, indicating this is all about using the Linux build with a Linux-on-windows layer, Hence my preference to reverse the order and go for a pure (and cheaper) Linux VM. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
I know this, and I am quite familiar with low level debugging techniques on Windows, though my favorite tool for the job was ruined by unfortunate business decisions to bundle it with irrelevant software that would be needed only in a completely different license count, if at all. I could probably set up a debugging scenario with a private compilation (to get debug symbols) and an artificial installation of more recent toolchain to work with the official ISC build instructions, though I strongly suspect a clean process exit with a return code of 0 (Depending, how good Windows is at capturing the return code of the exited product). But I was hoping there was a way to find out directly, such as an option to make the entire startup sequence non-parallel and verbose, thus revealing the exact point of failure. On 2022-02-17 17:15, Danny Mayer wrote: I can short-cut that a little! :) A 1067 error is always the Windows named service failing to start. The reasons behind it are much harder to figure out. I've seen these over the years but I don't know off the top of my head why. Danny On 2/17/22 9:26 AM, Ondřej Surý wrote: Log isn’t going to help here if named is crashing. Getting a backtrace or anything that closely resembles one would help. Running debug build under MSVS would help. Or doing git bisect and pinpoint the breakage to a commit or at least Merge commit would help. This is part of the problem - debugging on Windows is extremely painful and requires expertise with extremely high learning curve. -- 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 17. 2. 2022, at 15:08, Jakob Bohm via bind-users wrote: On 2022-02-12 01:06, Richard T.A. Neal wrote: I run BIND on Windows as well but I've been unable to upgrade to 9.16.25 - I get an error stating "Error Validating Account. Unable to install service using this account.". So I'm presently running 9.16.21. What are the last few things in the Application Event Log (Source: named) before it terminates? Richard. -Original Message- From: bind-users On Behalf Of Jakob Bohm via bind-users Sent: 11 February 2022 12:19 pm To: bind-users Subject: Windows 9.16.25 fails to start (1067 Terminated unexpectedly) Dear list, When recently trying to upgrade some secondary-only authoritative servers running on Windows machines, I found that Bind 9.16.25 (x86_64) binaries from isc.org failed to completely startup, causing Windows to report that "1067 The process terminated unexpectedly.", with 0 process exit code. Attempting to up the debug level all the way to "-d 100" failed to log a reason, but downgrading to the 9.16.21 binaries resumed operation. Is there a known issue and workaround for this, or is there any additional information to extract? The latest in the log (I directed it to a file, as the Event Viewer wrapping in the port was badly done) were the mentioned fetch of ./NS etc. interspersed with zone loading messages for default zones (I temporarily commented out the real zones to shorten the config, but it still failed). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is there a community product maintaining Windows support?
This is truly tragic, and quite counterproductive action by ISC. Messing about with docker virtualization inside an already virtual machine seems like a recipe for disaster. And given the way you suggest it, I suspect you mean running a Linux binary under the WSL layer which is not available in any Nadela-free version of Windows. So I guess I will have to port the other software on the machine to Linux a little earlier than previously planned. On 2022-02-17 15:27, Danny Mayer wrote: As the original developer of the Windows version of bind9, I can tell you that ISC has removed support for the WIndows version from their newer versions of the code and there are other changes that would need a lot of work to catch back up. Since BIND9 is under continuous development you'd be in a constant race to keep up. It's not worth the effort. I have recommended that you use the docker image version of BIND9 and run that on your Windows box. Danny On 2/17/22 7:42 AM, Jakob Bohm via bind-users wrote: Fortunately (or unfortunately), the existing port of the 9.16.x bind code to Windows is built with Microsoft tools (MSVC2019) and contains its own handling of differences between Windows and Unix. If a maintainer stepped up to maintain the source for a port, I could compile it locally for our own systems, as I happen to also be a software developer using bind to support that activity. I know that there is a project that builds a 3rd party installer for the Windows port (I currently use the simple upstream install utility that is included in the ISC binary download), and I was hoping that maybe someone from that installer project could extend it to also maintain the port itself. On 2022-02-11 18:02, Ted Mittelstaedt wrote: I just became a maintainer on the apcupsd project. I don't know if bind for windows is built like apcupsd is, by using mingw32 but unfortunately there's problems with the mingw32 project these days, it's gone through a lot of transitions. Getting a working build environment for apcupsd at least, requires using pretty old versions of mingw. No doubt I'm going to be jumped on for saying so but I know for apcupsd I've got a -lot- of work to do to get it up to speed. There are some people out there who have built their own mingw32/mingw64 binaries that are separate from the ones "officially" distributed which might be an avenue. My guess the ISC developer who was spearheading this port moved on to other things and ISC can't find someone who wants to get involved in this and I can understand why. There is an interesting article on this problem here: https://increment.com/open-source/the-rise-of-few-maintainer-projects/ I would ask you this Jakob - would you trust a windows binary of bind that you compiled? I've got years of history participating on the apcupsd project. When I start submitting changes to it, the users of it have that trust automatically from that history. They won't worry if they download a binary from sourceforge that I built that it's going to gun their system. I'm a public figure in OSS besides that - people may like me or think I'm an asshole - but they know I'm a real person who has a rep. to maintain. I've got a business, federal and state tax ID's, a published phone number, multiple domain names I've owned for years. I can't run and hide. You can probably review the bind mailing list and dig out less than 100 names of people who have been on it, regularly posting, for the last decade. If none of those people step up to create a fork - then the windows port is effectively going to be dead I'm afraid. Nobody is going to trust "some dude" with zero history who sets up on github and forks bind and posts a windows binary for downloading just because he says it's gold. Would you? Trust a production system to that? OSS got it's start by making the CODE available, NOT BINARIES. Users like you were expected to be completely happy with the fact that the code was even there at all and it compiled. You do your own building. Not knowing how to run a compiler is no excuse. The Internet has tons of tutorials on it. You want a bind for windows - build it yourself. That's the can-do attitude that OSS started with. I remember the first time I ever downloaded an real OSS code and built it myself. It was rzsz - zmodem code for windows. Back in the BBS days, really. That's the only way you got that binary. It was a total gas and I was hooked. Don't deny yourself the same pleasure. Ted On 2/11/2022 8:24 AM, Jakob Bohm via bind-users wrote: As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 Th
Re: Is there a community product maintaining Windows support?
This is truly tragic, and quite counterproductive action by ISC. On 2022-02-17 15:27, Danny Mayer wrote: As the original developer of the Windows version of bind9, I can tell you that ISC has removed support for the WIndows version from their newer versions of the code and there are other changes that would need a lot of work to catch back up. Since BIND9 is under continuous development you'd be in a constant race to keep up. It's not worth the effort. I have recommended that you use the docker image version of BIND9 and run that on your Windows box. Danny On 2/17/22 7:42 AM, Jakob Bohm via bind-users wrote: Fortunately (or unfortunately), the existing port of the 9.16.x bind code to Windows is built with Microsoft tools (MSVC2019) and contains its own handling of differences between Windows and Unix. If a maintainer stepped up to maintain the source for a port, I could compile it locally for our own systems, as I happen to also be a software developer using bind to support that activity. I know that there is a project that builds a 3rd party installer for the Windows port (I currently use the simple upstream install utility that is included in the ISC binary download), and I was hoping that maybe someone from that installer project could extend it to also maintain the port itself. On 2022-02-11 18:02, Ted Mittelstaedt wrote: I just became a maintainer on the apcupsd project. I don't know if bind for windows is built like apcupsd is, by using mingw32 but unfortunately there's problems with the mingw32 project these days, it's gone through a lot of transitions. Getting a working build environment for apcupsd at least, requires using pretty old versions of mingw. No doubt I'm going to be jumped on for saying so but I know for apcupsd I've got a -lot- of work to do to get it up to speed. There are some people out there who have built their own mingw32/mingw64 binaries that are separate from the ones "officially" distributed which might be an avenue. My guess the ISC developer who was spearheading this port moved on to other things and ISC can't find someone who wants to get involved in this and I can understand why. There is an interesting article on this problem here: https://increment.com/open-source/the-rise-of-few-maintainer-projects/ I would ask you this Jakob - would you trust a windows binary of bind that you compiled? I've got years of history participating on the apcupsd project. When I start submitting changes to it, the users of it have that trust automatically from that history. They won't worry if they download a binary from sourceforge that I built that it's going to gun their system. I'm a public figure in OSS besides that - people may like me or think I'm an asshole - but they know I'm a real person who has a rep. to maintain. I've got a business, federal and state tax ID's, a published phone number, multiple domain names I've owned for years. I can't run and hide. You can probably review the bind mailing list and dig out less than 100 names of people who have been on it, regularly posting, for the last decade. If none of those people step up to create a fork - then the windows port is effectively going to be dead I'm afraid. Nobody is going to trust "some dude" with zero history who sets up on github and forks bind and posts a windows binary for downloading just because he says it's gold. Would you? Trust a production system to that? OSS got it's start by making the CODE available, NOT BINARIES. Users like you were expected to be completely happy with the fact that the code was even there at all and it compiled. You do your own building. Not knowing how to run a compiler is no excuse. The Internet has tons of tutorials on it. You want a bind for windows - build it yourself. That's the can-do attitude that OSS started with. I remember the first time I ever downloaded an real OSS code and built it myself. It was rzsz - zmodem code for windows. Back in the BBS days, really. That's the only way you got that binary. It was a total gas and I was hooked. Don't deny yourself the same pleasure. Ted On 2/11/2022 8:24 AM, Jakob Bohm via bind-users wrote: As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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-use
Re: Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
On 2022-02-12 01:06, Richard T.A. Neal wrote: I run BIND on Windows as well but I've been unable to upgrade to 9.16.25 - I get an error stating "Error Validating Account. Unable to install service using this account.". So I'm presently running 9.16.21. What are the last few things in the Application Event Log (Source: named) before it terminates? Richard. -Original Message- From: bind-users On Behalf Of Jakob Bohm via bind-users Sent: 11 February 2022 12:19 pm To: bind-users Subject: Windows 9.16.25 fails to start (1067 Terminated unexpectedly) Dear list, When recently trying to upgrade some secondary-only authoritative servers running on Windows machines, I found that Bind 9.16.25 (x86_64) binaries from isc.org failed to completely startup, causing Windows to report that "1067 The process terminated unexpectedly.", with 0 process exit code. Attempting to up the debug level all the way to "-d 100" failed to log a reason, but downgrading to the 9.16.21 binaries resumed operation. Is there a known issue and workaround for this, or is there any additional information to extract? The latest in the log (I directed it to a file, as the Event Viewer wrapping in the port was badly done) were the mentioned fetch of ./NS etc. interspersed with zone loading messages for default zones (I temporarily commented out the real zones to shorten the config, but it still failed). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Standard Ports And Non Standard Ports
On 2022-02-12 09:01, Greg Choules wrote: > "...to use a traditional VPN solution such as DNSSEC ..." DNSSEC is not a VPN service. It is regular, unencrypted DNS on port 53, or whichever port you choose - see the manuals and KB articles for how to configure non-standard ports. DNSSEC adds extra records to provide checks that answers are genuine. Oops, typo, I meant IPSEC. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is there a community product maintaining Windows support?
Fortunately (or unfortunately), the existing port of the 9.16.x bind code to Windows is built with Microsoft tools (MSVC2019) and contains its own handling of differences between Windows and Unix. If a maintainer stepped up to maintain the source for a port, I could compile it locally for our own systems, as I happen to also be a software developer using bind to support that activity. I know that there is a project that builds a 3rd party installer for the Windows port (I currently use the simple upstream install utility that is included in the ISC binary download), and I was hoping that maybe someone from that installer project could extend it to also maintain the port itself. On 2022-02-11 18:02, Ted Mittelstaedt wrote: I just became a maintainer on the apcupsd project. I don't know if bind for windows is built like apcupsd is, by using mingw32 but unfortunately there's problems with the mingw32 project these days, it's gone through a lot of transitions. Getting a working build environment for apcupsd at least, requires using pretty old versions of mingw. No doubt I'm going to be jumped on for saying so but I know for apcupsd I've got a -lot- of work to do to get it up to speed. There are some people out there who have built their own mingw32/mingw64 binaries that are separate from the ones "officially" distributed which might be an avenue. My guess the ISC developer who was spearheading this port moved on to other things and ISC can't find someone who wants to get involved in this and I can understand why. There is an interesting article on this problem here: https://increment.com/open-source/the-rise-of-few-maintainer-projects/ I would ask you this Jakob - would you trust a windows binary of bind that you compiled? I've got years of history participating on the apcupsd project. When I start submitting changes to it, the users of it have that trust automatically from that history. They won't worry if they download a binary from sourceforge that I built that it's going to gun their system. I'm a public figure in OSS besides that - people may like me or think I'm an asshole - but they know I'm a real person who has a rep. to maintain. I've got a business, federal and state tax ID's, a published phone number, multiple domain names I've owned for years. I can't run and hide. You can probably review the bind mailing list and dig out less than 100 names of people who have been on it, regularly posting, for the last decade. If none of those people step up to create a fork - then the windows port is effectively going to be dead I'm afraid. Nobody is going to trust "some dude" with zero history who sets up on github and forks bind and posts a windows binary for downloading just because he says it's gold. Would you? Trust a production system to that? OSS got it's start by making the CODE available, NOT BINARIES. Users like you were expected to be completely happy with the fact that the code was even there at all and it compiled. You do your own building. Not knowing how to run a compiler is no excuse. The Internet has tons of tutorials on it. You want a bind for windows - build it yourself. That's the can-do attitude that OSS started with. I remember the first time I ever downloaded an real OSS code and built it myself. It was rzsz - zmodem code for windows. Back in the BBS days, really. That's the only way you got that binary. It was a total gas and I was hooked. Don't deny yourself the same pleasure. Ted On 2/11/2022 8:24 AM, Jakob Bohm via bind-users wrote: As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Standard Ports And Non Standard Ports
On 2022-02-11 16:20, Tim Daneliuk via bind-users wrote: After some months of poking around, we are now certain that our so-called "Business" service from Comcast is compromising our DNS servers because of their execrable "Security Edge" garbage. (They are willing to remove this 'service' only if we are willing to incur a higher monthly recurring fee.) Our master is in the wild and works fine, but the slave is behind the compromised Comcast pipe. The effect of having Security Edge in place is that the slave cannot get updates from the master and is also unable to resolve anything outside our own zone. Comcast is apparently hijacking all port 53 requests and doing unspeakable things with them. Is there a way to have these servers work as usual, listening to resolution request on port 53, but have the slave update AND forward requests to the master over a non-standard port, so as to work around the Comcast madness? TIA, Tim P.S. My guess is that this so-call "security" service is no such thing, or at least its not the only thing. They are probably harvesting DNS lookups to sell as marketing data, or at least that would be my first guess. If bind cannot be configured to avoid a port blocking or filtering 3rd party filter between two of your own servers, the obvioussolution is to use a traditional VPN solution such as DNSSEC or OpenVPN to encrypt all traffic between the two servers. That should pass through any ISP filters that don't block work-from-home VPNs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Is there a community product maintaining Windows support?
As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
Dear list,
When recently trying to upgrade some secondary-only authoritative
servers running on Windows machines, I found that Bind 9.16.25 (x86_64)
binaries from isc.org failed to completely startup, causing Windows to
report that "1067 The process terminated unexpectedly.", with 0 process
exit code. Attempting to up the debug level all the way to "-d 100"
failed to log a reason, but downgrading to the 9.16.21 binaries resumed
operation.
Is there a known issue and workaround for this, or is there any
additional information to extract?
The bind binaries are installed in C:\Program Files\ISC BIND 9\bin
The config files are in C:\Program Files\ISC BIND 9\etc
Commenting out all the configured secondary zones did not fix the issues.
The zone primaries are identified by IP address in the zone config entries.
One of the last (but not always the actual last) debug messages logged
before failure was this:
resolver: debug 1: fetch: ./NS
This may or may not point to incomplete disabling of useless root server
access attempts.
Current config file:
options {
directory "C:\Program Files\ISC BIND 9\etc";
automatic-interface-scan no;
listen-on { 172.31.41.230; 127.0.0.1; };
listen-on-v6 { any; };
// Authoritative only
allow-query-cache { none; };
// Do not provide recursive service
recursion no;
// This is the default
allow-query { any; };
// This is not
allow-transfer { none; };
// Other useful settings
minimal-responses yes;
multi-master yes;
notify master-only;
version none;
server-id hostname;
max-zone-ttl 2764800;
// Prevent queries that would case troubles
blackhole { 0.0.0.0/8;
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
169.254.0.0/16; };
};
logging {
channel bind.log {
file "C:\Windows\logs\bind\bind.log" versions 10 size 20m;
// severity information;
print-category yes;
print-severity yes;
print-time yes;
};
category client { bind.log; };
category cname { bind.log; };
category config { bind.log; };
category database { bind.log; };
category default { bind.log; };
category delegation-only { bind.log; };
category dispatch { bind.log; };
category dnssec { bind.log; };
category dnstap { bind.log; };
category edns-disabled { bind.log; };
category general { bind.log; };
category lame-servers { bind.log; };
category network { bind.log; };
category notify { bind.log; };
category nsid { bind.log; };
category queries { bind.log; };
category query-errors { bind.log; };
category rate-limit { bind.log; };
category resolver { bind.log; };
category rpz { bind.log; };
category security { bind.log; };
category serve-stale { bind.log; };
category spill { bind.log; };
category trust-anchor-telemetry { bind.log; };
category unmatched { bind.log; };
category update { bind.log; };
category update-security { bind.log; };
category xfer-in { bind.log; };
category xfer-out { bind.log; };
category zoneload { bind.log; };
};
include "zones.bind.conf";
include "rndc.key";
controls {
inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; };
};
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
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
