On Wed, Aug 1, 2012 at 1:22 PM, Ray Hunter <[email protected]> wrote: > Isn't it possible to combine the two ideas of sitelocal. with > pseudo-domains generated from ULA to give a usable solution? > > e.g. fridge.<pseudo-ula-domain>.**sitelocal. > > Two points. As I mentioned at the mic yesterday, this maps onto the ULA distribution problem. You'd either have to identify a deterministic "root" ULA for this "zone" or guarantee that multiple such zones within a given site all appear as being "on-site". Second, is the unique string part of the name or a zone of the domain? mDNS recommends that all host names in .local. appear as a flat namespace, but this is only a recommendation. We humans started using surnames some time ago to disambiguate our identities regardless of location (although I note that many such attempts were of the form "O'There").
> Don't you then avoid the evilness of identifier overloading (my fridge > versus your fridge) and potential problems with clashing TLD's? > e.g. someone registering a bunch of <pseudo-ula-domain>. TLD records as > their company brand for manual administration. > > How else are homenet devices going to know not to bother the root servers > with fridge.<pseudo-ula-domain>. NS queries given that TLD's are now > basically a free for all? > > I think this is a darned good point. It saves every resolver from having to parse ".local-<mumble>." to decide whether it should delegate or not. > Wouldn't it also potentially give a unique anchor point for storing DNSSEC > zone signing with an implicit sitelocal. trust anchor? > > An even better point. -K- > regards, > RayH > > > > Brian E Carpenter wrote: > >> Synthesise a pseudo-TLD from the ULA prefix. >> >> Brian >> > > > > > Brian E Carpenter wrote: > >> On 01/08/2012 05:48, Curtis Villamizar wrote: >> ... >> >>> fridge.sitelocal. is a FQDN with site local scope. >>> >> >> And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically >> evil. >> >> IMHO we shouldn't be discussing how to make it work less badly; we should >> be discussing how to avoid it entirely. >> >> Brian >> >> ______________________________**_________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet> >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
