Hi. Firstly, a big thank-you for knotd.
I've been writing some code for automatic configuration of DNS
delegations, including dnssec.
It's been very straightforward with knot. The code is very clean, and
the documentation extensive.
Now my request:
Your control programs seem to assume that the user is running knotc or
keymgr and generating commands interactively or via a script.
Would it be possible to expose all of the knotc and the keymgr API
functions into a separate library, like libknotd-ctrl, plus a set of
header files?
At the moment I'm forking off external shell scripts from my program,
and that works fine, but if I could call and link these control
functions direct from my own code it would be great. It's probably
possible already with some automake magic, but it's not easy for someone
of my limited skills level.
The code already exists, it'd just be some additional build steps AFAICS.
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campai…>
Hiya,
trying to get our knot dns server (FreeBSD pkg, 2.8.1) to export
prometheus statistics.
I found https://github.com/ghedo/knot_exporter, which looks promising
(and I found that knot-resolver has this all built in, but this doesn't
help me :-/ ).
So, I've installed the required python modules, and when I start
the knot_exporter (with the right paths and everything) it complains
to me:
$ /tmp/knot_exporter --web-listen-port 4041 --knot-library-path ...
Traceback (most recent call last):
File "/tmp/knot_exporter", line 489, in <module>
args.knot_socket_timeout,
File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 24, in register
names = self._get_names(collector)
File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 64, in _get_names
for metric in desc_func():
File "/tmp/knot_exporter", line 434, in collect
for zone, zone_data in zone_stats["zone"].items():
KeyError: 'zone'
so, I read the manual, and it says that this should be sufficient:
template:
- id: default
storage: /usr/local/etc/dnsmgmt/data/CA/knot
disable-any: true
acl: [ acl_transfer, acl_notify ]
global-module: mod-stats
with or without
mod-stats:
- id: default
request-protocol: on
server-operation: on
edns-presence: on
flag-presence: on
response-code: on
reply-nodata: on
query-type: on
... but it does not seem to make a difference.
So - if one of you has a working knot-server knot.conf that exports data
to prometheus, can you share it?
thanks,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I am trying to add wildcard static hints to catch all local domains like
below. But does not seem to work.
hints['nextcloud.local'] = '127.0.0.1' # This works fine
hints['*.local'] = '127.0.0.1'
hints['.local'] = '127.0.0.1'
DNSMasq supports this like https://stackoverflow.com/a/22551303
Is there way to do this in knot?
Thanks,
Bala
Hi,
we're using knot as a bump-in-the-wire DNSSEC Signer. The setup is as
follows:
BIND9(unsigned) -> AXFR -> knot(signing) -> AXFR -> BIND9(signed)
The zone starts out with a low serial like 10 or 11. knot has a
serial-policy: unixtime for the zones.
Problem is, whenever an update is pushed the serial number is
decreased again from unixtime back to the original serial which
prevents the zone from propagating to the slaves.
Example (test zone):
template:
- id: slave-dnssec-ecdsap256
storage: "/var/lib/knot/slave"
file: "%s.zone"
zonefile-load: difference
dnssec-signing: on
dnssec-policy: ecdsap256
master: ns1_signer
notify: ns1
acl: acl_ns1
zone:
- domain: xn--78jubwhb.xn--q9jyb4c
template: slave-dnssec-ecdsap256
serial-policy: unixtime
Here is an example where first a manual "zone-sign" is done to update
the serial to current unixtime (12 -> 1559298292) and after that the
zone is transferred in again which results in a serial decrease
(1559298292 -> 13).
[xn--78jubwhb.xn--q9jyb4c.] control, received command 'zone-sign'
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, dropping previous signatures, re-signing zone
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:24:52
[xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 12 -> 1559298292
[xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 1559298292
[xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, started, serial 1559298292
[xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, finished, 0.00 seconds, 1 messages, 1819 bytes
[xn--78jubwhb.xn--q9jyb4c.] notify, incoming, remote 176.9.75.248@9104, received, serial 13
[xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, remote serial 13, zone is outdated
[xn--78jubwhb.xn--q9jyb4c.] IXFR, incoming, remote 176.9.75.248@53, receiving AXFR-style IXFR
[xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, starting
[xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, finished, 0.00 seconds, 1 messages, 321 bytes
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:25:21
[xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, zone updated, 0.10 seconds, serial 12 -> 13
[xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 1559298292 -> 13
[xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 13
How to prevent this? We want knot to always use the current unixtime
for the zone.
Best Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Dobrý den,
zkouším rozjet Knot DNS, ovšem narazil jsem na problém - knotd mi
neposlouchá na UDP portu. Upozornil mě na to nástroj http://dnsviz.net.
Poradí mi někdo prosím, co by mohlo být špatně a jak z toho ven?
Mám podezření na modul *noudp*, ovšem marně se snažím dohledat nějaké
podrobnější informace, popisující jak vůbec moduly fungují a jak se s
nimi pracuje. Knot jsem instaloval z repositáře
https://deb.knot-dns.cz/knot-latest.
knotd (Knot DNS), version 2.8.1; Debian 9
Děkuji.
--
S pozdravem
Ondřej Budín
Hi there,
while trying to understand the algorithm employed in the
`find_best_view` function in the geoip module, I started wondering
whether this line is in there intentionally:
https://gitlab.labs.nic.cz/knot/knot-dns/blob/4015475b0d3e11c0bd6fcac8aceb6…
I am still trying to understand how this works with the actual geo data,
but here is a test case using the subnet mode that yields slightly
surprising results:
Using a geoip config like this for zone example.com:
bar.example.com:
- net: 127.0.0.0/8
A: 9.9.9.9
- net: 192.0.0.0/8
A: 1.1.1.1
- net: 192.168.0.0/16
A: 4.4.4.4
- net: 192.168.1.0/24
A: 8.8.8.8
If I query bar.example.com from 192.168.1.X, I get 4.4.4.4, which is
suprising because it is neither the most nor the least specific item.
The binary search returns the most specific one (8.8.8.8), which is sort
of what I would expect. However, above line immediately takes the `prev`
item without checking for `view_strictly_in_view`. Without the above
line, the whole function returns the most specific item, as I would expect.
Please note that this is mostly an intuition atm, as I have not yet had
the time to set up a similar test case for real geo data (which uses the
same algorithm). But I figured that someone more familiar with the code
might have enough context to tell whether this is correct or not or what
a suitable fix might look like.
Thanks a bunch,
Conrad