RE: How to setup DNS on virtual machine
Hi Gary, I have written a guide for that here: https://www.winbind.org/guides/ I know you say you’ve already installed it, but I would still recommend starting with the “Installation” guide to make sure you’ve followed current best practice (well, *my* best practice, others may well chip-in with specific advice of course). Best, Richard. From: bind-users On Behalf Of Gary Chang Guang-Ruei Sent: 10 June 2021 5:56 am To: bind-users@lists.isc.org Subject: How to setup DNS on virtual machine Hi, I have installed bind 9.16.16 on a windows 10 virtual machine, my question is how do I make the virtual machine a DNS server to make queries? Thanks Gary This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. ___ 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
hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
DNSSEC signing using Bind 9.16.x's internal/automated key mgmt correctly
generates PublishCDS, DSChange, DSState data for the KSK .state.
Subsequent published data correctly contains CDS/CDNSKEY data.
Most registrars are still incapable of polling for updates, and require, at
best, API push of DS Records for promotion to TLD parent.
("We're looking into it ..." and "You should expect it by the end of year ..."
seems to be the most common, years-long excuses ... er ... promises I've gotten).
About a year ago, I'd submitted
"automation of DS Record submit to registrar/parent, integrated with 'new'
kasp/dnssec-policy support in bind"
https://gitlab.isc.org/isc-projects/bind9/-/issues/1890
So far, no visible progress.
Before bind's current, integrated approach, I'd done some sloppy scripting with
opendnssec, and it ended up being a fragile mess.
I can certainly can set up kludgy, async polling scripts &/or cronjobs to do the
same with bind; It seems so 1990s :-/ Just looking for something more integrated.
Short of the registrars getting a clue anytime soon, or moving to .CZ/.CH where
CDS/CDNSKEY polling seems uniquely doable ...
Has anyone here on-list figured out how to hook bind's internal signing process
to *trigger* and external script to exec those API pushes?
Also, input/comment from devs here, &/or @ #1890 would be appreciated.
___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
PGNet Dev wrote: > > Has anyone here on-list figured out how to hook bind's internal signing > process to *trigger* and external script to exec those API pushes? I have not, and I also want to be able to do this, and I also want scripting hooks for whenever any keys change so that I can stash them somewhere safer. Tony. -- f.anthony.n.finchhttps://dotat.at/ Rockall, Malin, Hebrides: Southwest veering west, 4 to 6, occasionally 7 at first. Rough, but slight or moderate in southeast Malin and southeast Hebrides. Rain with fog patches, showers later. Moderate or good, occasionally very poor at first. ___ 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
On 6/10/21 8:38 AM, Tony Finch wrote: I have not, and I also want to be able to do this, and I also want scripting hooks for whenever any keys change so that I can stash them somewhere safer. fyi, perhaps keep an eye on this: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 seems like a point solution to the more generic problem, but does touch on softhsm integration. proper process hooks should enable the option to stash where you want to -- fs, git, softhsm, hashicorp vault, h/w hsm, etc etc. ___ 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: RE: No more support for windows
On 09-Jun-21 18:46, Richard T.A. Neal wrote: > Evan Hunt wrote: > >>> My understanding is BIND will still run fine under WSL; it's only the >>> native Visual Studio builds that we're removing. >>> For people who want to run named on windows, WSL seems like the best way to >>> go. > Sadly no. To quote myself from an earlier email on this topic: > > There are two versions of WSL: WSL1 and WSL2. Development has all but ceased > on WSL1, but WSL1 is the only version that can be installed on Windows Server > 2019. > > Microsoft have not yet confirmed whether WSL2 will be available for Windows > Server vNext (Windows Server 2022, or whatever they name it). > > Even if WSL2 is made available for Windows Server 2022 it has some serious > networking limitations: it uses NAT from the host, so your Linux instance > gets a private 172.x.y.z style IP address, and that IP address is different > every reboot. Proxy port forwarding must therefore be reconfigured on every > reboot as well. > > Personally I'm comfortable with the decision that's been made and I > understand the logic. Saddened, like saying goodbye to an old friend, but > comfortable. > > Richard. As I suggested early on, it would be great if the tools could somehow be available as native binaries. Sounds like there's progress there - thanks Evan! As for running a BIND server, all things considered it seems to me that the simplest approach is to create a bare-bones VM running Linux. Run that on the windows server (use VMware, VirtualBox) If the only things running in that machine are named, a firewall, a text editor, logwatch, and backups, there's really not much effort in keeping that machine running. Just remember to do a distribution update once in a while (e.g. dnf update/apt-get, etc). You might want to keep SeLinux/Apparmor, but with no other services, it may not be worth the effort. You can tailor Linux distributions down to a very minimal set of services. It's often done for embedded applications. You can even do the backups by snapshoting the VM. You can update the zone files via UPDATE. You can update the config (and zone files if you like) in the VM, or via an exported directory from the Windoze host. (E.g. VirtualBox does this trivially.) This would completely eliminate the complexity of dealing with the Windows networking stack - the Linux machine (and named) just see an ethernet adapter (or two, or...) on the host's network. (Mechanically, the VM's "adapter" injects and retrieves raw ethernet packets into the driver stack very close to the wire.) No NAT or proxy (unless you want it, in which case it can be static.) And whatever kernel features/networking libraries ISC uses are just there - no porting. I haven't measured performance, but I do run my Linux machines in VirtualBox VMs (mostly hosted on a Linux server, but some on Windows). I haven't run into issues - but then I'm not a big operator. I do use CPUs (and IO) with hardware virtualization support. In any case, the workload on ISC would be zero - unless they choose to provide the VM (there are portable formats). That work might be something that someone who wants a Windows solution could afford to sponsor. The biggest part would be scripting packaging from the selected distro and a test system. Plus a bit of keeping it up-to-date. And documentation. Optionally, someone might want to do some configuration/performance tuning - but most of that is what ISC does anyway inside the VM. Again, the work would seem to be something that the Windows community could donate and/or sponsor. It might even be the case that ISC could use the same VM as part of its test suite - many CI engines are using that approach to get wide coverage with minimal hardware. (The CI folks, like GitHub Actions, GitLab, etc spin up a VM, install the OS and minimal packages, then run your tests.) I confess that this is a practical approach - it won't satisfy those who insist on a "pure" windows solution. (Though I bet if you looked inside their routers, storage, phone systems, and certainly cars there'd be Linux purring away under the hood...) Nor anyone who thinks that the status quo is ideal or that only a "no effort" solution is acceptable. Anyhow, it's not an attempt to start a religious war or to prolong the debate on what ISC does. It assumes BIND won't support windows, that WSL is imperfect, and that an alternative to complaining might be helpful... Feel free to s/Linux/(Solaris|FreeBSD|VMS|yourfavorite/g. I don't have a need for BIND (except the tools) under Windows, so I'm not volunteering to implement this. FWIW. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscrib
Re: No more support for windows
You might want to consider using the BIND9 docker image. With docker and kubernetes which has an internal load balancer you can run this on any Windows platform and don't need anything special. You point to the IP address of the kubernetes load balancer and it takes care of where to find the docker named image. This is separate from the utilities like dig. Setting up the configuration and the zones is a little more work but you won't need to worry about keeping uptodate on the Windows images. Danny On 6/10/21 10:19 AM, Timothe Litt wrote: On 09-Jun-21 18:46, Richard T.A. Neal wrote: Evan Hunt wrote: My understanding is BIND will still run fine under WSL; it's only the native Visual Studio builds that we're removing. For people who want to run named on windows, WSL seems like the best way to go. Sadly no. To quote myself from an earlier email on this topic: There are two versions of WSL: WSL1 and WSL2. Development has all but ceased on WSL1, but WSL1 is the only version that can be installed on Windows Server 2019. Microsoft have not yet confirmed whether WSL2 will be available for Windows Server vNext (Windows Server 2022, or whatever they name it). Even if WSL2 is made available for Windows Server 2022 it has some serious networking limitations: it uses NAT from the host, so your Linux instance gets a private 172.x.y.z style IP address, and that IP address is different every reboot. Proxy port forwarding must therefore be reconfigured on every reboot as well. Personally I'm comfortable with the decision that's been made and I understand the logic. Saddened, like saying goodbye to an old friend, but comfortable. Richard. As I suggested early on, it would be great if the tools could somehow be available as native binaries. Sounds like there's progress there - thanks Evan! As for running a BIND server, all things considered it seems to me that the simplest approach is to create a bare-bones VM running Linux. Run that on the windows server (use VMware, VirtualBox) If the only things running in that machine are named, a firewall, a text editor, logwatch, and backups, there's really not much effort in keeping that machine running. Just remember to do a distribution update once in a while (e.g. dnf update/apt-get, etc). You might want to keep SeLinux/Apparmor, but with no other services, it may not be worth the effort. You can tailor Linux distributions down to a very minimal set of services. It's often done for embedded applications. You can even do the backups by snapshoting the VM. You can update the zone files via UPDATE. You can update the config (and zone files if you like) in the VM, or via an exported directory from the Windoze host. (E.g. VirtualBox does this trivially.) This would completely eliminate the complexity of dealing with the Windows networking stack - the Linux machine (and named) just see an ethernet adapter (or two, or...) on the host's network. (Mechanically, the VM's "adapter" injects and retrieves raw ethernet packets into the driver stack very close to the wire.) No NAT or proxy (unless you want it, in which case it can be static.) And whatever kernel features/networking libraries ISC uses are just there - no porting. I haven't measured performance, but I do run my Linux machines in VirtualBox VMs (mostly hosted on a Linux server, but some on Windows). I haven't run into issues - but then I'm not a big operator. I do use CPUs (and IO) with hardware virtualization support. In any case, the workload on ISC would be zero - unless they choose to provide the VM (there are portable formats). That work might be something that someone who wants a Windows solution could afford to sponsor. The biggest part would be scripting packaging from the selected distro and a test system. Plus a bit of keeping it up-to-date. And documentation. Optionally, someone might want to do some configuration/performance tuning - but most of that is what ISC does anyway inside the VM. Again, the work would seem to be something that the Windows community could donate and/or sponsor. It might even be the case that ISC could use the same VM as part of its test suite - many CI engines are using that approach to get wide coverage with minimal hardware. (The CI folks, like GitHub Actions, GitLab, etc spin up a VM, install the OS and minimal packages, then run your tests.) I confess that this is a practical approach - it won't satisfy those who insist on a "pure" windows solution. (Though I bet if you looked inside their routers, storage, phone systems, and certainly cars there'd be Linux purring away under the hood...) Nor anyone who thinks that the status quo is ideal or that only a "no effort" solution is acceptable. Anyhow, it's not an attempt to start a religious war or to prolong the debate on what ISC does. It assumes BIND won't support windows, that WSL is imperfect, and that an alternative to complaining mi
cmdns.dev.dns-oarc.net oddness with windows 10 and bind
So I redone my windows bind setup on a new system and this bug may never get fixed but I wanted to post the oddness of this bug. Bind on New PC as servers 127.0.0.1 for dns on that system cmdns.dev.dns-oarc.net reports fine except for IPv6 test OK I then have two PC's as clients to this DNS bind server 192.168.255.62 and 192.168.53.2 the internet works fine DNS seems to work fine but testing at cmdns.dev.dns-oarc.net shows some failed tests for IPv4. And it gets odder if on that PC I remove 192.168.255.62 and 192.168.53.2 and put in 127.0.0.1 setup bind with forwarder only 192.168.255.62 and 192.168.53.2 then run cmdns.dev.dns-oarc.net it shows as fine! I just don't get it? ___ 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
PGNet Dev wrote: > > fyi, perhaps keep an eye on this: > > https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 hmm, maybe, but it's my Spock eye with a single arched eyebrow Tony. -- f.anthony.n.finchhttps://dotat.at/ Thames, Dover: Southwest 4 to 6. Smooth or slight becoming slight, occasionally moderate later in Thames. Fog banks. Moderate to very poor. ___ 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
On 6/10/21 1:55 PM, Tony Finch wrote: PGNet Dev wrote: fyi, perhaps keep an eye on this: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 hmm, maybe, but it's my Spock eye with a single arched eyebrow hehe. well, I _did_ just suggest "keep an eye on it", not "wait for it" or "hold your breath" ! ;-) ___ 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
