Maintained by: NLnet Labs

[Unbound-users] named.cache & .conf setup best practices

bmanning at vacation.karoshi.com
Tue May 28 15:05:54 CEST 2013


On Tue, May 28, 2013 at 10:45:01PM +1000, shmick at riseup.net wrote:
> hello,
> OndEej SurC=:> On Tue, May 28, 2013 at 12:03 PM, shmick at riseup.net <shmick at riseup.net>wrote:> >> hello list,>>>> 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 rootservers, without additional stub/forward entries in unbound.conf, will istill be able to resolve for example new nation TLD's such as .ti .koand .uu ?
> will i be able to resolve gTLD's such as .satan (which cesidian can).africa (which namespace can) or .geek (which opennic can) ?
> > > >> 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.> > O.> _______________________________________________Unbound-users mailing listUnbound-users at unbound.nethttp://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users


	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?

/bill