concerning the following entities and the many other entites that
provide dns services:
cesidian;
unifiedroot;
public-root;
opennic;
1.
what is considered better practice for use with unbound:
Best practise is _not_ to use alternative roots.
1.1
merging the above individually provided named.cache entries into one
file with the existing iana root-servers.net named.cache; or
1.2
manually adding forward/stub zone entries into the .conf file instead to
resolve other domains that would normally be un-resolvable?
This.
2.
why ?
Because they provide conflicting namespaces (root vs. alt_root, but also
alt_root vs. alt_root), so you need to pick which one you will be using
anyway.
But I would like to repeat again. Don't use alt_roots, they don't play well
(and never will) with unified DNS tree, and there's really no strong reason
(no reason at all from my POV) for using them.
concerning the following entities and the many other entites that
provide dns services:
cesidian;
unifiedroot;
public-root;
opennic;
1.
what is considered better practice for use with unbound:
Best practise is _not_ to use alternative roots.
if i only incorporate a named.cache hint file from the traditional root
servers, without additional stub/forward entries in unbound.conf, will i
still be able to resolve for example new nation TLD's such as .ti .ko
and .uu ?
will i be able to resolve gTLD's such as .satan (which cesidian can)
.africa (which namespace can) or .geek (which opennic can) ?
no, you will not. not until those strings are properly vetted.
the rational for private name space is varied, some justification may be
found in SSAC-009 www.icann.org/en/groups/ssac/alt-tlds-roots-report-31mar06-en.pdf
mixing public and private namespace is problematic. you -can- do it, but do you
have a compelling case to do so?