DISQUS

Scripting News: I need a Domain Name Server with a REST interface (Scripting News)

  • Erik Carlin · 3 months ago
    Dave,

    Rackspace would like to offer you some comped slices on Slicehost for your dev work. That will give you a RESTful interface to both compute and DNS, including TXT record manipulation. If you are interested, please e-mail me at erik.carlin at rackspace.com.

    Regards,
    Erik
  • smilbandit · 3 months ago
    sounds like you are looking for a dynadns.org server with REST update.
  • mterenzio · 3 months ago
    It takes dynamite to get me up!

    I'm not a DNS guru, but it's not clear what you want. Your REST call sends "george", "TXT", "george.loose.ly" and what do you expect to be returned? George's RSS feed?

    If so, I get it.

    loose.ly always reminds me of loose lucy. ; )
  • dave · 3 months ago
    Yes Matt -- you got it -- the URL of the feed.

    It's time to get started on that thread.

    I also want to look at implementing the FriendFeed-like long HTTP connection.

    I'm going to put up another post soon -- I want to work with someone who has a Tornado implementation up and running. It may well be part of the system we want to put together. And I want to create a thread into Facebook too.

    I also am looking for a site that I can call ilove.loose.ly.

    Also it looks like I'll be back east late next week and probably in NY the beginning of the week after next. Maybe time for another meetup. Maybe a little smaller than the last one, who knows.

    I can't believe they're saying I don't work with other people. Some of those dicks shoudl come to our meeting and drink margueritas with us.
  • mterenzio · 3 months ago
    The long polling is interesting. I'm working on that. Some claim that eases resources on the edge and that makes sense.

    But I was thinking today. One argument is that we need to remove the burden from the publisher, so they don't get thousands of requests when they notify everyone of new content.

    And I say, "Okay. Put their feed on S3 or some other CDN if they are big enough to need it." Burden over.

    Is there someone that would be willing to have a central "hub" deliver their content to subscribers and relieve their burden, but unwilling to have a neutral host serve it and relieve their burden?

    Explain to me where the problem lies.

    Another meetup? Yeah!!!! I want Corned Beef or Pizza this time. Lombardis or Katz! They don't eat this well at those fancy conferences! ; )
  • sull · 3 months ago
    Dave.. I spotted this yesterday which may be of interest:

    http://github.com/progrium/domdori
    http://blogrium.wordpress.com/2009/09/15/the-do...

    Also, refer to this comment where i mentioned using a .tel as an initial use-case deployment for rssCloud identity:
    http://www.scripting.com/stories/2009/08/07/tra...

    Another possibility is to utilize Dreamhost's API:
    http://wiki.dreamhost.com/Api#dns-add_record
  • Andy Chantrill · 3 months ago
    Placing the entire rssCloud namespace under one domain name would be a folly - it could be left to expire, accidentally deleted, or even hijacked by a miscreant using non-legal or legal means. Not using a common namespace would create difficulties and mean non-simple names. The good news is there's a more elegant solution.

    Why not use .tel? It's a TLD blessed for this very purpose. Our names in the rssCloud would have deeper meanings, we'd enjoy a common namespace with all the advantages that entails, and everybody gets full ownership over their data, rather than being held hostage to third parties (you and vicariously your service providers).

    TelHosting providers (i.e. the nameserver operators for .tel) are obligated to support SOAP and JSON API specs, described here: http://dev.telnic.org/pages/doc_index.html

    I e-mailed you the credentials for davewiner.tel so you could play around.

    I'd love to go on and extol into the other far reaching implications of .tel, but I figure all that matters here is the rsscloud application, unless you wish to explore broader issues of communication.

    Incidentally, the MyStatusCloud rsscloud aggregator already supports .tel name resolution: http://www.educer.org/2009/09/10/subscribing-to...

    I have great respect for you Dave. Please don't be annoyed with me for not sticking to what you've specifically requested.
  • dave · 3 months ago
    Your first sentence is wrong. I'll read the rest of it, but it began very wrong very very very very wrong.
  • dave · 3 months ago
    I don't want SOAP or JSON -- I want REST.

    I know what I'm taking about Andy. I know how to listen to people, and I know what they will go for.

    And right now -- in 2009 that's REST.

    I do get annoyed when people say I want to put the entire cloud under one namespace. That would be idiotic. I am not an idiot. You shoudl have rejected the notion based on that alone.
  • Andy Chantrill · 3 months ago
    Well I'm with you on the REST thing. I could code up a RESTful gateway for .tel if you'd like. We could also ask Telnic to provide one straight out of Community TelHosting system.

    I understand that you don't like being second guessed. Believe me, I thought twice before commenting. However, if you don't intend to use a single namespace then wouldn't it fall short of the simplicity you'd described previously? By using .tel we get to silently drop the extension and use shorthand, i.e. davewiner instead of davewiner.tel. I thought you'd appreciate that.
  • dave · 3 months ago
    You need a big hug. Get going with the coding up a RESTful gateway for .tel and we;re in business. And stop worrying so much! :-)
  • Andy Chantrill · 3 months ago
    I do! A BigHugSugbug :)

    I'll let you know when I've got something ready.
  • Henri Asseily · 3 months ago
    Ok I'll try to get a prototype for you out today.
    But it won't be a 'TXT' record, it'll be 'NAPTR'. Makes a lot more sense to use NAPTR, as this is a URI we're talking about, as a value.
  • Mason Lee · 3 months ago
    By the same token that developers want to use HTTP POST to register their feed, won't developers want to use HTTP GET to resolve the names to feeds?
  • Andy Chantrill · 3 months ago
    That would make sense for completeness sake, but I wonder if it'd be wise to sell shoes with mines embedded in the soles - there'd have to be a huge health warning :)

    I know you know this, but for the benefit of others: for lookups DNS is the API. In the case of name->endpoint resolution just pull the NAPTRs; it's faster (less data on the wire, UDP), high availability (load distributed across the network), no single PoF like a web server.

    Maybe Dave's right, I do worry too much :)
  • Mason Lee · 3 months ago
    For the sake of completeness, here are some problems for using DNS as a generalized service registry. They may or may not affect the 140 char loosely coupled network ("Loose.ly").

    1. The DNS cache can be slow to propagate, meaning there's an indeterminate lag between modifying a service endpoint (e.g. a feed address) and being able to use it fully. The best case for DNS NAPTR records is probably a 1-5 minutes lag, but it's ultimately up to each ISP's nameserver to decide how they want to setup their cache. The shorter the TTL, the less caching you get.

    2. Javascript in the browser cannot make the socket connection to do a DNS lookup. Javascript widgets will need to contact some server running an HTTP service that bridges to a DNS lookup. And of course, an HTTP service is what most developers today will want to contact in the first place, Andy's fair points above notwithstanding.

    3. Lastly, a general point which probably does not affect Loose.ly's casual use case: DNS is vulnerable to easy spoofing attacks and so cannot be used for looking up some other types of service endpoints, such as OpenID's single-sign-on delegation, or OAuth's authentication endpoints, or a person's public keys for digital signatures.

    Just wanted to get that on the record. None of this is to say it can't work. Obviously DNS sure is clean and simple :)
  • sull · 3 months ago
    what do you suggest regarding the spoofing vulnerabilty?
  • Andy Chantrill · 3 months ago
    1. If your local resolver enforces minimum TTLs that are unacceptably high for your particular application then you could use more liberal public resolvers like OpenDNS.

    2. Technically Javascript does support sockets - you're just not allowed to use them from a web page, though you could from a browser extension (I built a web server for Firefox). I plan on implementing a DNS client in Flash and exposing its interface via Javascript. Should be good enough - if a client doesn't have Flash then I can just fallback to a HTTP request.

    3. DNS is vulnerable to pharming attacks for a lot of stuff, including OpenID (unless you use something like X509 client side certification). DNSSEC is the answer - the internet needs it.. like yesterday!
  • AndrewBurton · 3 months ago
    You mean something like this?

    http://dvlop.in/
  • Hanan Cohen · 3 months ago
    I am now sure if this is exactly what you are looking for but take a look at the API of http://dreamhost.com

    http://wiki.dreamhost.com/Application_programmi...
  • sull · 3 months ago
    right, i mentioned this in my comment as well.
    i have not tried dreamhost's API but the DNS hooks are there.
  • Henri Asseily · 3 months ago
    I'm pretty much done with your requested interface. I'm implementing a simple authentication mechanism right now, should be done in an hour or so.
    Ping me offline for the info (http://henri.tel or twitter or whatever you prefer)
  • sull · 3 months ago
    i assume you plan to release to the telnic dev community?
  • Henri Asseily · 3 months ago
    Yep I'll publish the source code that took all of 3 hours to write very soon.
    By the way, there's a major issue with "let's make a simple API for the DNS" in that the DNS ain't that simple. So in order to make a simple API, you have to do the hard work of getting rid of what you don't want.
    Luckily when you're using .tel domains you already have a couple of APIs you can use, and making simple wrappers for those is quite easy.
  • dave · 3 months ago
    A heads-up that there's another serious implementation that's reaching closure. I hope you guys share ideas and perhaps we could even have an interoperating REST interface for DNS administration. I would totally support that (with code of my own, on the client side).
  • Henri Asseily · 3 months ago
    I have no idea what that other "serious implementation" is, but if we even haven't discussed the choice of record type to use, I can guarantee you that we're not going to get far in interoperability.
    Here's my quick little thing:
    http://67.23.22.13/dns/

    It inserts into a .tel domain a NAPTR record of this type:
    "E2U+x-feed:http" "!^.*$!http://rikkles.blogspot.com/feeds/posts/default!"

    It says that it's a feed ("x-feed") using the http protocol, and the replacement string is (as is the case for all NAPTR records) a fully functioning regular expression.
  • rbonini · 3 months ago
    Don't forget guys.
    If you are going to be using Friendfeed-Like long polling here, Facebook opensourced Friendfeed's web server (that just sounds wrong), named Tornado.

    Find it here: http://www.tornadoweb.org/
  • brianjesse · 3 months ago
    I made a REST API like this, you can find the documentation at http://cloud.twitteronia.com - would love to have feedback here on whether it works. Thanks! -- Brian
  • brianjesse · 3 months ago
    This is working pretty well, send me an e-mail if you'd like to try it out. brian@megapump.com

    The source code is published on github:
    http://github.com/voitto/rsscloud_dns_server


    ####################
    ## creating a zone record
    ####################

    POST vars
    ---------------
    name = "george"
    record = "TXT"
    feedname = "george.loose.ly"
    key = md5( subdomain.record.value.pass ) where period concatenates values of these post vars and "pass" contains password value

    API endpoint
    ------------------------------
    http://cloud.twitteronia.com/api/

    New zone record
    ------------------------------
    | 14 | 9 | george | TXT | | 0 | 86400 | george.loose.ly |





    ####################
    ## updating the feedname
    ####################

    POST vars
    ---------------
    name = "george"
    record = "TXT"
    feedname = "george.twitteronia.com"
    key = md5( subdomain.record.value.pass ) where period concatenates values of these post vars and "pass" contains password value

    API endpoint
    ------------------------------
    http://cloud.twitteronia.com/api/

    Updated zone record
    ------------------------------
    | 14 | 9 | george | TXT | | 0 | 86400 | george.twitteronia.com |





    ######################
    ## updating the record data
    ######################

    POST vars
    ---------------
    name = "george"
    record = "TXT"
    feedname = "george.twitteronia.com"
    feedurl = "http://george.blogspot.com/posts.rss"
    key = md5( subdomain.record.value.pass ) where period concatenates values of these post vars and "pass" contains password value

    API endpoint
    ------------------------------
    http://cloud.twitteronia.com/api/

    Updated zone record
    ------------------------------
    | 14 | 9 | george | TXT | http://george.blogspot.com/posts.rss | 0 | 86400 | george.twitteronia.com |




    #############################
    ## REST feed lookup from feedname
    #############################

    (you can try this one yourself without authentication)

    POST vars
    ---------------
    name = "george"
    record = "TXT"
    feedname = "george.loose.ly"

    API endpoint
    ------------------------------
    http://cloud.twitteronia.com/api/

    (server performs a DNS lookup for TXT record at george.loose.ly)

    Output
    ------------------------------
    http://george.blogspot.com/posts.rss
  • Henri Asseily · 3 months ago
    Using TXT is wrong for this. You should use NAPTR records.
    You can rig it with TXT, but it doesn't make sense as NAPTR is specifically engineered for this.
  • Andy Chantrill · 3 months ago
    Edit: posted in wrong place of thread.