... | ... | @@ -57,7 +57,7 @@ This is a bit more than 'monitoring' because it also requires some reading and a |
|
|
| 3.1 | Software update status | look up (presumably at ISC) whether the application software branch is currently supported (Stable, Extended Support, Development, EOL) and report what the current/latest version on the branch is. | | 2 |
|
|
|
| 3.2 | Software updater | This was REMOVED from the initial requirements list because it seems like it is too complicated to do it well for the wide variety of deployment environments users have. | | out of scope for 1.0 |
|
|
|
| 3.3 | Configuration variance | report on running configuration parameters that are non set to their default values. This could consist of a filter on the configuration from the view in 1.8 that shows parameters that have a default value, where the active setting is different from the default. (requested by support for troubleshooting) | | 2 |
|
|
|
| 3.4 | Log viewer| view log of monitored servers of significant events since (some limited size). if possible, include platform logs (e.g. platform restarts, OS updates...) and stork application logs. This is envisioned initially as a fairly simple display of the log file on an individual server. This is not a massive database of historical logs with analysis. | | |
|
|
|
| 3.4 | Log viewer| view log of monitored servers of significant events since (some limited size). if possible, include platform logs (e.g. platform restarts, OS updates...) and stork application logs. This is envisioned initially as a fairly simple display of the log file on an individual server. This is not a massive database of historical logs with analysis. | | 1 |
|
|
|
| 3.5 | Log analysis| | | >1 |
|
|
|
| 3.5 | Log alerting | alerting when specific words appear in the log | | >1 |
|
|
|
|
... | ... | @@ -67,12 +67,12 @@ This is a list of things that are not strictly monitoring. Putting them on a sep |
|
|
|
|
|
| # | Tool | Details | Feasibility | Release or GL#? |
|
|
|
| ------ | ------ | ------ | ------ | ------ |
|
|
|
| 4.1 | Devices database | List of devices that have appeared on the network at some point in the past. We may want a knob to configure how long to save this information for. The idea is to retain information associated with a given MAC address, even if it does not have a current valid lease, so that when it next gets a lease, we have this other information about it. Ultimately, we will want to store additional information with each lease (eg. user ID - things that we look up in another database at the time and associate with the dhcp lease). This should be possible both on a per-server basis and on a global basis. | | |
|
|
|
| 4.2 | Failover test | no idea what this could consist of, but it is a common request, how to test failover. what we need is something that will reassure the admin that failover is 'ready and working' | | |
|
|
|
| 4.3 | Relay drill down | The user wants to know what relay the client is behind. See all requests that came through a specific relay. If all we have is leases per relay, that is ok. | | |
|
|
|
| 4.4 | Clients refusing offers | See all addresses declined by clients - troubleshooting | | |
|
|
|
| 4.1 | Devices database | List of devices that have appeared on the network at some point in the past. We may want a knob to configure how long to save this information for. The idea is to retain information associated with a given MAC address, even if it does not have a current valid lease, so that when it next gets a lease, we have this other information about it. Ultimately, we will want to store additional information with each lease (eg. user ID - things that we look up in another database at the time and associate with the dhcp lease). This should be possible both on a per-server basis and on a global basis. | | >1 |
|
|
|
| 4.2 | Failover test | no idea what this could consist of, but it is a common request, how to test failover. what we need is something that will reassure the admin that failover is 'ready and working' | | >1 |
|
|
|
| 4.3 | Relay drill down | The user wants to know what relay the client is behind. See all requests that came through a specific relay. If all we have is leases per relay, that is ok. | | >1 |
|
|
|
| 4.4 | Clients refusing offers | See all addresses declined by clients - troubleshooting | | 1 |
|
|
|
| 4.5 | | | | |
|
|
|
| 4.6 | device fingerprinting | options requested/provided?, incl pxe file location. It is also important to know the order in which the options were requested, so this will probably require a Kea hook. | | |
|
|
|
| 4.6 | device fingerprinting | options requested/provided?, incl pxe file location. It is also important to know the order in which the options were requested, so this will probably require a Kea hook. | | >1 |
|
|
|
|
|
|
|
|
|
## BIND Status and Activity
|
... | ... | @@ -80,14 +80,14 @@ Most BIND 9 users have added BIND 9 to their existing fault monitoring systems b |
|
|
|
|
|
| # | Feature | Details | Feasibility | Release or GL#? |
|
|
|
| ------ | ------ | ------ | ------ | ------ |
|
|
|
| 5.1 | Zone list | human-readable list of zones, sortable by zone name, time of last update (this might be the default sort), zone size? signing status (signed/unsigned/expired?), #RRs. 'dynamic' or 'traditional' zone files | | |
|
|
|
| 5.2 | Zone xfr status | See current SOA record, monitor notifies, time since last xfer/ixfr, size, source of transfer. If there is any way to see the time it took for the transfer to become effective in the server, that would be ideal. | | |
|
|
|
| 5.3 | Zone xfr performance | See current SOA record, monitor notifies, time since last xfer/ixfr, size, source of transfer. If there is any way to see the time it took for the transfer to become effective in the server, that would be ideal. You want to know, how dynamic a zone is. How often you are getting updates for the zone, how large are the updates, etc. How much is the transfer traffic impacting the traffic, and which are the zones that are causing the problem.| | |
|
|
|
| 5.4 | Zone/rr signing status | DNSSEC details, key information, signature validity period | | |
|
|
|
| 5.5 | Zone/rr signing performance | monitoring where BIND is in signing and resigning new or updated zones, both the status and time it takes to complete the signing operation. I realize this is potentially very detailed and complicated, but think of the use case where an auth publisher has a few very large zones - how can they track their signing process? | | |
|
|
|
| 5.6 | Query activity | (queries per second received and answered), with some time series so you can identify changes from the usual pattern, TOD patterns. | | |
|
|
|
| 5.7 | RPZ reporting | logging of RPZ 'matches', with the name of the RPZ, name of the answer zone and action taken - rewrites, nxdomain, etc and counters (eg. 15 minute intervals). This may require log analysis. This for the purpose of proving to management that the RPZ service is worthwhile and impactful. | | |
|
|
|
| 5.8 | RPZ client reporting | log of clients that are presumably infected based on their DNS requests for malware zones. | | |
|
|
|
| 5.1 | Zone list | human-readable list of zones, sortable by zone name, time of last update (this might be the default sort), zone size? signing status (signed/unsigned/expired?), #RRs. 'dynamic' or 'traditional' zone files | | 1 |
|
|
|
| 5.2 | Zone xfr status | See current SOA record, monitor notifies, time since last xfer/ixfr, size, source of transfer. If there is any way to see the time it took for the transfer to become effective in the server, that would be ideal. | | >1 |
|
|
|
| 5.3 | Zone xfr performance | See current SOA record, monitor notifies, time since last xfer/ixfr, size, source of transfer. If there is any way to see the time it took for the transfer to become effective in the server, that would be ideal. You want to know, how dynamic a zone is. How often you are getting updates for the zone, how large are the updates, etc. How much is the transfer traffic impacting the traffic, and which are the zones that are causing the problem.| | >1 |
|
|
|
| 5.4 | Zone signing status | DNSSEC details, key information, signature validity period | | 1 |
|
|
|
| 5.5 | Zone/rr signing performance | monitoring where BIND is in signing and resigning new or updated zones, both the status and time it takes to complete the signing operation. I realize this is potentially very detailed and complicated, but think of the use case where an auth publisher has a few very large zones - how can they track their signing process? | | 1 |
|
|
|
| 5.6 | Query activity | (queries per second received and answered), with some time series so you can identify changes from the usual pattern, TOD patterns. | | 1 |
|
|
|
| 5.7 | RPZ reporting | logging of RPZ 'matches', with the name of the RPZ, name of the answer zone and action taken - rewrites, nxdomain, etc and counters (eg. 15 minute intervals). This for the purpose of proving to management that the RPZ service is worthwhile and impactful. The user wants to know how much of an impact (each RPZ zone) is having. | | 1 |
|
|
|
| 5.8 | RPZ client reporting | log of clients that are presumably infected based on their DNS requests for malware zones. | | >1 |
|
|
|
|
|
|
|
|
|
## BIND Performance Details
|
... | ... | |