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

Mark Andrews Mark_Andrews at isc.org
Sat Feb 28 00:44:48 CET 2009


In message <D00822994960DA99F078222E at PST.JCK.COM>, John C Klensin writes:
> Mark,
> 
> To follow up on the comments made by Andrew and Jaap, if one
> assumed for purposes of argument that someone wrote an I-D
> between now and Wednesday and submitted it to DNSExt (that
> assumption is probably ridiculously optimistic, especially since
> your strawman proposal appears to be quite different from
> Andrew's, but bear with me), what do you think the minimum time
> would be before the proposal were appropriately refined,
> approved by the WG and the IETF, implemented in all relevant DNS
> servers and resolvers, including stub resolvers (because this
> would clearly not be useful unless implemented in end systems),
> and then deployed sufficiently widely across the Internet that
> all of the systems involved would handle the records correctly,
> preserve the relevant information, cache data as needed, etc.?
> 
> And, just out of curiosity, how much less time do you think that
> would take than the complete DNS redesign, reimplementation, and
> redeployment that some people believe is now due or overdue?
> 
>       john

	You could get partial support the moment the type code was
	allocated.  Clients would query for the record.  Authoritative
	servers could use unknown type support to add the record.
	It would work for all names except those with CNAMEs.

	Support for CNAMEs requires servers and caches to be updated.

	Mark
 
> --On Saturday, February 28, 2009 09:51 +1100 Mark Andrews
> <Mark_Andrews at isc.org> wrote:
> 
> > 
> > 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
> >  
> 
> 
> 
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org


More information about the Idna-update mailing list