resolution spaces

[JFC Morfin]

While working on semantic address resolution I consider the DDDS 
possibilities (RFC 3401 ++]. I block each time on a limitation which 
seems to be the same the IDN support is confronted to, the resolution 
of which could be a "virtual presentation layer".

The DNS is a DDDS application. DDDS are based upon a fundamental 
assumption which makes them to resolve only in using the data from 
the provided "application unique string" (in our case the domain 
name). No outside knowledge can be used (such an external knowledge 
of a script or language or [quoted in RFC 3401] time of the day, 
financial transactions, rights managements, etc.). One could imagine 
the problems of resolution space this would lead to.

This obliges MLDNs issues to be solved in a common DNS resolution 
space by default, leading to the IDNA compromise and all the problems 
we face. Would it not be easier to face each namespace with its own 
corresponding resolution space?

When I compare with the LISP discussion, I come with the idea that if 
the Internet technology is not understood in a way supporting what I 
call "externets" (i.e. internal external network look alike), this 
does not mean that it could not. One solution John Klensin suggested 
was to use classes. This is certainly the best one (however classes 
are limited in number in TCP/IP). Another simpler and deployable 
solution could be at the OS level.

When I want to change my DNS resolution parameters, OSes only propose 
me only one possibility. Should they propose me an options based list 
of nameservers, I could define different resolution spaces, for 
example based upon the TLD. "xn--vbevde" could be resolved by 
NS1...series, more generally "xn--" by NS2...series, and the rest of 
the domain names by the legacy DNS system.

Obviously this could be implemented at root, ISP, and every private 
name server, moreover if the wild card extension is extended to an 
"..--*" option. But the individual OS level resolves the problem of 
update : compute would be multilingualy enabled not. Without any risk 
of pollution. The grid of local resolvers could be documented in the 
"netlocale" file with a great granularity (cf. my Draft on cctags).

I am not familiar with the socket software but I suppose that the 
fork could be established there. This would permit to customize the 
resolution spaces against phishing problems. The other "xx--" 
namespaces would be immediately supported, that could use other DDDS 
resolution systems, or more sophisticated non-linear ones.

jfc