ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-10-16T16:52:05Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1272Error loading zone with TXT record at end2019-10-16T16:52:05ZGhost UserError loading zone with TXT record at endWe are running BIND 9.14.2. With an existing zone if we add a TXT record to the end of the zone file it will not load with the error: failed: CNAME and other dataWe are running BIND 9.14.2. With an existing zone if we add a TXT record to the end of the zone file it will not load with the error: failed: CNAME and other datahttps://gitlab.isc.org/isc-projects/kea/-/issues/956investigate scenario with two servers sharing lease database and pools2021-06-18T10:47:35ZFrancis Dupontinvestigate scenario with two servers sharing lease database and poolsClearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code an...Clearly it is a pretty bad setup but it seems to be used by some customers so it is a bit late to say it is not supported so:
- analyze the behavior of the current code
- decide what should be the lease worst behavior
- update code and documentationKea1.9-backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/955fixing repo_url in hammer.py2019-10-16T07:06:19ZWlodzimierz Wencelfixing repo_url in hammer.pykea1.7.1Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/59Add support for DDNS updates to non-standard port2020-02-13T13:44:39ZhlmtreAdd support for DDNS updates to non-standard port---
name: DDNS update to non-standard port
about: Add support for sending to non-standard DNS port (not 53) for DDNS updates
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP v...---
name: DDNS update to non-standard port
about: Add support for sending to non-standard DNS port (not 53) for DDNS updates
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
**Is your feature request related to a problem? Please describe.**
Currently it is impossible to specify the port to send DNS updates to in the `dhcpd.conf` file for a zone.
**Describe the solution you'd like**
Add the ability to specify the port to send the DDNS update notice to. `nsupdate` can currently do this.
**Describe alternatives you've considered**
I ended up setting up the primary DNS server on a secondary address on the standard port so DDNS updates could be performed. I also considered using `iptables` to remap the outgoing request.
**Additional context**
Example of what relevant `dhcpd.conf` might look like:
```
zone lan.my.example.com {
primary 192.168.6.4;
port 5300;
key dnsupdate;
}
```
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs? Can't contribute financially at the moment.
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
**Yes, absolutely.**
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.
hellmitre@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1269A DKIM RR added in an inline-signing zone is not served2019-10-15T16:59:17ZJean-Christophe ManciotA DKIM RR added in an inline-signing zone is not servedUbuntu 19.10
bind9 9.15.4
opendkim 2.11.0~alpha-12
bind9 domain configuration:
```
zone "exmaple.com"
{
type master;
file "/etc/bind/db.example.com";
// Publishing and activating dnssec keys
auto-dnssec maintain;
// Usi...Ubuntu 19.10
bind9 9.15.4
opendkim 2.11.0~alpha-12
bind9 domain configuration:
```
zone "exmaple.com"
{
type master;
file "/etc/bind/db.example.com";
// Publishing and activating dnssec keys
auto-dnssec maintain;
// Using inline signing
inline-signing yes;
...
```
The private key & RR have been generated with:
```
opendkim-genkey -s mail -d example.com -h <algorithm>
```
The added record **begins** with:
```
mail._domainkey IN TXT ( "v=DKIM1; h=<algorithm>; k=rsa; "
...
```
I followed all the steps outlined in the official bind9 documentation regarding "[Adding DKIM Records with BIND9](https://kb.isc.org/docs/aa-00725)"/**Directly Editing your DNS Zone**.
Checking the result after successfully thawing the server:
```
# named-checkzone -D -f raw -o - example.com db.example.com.signed|grep DKIM
zone example.com/IN: loaded serial 2019101515 (DNSSEC signed)
OK
mail._domainkey.example.com. 604800 IN TXT "v=DKIM1; h=<algorithm>; k=rsa; "
...
```
However it does not serve the DKIM RR on the **primary** server:
```
# dig @localhost TXT example.com|grep DKIM
#
```
On top of that issue, the **secondary** is not aware of the change at all despite the zone transfer:
```
15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaa w.x.y.z#54219 (example.com): transfer of 'example.com/IN': IXFR started (serial 2019092407 -> 2019101515)
15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaa w.x.y.z#54219 (example.com): transfer of 'example.com/IN': IXFR ended: 1 messages, 14 records, 1412 bytes, 0.001 secs (1412000 bytes/sec)
15-Oct-2019 16:55:14.078 xfer-out: info: client @xbbbbbbbbbbbb w.x.y.z#58529 (example.com): transfer of 'example.com/IN': AXFR started (serial 2019101515)
15-Oct-2019 16:55:14.078 xfer-out: info: client @xbbbbbbbbbbbb w.x.y.z#58529 (example.com): transfer of 'example.com/IN': AXFR ended: 1 messages, 36 records, 2906 bytes, 0.001 secs (2906000 bytes/sec)
```
```
# named-checkzone -D -f raw -o - example.com db.example.com.signed|grep DKIM
zone example.com/IN: loaded serial 2019092407 (DNSSEC signed)
OK
#
# dig @localhost TXT example.com|grep DKIM
#
```
The loaded zone unexpectedly matches the old one.
Am I missing something?https://gitlab.isc.org/isc-projects/dhcp/-/issues/58undocumented "option routers false;" usefull - should be documented2019-10-16T16:45:32ZGhost Userundocumented "option routers false;" usefull - should be documented* isc-dhcpd-4.3.5
* dhcpd.conf
Dear ISC-Maintainers,
in my network there is one single host named "gw" that itself is a gateway. I could give it a static ip - but i want it to be a normal DHCP-Client. But sending a standard-route to "...* isc-dhcpd-4.3.5
* dhcpd.conf
Dear ISC-Maintainers,
in my network there is one single host named "gw" that itself is a gateway. I could give it a static ip - but i want it to be a normal DHCP-Client. But sending a standard-route to "gw" makes no sense, more than this, it confuses this gateway routing ip-traffic back to the default-router used in the dhcpd-network. So i searched for a possibility to supress isc-dhcpd from sending a router-ip to this special host. This worked:
option routers 192.168.1.1;
[... hundred hosts ...]
host gw {
option host-name "gw";
hardware ethernet b8:27:eb:dd:fa:77;
fixed-address gw;
**option routers false;**
}
This is very usefull -- but undocumented, please document this in man dhcpd.conf.
Andreashttps://gitlab.isc.org/isc-projects/bind9/-/issues/1268Allow ANY queries for localhost only2019-10-15T23:31:12ZVicky Riskvicky@isc.orgAllow ANY queries for localhost onlyfeature request emailed to info@ from d.stussy@yahoo.com:
re: version 9.15.4
RFC 8482 suggested deprecation of the "ANY" qtype for DNS queries (or minimal responses). Please do not remove the code that handles this.
HOWEVER, as "ANY" q...feature request emailed to info@ from d.stussy@yahoo.com:
re: version 9.15.4
RFC 8482 suggested deprecation of the "ANY" qtype for DNS queries (or minimal responses). Please do not remove the code that handles this.
HOWEVER, as "ANY" queries are used for testing and such, I do suggest the following additional configuration directive for "/etc/named.conf" (or equivalent): "allow-query-any[-v6] { };", where the default list is set to "localhost;" (or perhaps "localnets;"). This way, system administrators can still test their authoritative server(s) for "all" DNS records for a label without the general public having similar access and without having to loop though all record types. Any query not matching the give source(s) can still get a "refused" rcode, a minimal response, a special HINFO response, etc., as per other directives.
I realize that by using different views based on the source query address, various other configurations could simulate the above. However, I believe that the directive suggested is the most straightforward. I am surprised that this wasn't previously done in the 9.14/9.15 series (or earlier).https://gitlab.isc.org/isc-projects/stork/-/issues/32CD (Continuous Delivery) - develop automated deployment to stork.lab.isc.org2020-06-22T08:29:23ZTomek MrugalskiCD (Continuous Delivery) - develop automated deployment to stork.lab.isc.orgDuring exec discussions about Stork, there was a request from Sales team to have something useful for a kind of demo system. We're still several months away from having anything useful enough to be users worthy, but we should start think...During exec discussions about Stork, there was a request from Sales team to have something useful for a kind of demo system. We're still several months away from having anything useful enough to be users worthy, but we should start thinking about our processes to deploy master (or perhaps selected builds) to stork.lab.isc.org.
The goal of this issue to came up with:
1. some rules proposal when to deploy updated code (every commit to master, every commit that passed jenkins tests, perhaps only manually?)
2. develop scripts that will make the deployment possible.Stork-0.3Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/31Need some basic documentation2019-10-14T18:35:09ZTomek MrugalskiNeed some basic documentationThis issue covers two aspects:
1. pick the right documenting tool
2. come up with some initial skeleton.
Note there are two .rst (sphinx) files in docs/, but that doesn't imply we need to use Sphinx. We can use something else, if we fi...This issue covers two aspects:
1. pick the right documenting tool
2. come up with some initial skeleton.
Note there are two .rst (sphinx) files in docs/, but that doesn't imply we need to use Sphinx. We can use something else, if we find it more useful. In particular, goswagger supposedly has some documentation generation capabilities that we could use. However, keep in mind that the API documentation is not the only thing that we want. There should be additional elements (software overview, current capabilities, installation instructions, etc)https://gitlab.isc.org/isc-projects/stork/-/issues/30CI: setup jenkins (or gitlab ci) env to run unit-tests automatically2019-10-24T08:12:46ZTomek MrugalskiCI: setup jenkins (or gitlab ci) env to run unit-tests automaticallyThese are still very early days. Let's see if there is anything we can deploy right now to kick off the CI process.These are still very early days. Let's see if there is anything we can deploy right now to kick off the CI process.Stork-0.1https://gitlab.isc.org/isc-projects/stork/-/issues/29CI: pre-commit git hook2019-12-27T17:30:26ZTomek MrugalskiCI: pre-commit git hookWe need a hook that will put the [#issue number] in the commit message automatically. @fdupont may have such a script already.We need a hook that will put the [#issue number] in the commit message automatically. @fdupont may have such a script already.Stork-0.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/28Coding guidelines2019-10-31T13:00:31ZTomek MrugalskiCoding guidelinesWe need coding guidelines for the Stork project written.We need coding guidelines for the Stork project written.Stork-0.1Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/57Fix reference count leaks2020-01-14T08:15:10ZThomas MarkwalderFix reference count leaksFix leaks reported in #44.Fix leaks reported in #44.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/954Support of google tests release 1.10.02019-12-12T11:23:25ZFrancis DupontSupport of google tests release 1.10.0kea1.7.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/27Create user documentation for Stork 0.12019-11-06T08:41:18ZMarcin SiodelskiCreate user documentation for Stork 0.1All features implemented for Stork 0.1 should be properly documented. This includes the details about installation of Stork, Stork Agent, UI etc. It should also include description of authentication, authorization, database administratio...All features implemented for Stork 0.1 should be properly documented. This includes the details about installation of Stork, Stork Agent, UI etc. It should also include description of authentication, authorization, database administration and everything else that counts for the administrator.Stork-0.1https://gitlab.isc.org/isc-projects/stork/-/issues/26Create stub stork agent with the code generated by grpc.2019-10-24T07:55:58ZMarcin SiodelskiCreate stub stork agent with the code generated by grpc.The Stork agent will be running on the remote machine and "talk" to the services running there. Initially the Stork agent will be installed manually by the administrator. The server will use grpc to communicate with the agent. This ticke...The Stork agent will be running on the remote machine and "talk" to the services running there. Initially the Stork agent will be installed manually by the administrator. The server will use grpc to communicate with the agent. This ticket creates the stub agent implementation and returns basic information about itself, e.g. its version.Stork-0.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/25Users: manage users by the user with administrator's privileges.2019-12-02T16:09:20ZMarcin SiodelskiUsers: manage users by the user with administrator's privileges.Initially, we will have two roles in the system: superuser and the regular user. The super user should be able to manage the user information: add new user with a generated password. The user should be able to log in to the system and be...Initially, we will have two roles in the system: superuser and the regular user. The super user should be able to manage the user information: add new user with a generated password. The user should be able to log in to the system and be prompted to change the password.Stork-0.2Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/24Services: listing, add new service, fetch a service in both frontend and the ...2019-12-23T11:21:38ZMarcin SiodelskiServices: listing, add new service, fetch a service in both frontend and the backend.We have to create a view with a list of services and with a selected service. We have to be able to specify new service information and store it in the db. The operational status of the service should be available.We have to create a view with a list of services and with a selected service. We have to be able to specify new service information and store it in the db. The operational status of the service should be available.Stork-0.3https://gitlab.isc.org/isc-projects/stork/-/issues/23Machines: listing, add new machine, fetch a machine in both frontend and the ...2019-10-31T17:33:41ZMarcin SiodelskiMachines: listing, add new machine, fetch a machine in both frontend and the backend.We have to create a view with a list of machine and with a selected machine. We have to be able to specify new machine information and store it in the db. The operational status of the machine should be available.We have to create a view with a list of machine and with a selected machine. We have to be able to specify new machine information and store it in the db. The operational status of the machine should be available.Stork-0.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/22Integrate sessions mechanism with the backend and connect to the logging page2019-11-04T21:44:11ZMarcin SiodelskiIntegrate sessions mechanism with the backend and connect to the logging pageWe have a stub logging page, but we now have to enable logging in the database and integrate it with the sessions mechanism via scs. This will require adding sessions to the goswagger spec and appropriate action to create/refresh the ses...We have a stub logging page, but we now have to enable logging in the database and integrate it with the sessions mechanism via scs. This will require adding sessions to the goswagger spec and appropriate action to create/refresh the session.Stork-0.1