Slashdot Mirror
Wildcard DNS, Session Management And Prior Art
Alowishus asks: "A company called sevenval has an interesting, but obvious, use of Wildcard A-Records in the DNS to encode Web session management IDs in the hostname of the site. Interesting, because if you are using relative URLs on your site, you do not need to do anything (i.e. setting a cookie or appending GET parameters) after the initial redirect to maintain a user session. See www.fahrschulportal.de for an example. Sevenval is applying for a patent on this technique, and Kristian Kohntopp, the author of a PHP session management library, is looking for prior art. He would like to find uses of hostnames that encode state or session information. Has anyone seen this before? It's an exceptionally useful technique, and I'd hate to see its use restricted by another improper software patent.
"
Why is this technique so useful compared to session-id tracking? I don't believe that it really is, or why such a fuss should be kicked up about it :
...)
:) Do correct my bullshit if it is that, please.
If I understand it correctly, it simply replaces the session ID normally stored in as a cookie/get-var in the hostname.
This would lead to extremely user-unfriendly domain names, and surely it would really bugger up users trying to bookmark the site (stale sessions could stay in bookmarks for a LONG time).
Also, its simply not as efficient as session IDs, which after one unfriendly GET, tend to store their results in a cookie which is transparently passed around. Surely dynamic DNS would all have to have really low TTLs and generally slow down site access if you have to do a large number of DNS lookups (which can be the slowest stage in an http access cycle?)
As I see it, the only problem with the session-id method is that it complicates serverside scripting, but with simply superb tools like PHPLIB all those details are abstracted away from the user. And also PHP4 has built in session handling to simplify things further. IIS has similar modules for ASP developers, and I'm sure others exist forother scripting languages (mod_perl? dunno
So while this might be of interest to some specific applications, I can't see it revolutionising the whole ecommerce industry with its cunning "new" user tracking system.
But then again, I might be talking bull
It IS obvious. One of my projects is a web search engine and I have given dns-based session control quite a bit of thought. As a spider designer, it gives me the heebie-jeebies.
No one uses dns encoding because it poisons dns caches. Remember, dns lookups that aren't cached on a nearby server require sending a request/response from at least two other machines. Here's what a session might look like.
////////////////////
First query the local server. Very fast since the connection is probably ethernet.
me -> dns.ryans.dhs.org
Now my local dns goes off and searches for the ip address.
Local dns queries the root servers.
dns.ryans.dhs.org -> b.root-servers.net
dns.ryans.dhs.org ns1-auth.sprintlink.net
dns.ryans.dhs.org - ns1-auth.sprintlink.net
Local dns sends me the answer
me - dns.ryans.dhs.org
Start tcp session
////////////
As you can see, the name lookup needed one short-haul and two long-haul roundtrips. If it was cached only one short-haul conversation would have been needed.
Ryan
http://x42.com/urlcalc/ looks a lot like prior art to me.
SSL site certificates are bound to a very specific host name, so this session tracking soution would work only for non-secure sites.
This has been one of the features I've been trying to hype for our new Web server cluster. I love wildcard A records. There not only useful for non-cookie sessions (I *hate* cookies.) but I have been playing with them to support being able to "log out" an HTTP authenticated connection. (So you'd authenticate with auth1234.foo.com and then the server could invalidate your authentication with that specific host name.)
I have public examples of my use of wildcard A records through purdue.org:
Not session tracking, but a similar idea:
http://type.something.here.real ly.fuckingsucks.net/
(and sorry for the sailor talk).
Replace "type.something.here" with, say, a company name.
...j
Ok, checked out the homepage of this user and don't get a lot of his complaints.
As customer, you are paying, so that the company owning the web-pages can profile you. Not only is tracking the default, there also is no way out, no "I don't wanna be tracked" button.
Ok, so I definitely don't understand all of this "location poisoning" technology, but I don't see anywhere that they are getting more information about you (IP address, pages viewed, etc...) than any other web site collects. Don't know about your friends and coworkers, but all the major websites that I've heard of and interviewed with do major tracking (300Gb data warehouses and such) of all hits and don't offer an opt-out option. How is this different?
With "paying" I do literally mean money and time. Location Poisoning disables proxy servers, DNS caching and other mechanisms that reduce the amount of net traffic. More traffic means waiting longer for pages to appear, and if you pay for your traffic (most small businesses do) it also means you are paying money that you shouldn't have to pay.
So what if I use this for dynamic content? In that case, caching doesn't matter anyway.
Location Poisoning also abuses HTTP and DNS standards.
Last time I checked, most of what web developers do abuses standards (mainly html) Ever noticed that client side scripting gets buried in comment tags? That's actually part of the standard, but it doesn't make it any less fucked up.
The reply to an initial request is a 302 error code, reserved for "Temporarily Moved" documents. Giving this reply is somewhat akin to a lie by the remote webserver.
Yeah, just like how giving me "permission denied" is a bit of a lie on footfetish.com, what they ought to be sending me is the (forget the number) "payment required" http response. Those bastards!
Abusing standards for one-sided gains should not be endorsed. It undermines the standards and punishes those who try to respect them.
How do you feel about all the html tags that netscape introduced? That was an abuse of the html standards process, but it's hard to deny that it dramatically improved the web. Why should http standards be different?
Location Poisoning tries to transparently add states to a stateless protocol. This is a bit like dehydrated water - sounds interesting, but doesn't make much sense.
Come on, every web developer I know spends time trying to establish states on this stateless protocol. Like cookies are an elegan solution.
There are several ways to add states to HTTP, but they are far from transparent. So it appears that in the long (by IT standards) history of the web, absolutely everyone missed this quite simple solution? Hardly a believable claim, is it?
Quite possible. I improve my throughput by using the mouse with my toes. My coworkers insist they've never heard of anything so daft.
Finally, Location Poisoning is a proprietary solution. If you use it, you are binding yourself to one partner. If at a later date you wish to work with someone else, you will have to completely redesign and re-implement your whole customer tracking system. Other mechanisms are open and can be taken over by your new partner. Location Poisoning is patented (or will be soon), and thus can't be used by someone else.
Ever talked to a mac user. They're all pretty relaxed about being married to a single company. (OK, so they were pretty nervous about it a few years ago, but really)
If I'm missing the point here, feel free to flame.
--Shoeboy
http://$urlcalc(about).x42.com/
According to the copyright notice on the page, this has been up since 1998-06-23, and has won the "Useless site of the year award" for 1998.
Perhaps it wasn't so useless after all.
Check out this article for a counter argument to this approach.
Quoting from that page:
Why you should oppose Location Poisoning as a customerAs customer, you are paying, so that the company owning the web-pages can profile you. Not only is tracking the default, there also is no way out, no "I don't wanna be tracked" button.
With "paying" I do literally mean money and time. Location Poisoning disables proxy servers, DNS caching and other mechanisms that reduce the amount of net traffic. More traffic means waiting longer for pages to appear, and if you pay for your traffic (most small businesses do) it also means you are paying money that you shouldn't have to pay.
Location Poisoning also abuses HTTP and DNS standards. The reply to an initial request is a 302 error code, reserved for "Temporarily Moved" documents. Giving this reply is somewhat akin to a lie by the remote webserver.
Abusing standards for one-sided gains should not be endorsed. It undermines the standards and punishes those who try to respect them.
Location Poisoning also undermines the purpose of DNS and hostnames. Instead of using DNS to give human-readable names of server machines ("www.lemuria.org" instead of 195.244.121.251), it abuses the DNS to identify a client machine - i.e. you, the customer.