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.
"
The Sevenval system is useful, because
- it makes pages fairly uncacheable in a central proxy while at the same time retaining local cacheability of the pages, thus keeping the back button alive
- you do not have to propagate the session id manually, but only have to use relative links in your pages. This will even would on static pages.
- you can easily log by host and get customer tracking with current tools
Sevenval implements this with a wildcard A-record in the DNS system, which has been around for quite some time, and an initial 302 redirect to a unique hostname. That hostname is long (a 128 bit value) and randomly generated, making it unguessable. Changing the hostname will simply restart your session, as with any other session tracking systems.
© Copyright 1999 Kristian Köhntopp
According to the DNS record for sevenval.com, how exactly are the dynamic A records held? I'm fairly sure there is an implementation of DDNS in the latest version of BIND (ala Windows dynamic WINS updates in DNS), but how is this stored?
I don't see anything even remotely dynamic below, but their hostname is extremely dynamic when viewing their webpage. I would assume its the * record, but what sort of application generates the hostname?
2000011802 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns.buy-world.de.
1D IN NS ns.r-tec.net.
1D IN MX 1 wilson.office.sevenval.de.
1D IN A 195.122.187.3
* 1D IN HINFO "IBM-PC" "UNIX"
1D IN A 195.122.187.3
cvsserver 1D IN A 62.96.224.212
1D IN HINFO "IBM-PC" "UNIX"
*.cologne 1D IN A 62.96.224.211
1D IN HINFO "IBM-PC" "UNIX"
wilson.office 1D IN A 62.96.224.210
1D IN HINFO "IBM-PC" "UNIX"
tim.office 1D IN A 62.96.224.222
1D IN HINFO "IBM-PC" "UNIX"
EraseMe
There's a web site http://www.lemuria.org/Software/unpoison that calls this technique "URL Poisoning" and mentions that this could be considered a Bad Thing, because using this technique, people cannot easily "opt out" from being profiled, as you can by, say, disabling cookies in your browser.
Refer to the above link for an explanation of URL Poisoning, and for a pointer to a Squid redirector plugin that can be used to disable URL poisoning.
I personally don't have any opinion on this; I can see how it can be used, as well as how it could be abused. [shrug]
--
"May I have ten thousand marbles, please?"
-----------
"You can't shake the Devil's hand and say you're only kidding."
Hostname information encoding has been done here as well. ;)
This site works with all text I have tried, separated by periods. I don't know how long it's been up, but it has been there for quite a while.
Geeky modern art T-shirts
--
News for Geeks in Austin, TX
Freshmeat already has a program registered called 'depoison' that will remove this session management information. I'm sure it was for a different web site, so perhaps THAT is prior art in itself?
Slashdot? Oh, I just read it for the articles.
My mistake. It's actually called unpoison and is written by Tom Vogt.
... (which in all liklihood is the same deal as sevenval.de now I've woken up enough to remember how to spell my numbers)
Freshmeat Application Page reads as follows:
unpoison.pl is a simple Squid redirector plugin that disables (and returns the favor of) a new customer-tracking scheme developed by 7val.com that the author has labeled "Location Poisoning". The Web page explains how Location Poisoning works and why the author considers it a Bad Thing(tm).
The App home page gives more information, including the patent request by 7val.com
Slashdot? Oh, I just read it for the articles.
AOL has been encoding session info into the DNS names given to its users' ip addresses for years.
-- Colin Steele
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
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.