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. "

18 of 177 comments (clear)

  1. Answert to "Why is this useful?" by kris · · Score: 3

    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

  2. DNS record.. by EraseMe · · Score: 3

    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

  3. It's been called "URL Poisoning" by lar3ry · · Score: 3

    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?"
  4. Improper? by Foogle · · Score: 3
    This is hardly an improper software patent. If it was so obvious, we'd all be using this sort of technology in our web-browsers right now. Now, you may not want to see it patented -- so that everyone can use it freely -- but that doesn't make it "improper". This is the very heart of what patent's are about.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  5. Re:depoison... and THIS(!) by Sun+Tzu · · Score: 3

    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.

  6. I got cher prior art right here... bookpool.com by StandardDeviant · · Score: 3
    I could of course be smoking der crackenpipen, but I think the stuff I see in the URLs when I visit www.bookpool.com (amazingly cheap prices on computer and tech books, way cheaper than amazon or fatbrain in my experience). I don't know how long they've been around, but I've been shopping there since april of last year. Mike

    --

  7. depoison by dsb3 · · Score: 3

    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.
  8. unpoison (not depoison) by dsb3 · · Score: 3

    My mistake. It's actually called unpoison and is written by Tom Vogt.

    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 ... (which in all liklihood is the same deal as sevenval.de now I've woken up enough to remember how to spell my numbers)

    --

    Slashdot? Oh, I just read it for the articles.
    1. Re:unpoison (not depoison) by Shoeboy · · Score: 5

      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

  9. AOL doing this for years -- serious prior art by webg2.com · · Score: 3

    AOL has been encoding session info into the DNS names given to its users' ip addresses for years.

    --
    -- Colin Steele
  10. Is this really groundbreakingly useful? by stab · · Score: 4

    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 :

    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 :) Do correct my bullshit if it is that, please.

  11. Re:IM SO SICK OF PEOPLE COMPLAINING by slashdot-me · · Score: 4

    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

  12. Calculator in the URL - prior art by bvark · · Score: 4

    http://x42.com/urlcalc/ looks a lot like prior art to me.

  13. Useless for SSL by DSCreat · · Score: 4

    SSL site certificates are bound to a very specific host name, so this session tracking soution would work only for non-secure sites.

  14. I've been doing this. by Kyler+Laird · · Score: 4

    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:

  15. Possible candidate by jbrw · · Score: 5

    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

  16. Calculator in the URL by HugoRune · · Score: 5
    This looks like a similar idea to me.
    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.

  17. aka "Location Poisoning", not good by RMGiroux · · Score: 5

    Check out this article for a counter argument to this approach.

    Quoting from that page:

    Why you should oppose Location Poisoning as a customer

    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.

    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.