Final Sigma (was: RE: Esszett, Final Sigma, ZWJ and ZWNJ)

[Mark Andrews]

In message <C9732258727F2347EB29508B at PST.JCK.COM>, John C Klensin writes:
> 
> 
> --On Thursday, February 26, 2009 22:03 -0800 Erik van der Poel
> <erikv at google.com> wrote:
> 
> > Just an afterthought, but if it really is impossible to add a
> > new field to DNS, one might imagine a new HTTP response header
> > that contains the hint. Of course, one would have to come up
> > with other ideas for protocols other than HTTP, but I hope you
> > get the gist.
> 
> I should let one of the DNS experts who follow the list respond
> to this, but...
> 
> Nothing is impossible, but this comes close.
> 
> It is far more complex than this because of rules about caching,
> additional information, and RR set integrity, but looking data
> up separately for two separate RRs (if that is what you mean by
> "field" causes the DNS overhead for IDNs to double (probably not
> acceptable) and introduces race conditions and vulnerabilities
> to attack (certainly not acceptable if we care anything about
> conditions).

	A quick think would have a record that contains a directionality
	indicator.  It would also have a raw domainname containing
	the UTF8 encoded name.  One would want it to be able to
	exist along side CNAMEs (this would be another exception
	like RRSIG and requires changes to both caches and authoritative
	servers).  One would want the ttl to be the longest of all
	the other ttls at the name.

	For a cache/application to accept it the UTF8 name MUST map
	back to the owner name.

	Do we neeed to support multiple UTF8 names and if so how do
	we tell the application which one to display in which context?

	The next question is which queries need it added to the
	additional section?  All of them?  Specific types?  How
	does it interact with SRV records where the name of interest
	is several label shorter?  I would also be adjusting the
	TTL on transmission to be the minumum of the record's ttl
	and the maximum of the other ttls with the same owner names.
	Additional section processing requires changes to authoritative
	servers and caches to be completely effective.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org