[e2e] scheduled name space

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Sat Apr 17 00:56:18 PDT 2004


In missive <4080B10A.1030207 at isi.edu>, Joe Touch typed:

 >>Geotargeting to provide a 'closer' reply is just an optimization; if you 
 >>actually give different content based on source (i.e., if the IP 
 >>addresses are not to equivalent content), then you've defeated the idea 
 >>that of the name-to-address lookup. All the addresses of the reply - 
 >>whether provided in a set or to different sources - are equivalent as 
 >>'name to address', which means if they're cached, forwarded, or other, 
 >>they should be sufficiently useful.
 
thats right-  DNS is no longer just a simple service

 >>This is like discussing NATs. Sometimes they work, except when they don't.
 
NATs are good since they fix a problem with IP's design that people needed fixing and they do it cheaper than other
proposed solutions. 

the binding between name/address is already weakeneed in DNS by the time to live - i'm formalising this in a way
that lets one control the life time in caches and clients on a per client basis for load reasons - the consistency
tradeoff can just be like a lot of cache consistency thigns ,but I am asserting that in fact the desire for DNS to
provide consistency is not just wrong for performance reasons, but is wrong for functionaloity reasons  there's no
need for it - it doesnt provide security - so long as one can map forward and reverse lookups consistntly for a
particular resolver, at a particular time, thats probably enough -, there's no real need to be able to do this
for the results returned for different clients (or caches) imho. 

one time this did bite was  worrying about SMTP relays looking each other up - but that is being 
addressed by proper security means due to spam and other problems, supportng my case that the idea of name/address
binding consistency over time and space is not a Strong Requirement (TM) - actually, i dont preclude it - the Auth
name server can still provide consistent names if the name semantics require it anyhow - i didnt say you  HAVE to
provide the schedule - i said there were hooks for a schedule - one schedule could just be default (current)
behaviour.....

so i win:)

 cheers

   jon



More information about the end2end-interest mailing list