[yadifa-users] yadifa 2.0.6 observations and questions
anandb at ripe.net
Tue Apr 21 03:53:54 CEST 2015
Hello yadifa developers,
I'm examining version 2.0.6, and I have several observations and questions.
1. The yadifad.conf man page appears to be out of date, because it is
showing a version string of 2.0.4. I suspect that this should have been
auto-generated to match the released version, but it seems to be
hard-coded. It would be good if this matched the release version. I
suspect that similarly, the values of "pidfile", "datapath" and so on
are hard-coded, rather than generated from a template using the options
passed to configure. Could you maybe turn the man page into a template,
and have it filled with appropriate values for a target system?
2. The yadifad.conf man page doesn't document the <nsid></nsid> container.
3. yadifa responds to ch/txt/version.bind, ch/txt/version.server and
ch/txt/version.yadifa queries. However, it does not respond to
ch/txt/hostname.bind or ch/txt/id.server.
4. yadifa responds to NSID in a regular query in the IN class, but does
not respond to NSID for a query for ch/txt/version.bind. Other name
servers do respond with NSID consistently, so yadifa should too.
5. It is not clear from the reading of the yadifad.conf man page which
options in <main> are mandatory, and which ones not. Also, if a setting
is optional, then what does it default to?
6. In the yadifad.conf man page, I see some strings enclosed in double
quotes, but other values are unquoted. The syntax of the yadifa
configuration isn't documented, and it's impossible to figure out what
needs quoting, and what doesn't. Some settings appear to be booleans,
some strings, some integers, some are references to ACLs.
7. In the ACLs, I'm confused by "transferrer" and "admins". What do
8. If a zone is configured as a slave, and I define the "file" setting
for it, I expect the zone to be written to that file after XFR. However,
I can't find the zone file at that location. The only thing is see is a
binary form of the zone file in the "xfr" directory.
9. The "port" setting seems completely redundant. I think it can be
removed, and its function merged into the "listen" setting. The listen
setting could default to "0.0.0.0 port 53".
10. The setting "axfr-maxrecordbypacket" has a default of 0. I can guess
what this means (cram as many answers as possible in every packet), but
could this please be documented clearly?
11. There are "allow-transfer" and "allow-notify" settings in <main>, so
I guess they are global. However, if I want different per-zone
"allow-transfer" and "allow-notify" settings, is this possible? There is
another example yadifad.conf file in the source distribution that
suggests this is possible, but I think this should all be explicitly
shown in the man page, not in an example file. The man page is where an
operator normally looks for detailed information about all the settings.
12. yadifa has several loggers. Is it possible to describe what each
logger actually logs? More importantly, for a user, it doesn't make
sense to enable every logger, because that produces too much output.
Could you describe in detail in the man page what each logger logs? And
provide a sensible suggestion for which loggers, and at what level, an
operator should enable to get reasonable logging for normal operations?
I realise that a developer might want to see every log of every
operation in the server, but for an operator, this is overkill.
13. The "uid" and "gid" settings are perhaps oddly named. To me, uids
and gids are numeric. More appropriate names would be "user" and
"group". Also, if the operator only specifies the user, but not the
group, could yadifa default the group to that user's primary group?
14. The setting "max-tcp-queries" seems odd. I suspect it is meant to be
"max-tcp-connections", because a client can make one TCP connection and
send several queries down this connection. If the intention was really
for the maxinum number of parallel connections, could this setting name
be changed please?
15. The setting "edns0-max-size" has a typo ("annot" instead of
"cannot"). Additionally, the upper limit is off by one. The comment
there says it cannot be bigger than 65535, but surely that should be
65536, isn't it? a UDP packet can be 65536 bytes in size (although of
course the word representing this size will be all ones, ie 65535).
16. The "statistics" option doesn't say exactly what statistics yadifa
will gather and report. It would be good to know this.
17. In the example channels, there's a syslog channel with arguments
"USER,CRON,PID". What does this mean? It doesn't make sense to me.
18. The "yadifa" control program isn't well-documented. I tried to use
it to signal a running yadifad daemon, but my test yadifad is running on
port 54, and I don't know how to tell yadifa to use a different port.
Also, it seems to have a config file, but the man page doesn't say what
the default location of this file is, or what it should contain.
Actually, this is an interesting question. Other DNS servers, such as
Knot and NSD, allow defining the control socket or address in their
config file. Then, the control client (knotc and nsd-control) can be
given the same config file as the server, and it will fish out the
control parts, and contact the appropriate server. This allows me to do:
knotc -c conf1.conf reload
knotc -c conf2.conf reload
and reload 2 instances of Knot running on the same server. I can do the
same with NSD, so I won't repeat the example.
If I am to run yadifa, I will almost certainly need to run at least 2
copies on my servers, and will need a clean way to signal each of them
for things like configuration reload, or to rotate log files.
I guess this is enough auditing for now :) Look forward to responses soon.
More information about the yadifa-users