>> 2.) Testing (read: does it compile and work) on AMD64. > > amd64 is easy, better questions are things like does it build/work on vax > (gcc2, no shared libs), does it work on "unusual" arch like hppa, etc.
I agree, however I cannot help with these arches as I do not have access to them. Anyone does? >> What to do with the BIND tools (dig/host/nslookup)? > > I don't think drill is quite a sufficient replacement for dig yet, > and the other tools are certainly still used and I'd expect to find them > in the base OS. So at this point I think they should stay. Clear on this point! I will loo >> From unbound-anchor.8 I understand that unbound-anchor can be run from the >> command line, or run as part of startup scripts _before_ the actual (unbound) >> DNS server is started. So there is no need for DNS. Proposal therefor is to >> run unbound-anchor automatically before starting the unbound daemon (rc_pre in >> unbound rc-script). > > This (i.e. connecting out to https://data.iana.org from the system startup > scripts) should *not* happen by default even if unbound is enabled. There > would need to be a separate option controlling this. This is tricky! Using unbound-anchor - as a function of unbound_flags (rc.conf) and some 'magic' in the unbound rc.d-script - is the easy part. It is possible to use 'auto-trust-anchor-file' (unbound.conf) as default. However, when there is no anchor-file a built-in value is used. Not a pretty solution. Now the hard part: How do we make unbound.conf listen to unbound_flags (rc.conf)? Any ideas or alternative solutions? -- Bjvrn Ketelaars
