Blog of our latest news, updates, and stories for developers

A proposal to extend the DNS protocol

Wednesday, January 27, 2010
Share on Twitter Share on Facebook
Google
Labels: dns

51 comments :

  1. Link E StarbureiyJanuary 27, 2010 at 10:55 PM

    Bravo!

    ReplyDelete
    Replies
      Reply
  2. RAINJanuary 27, 2010 at 11:56 PM

    Thats good.

    ReplyDelete
    Replies
      Reply
  3. SreejithJanuary 28, 2010 at 1:18 AM

    cool

    ReplyDelete
    Replies
      Reply
  4. MickeyCJanuary 28, 2010 at 1:38 AM

    Google wants to shave a few dozen milliseconds off the time a HTTP request takes for an extremely small number of users, when accessing a *tiny* fraction of a percent of websites, by creating a major change to the most important protocol on the Internet? Doesn't seem very clever to me.

    It also leaks information about the end user unnescesarily. A prime example of where this would have been bad is the DNS pre-fetching flaw in most webmail implementations (inc GMail over HTTP) which I blogged about the other day:

    https://secure.grepular.com/DNS_Prefetch_Exposure_on_Thunderbird_and_Webmail

    ReplyDelete
    Replies
      Reply
  5. mathbuzzJanuary 28, 2010 at 1:53 AM

    This is horrible. This is so GOOG can monitor ALL of your web activity, all the time.

    If you ever use Google, or see adwords anywhere, they already have your ip--all 4 octets.

    With this DNS extension, they can see what sites buckets of people are visiting when they're NOT on google sites or where goog ads are being served. It's not resolved down to the user, but it's bucketed, and over time, they can guess what's happening.


    This proposal is absolutely about google getting more data about your internet habits, and more data about the market spaces they don't (yet) control.

    ReplyDelete
    Replies
      Reply
  6. seoerJanuary 28, 2010 at 4:05 AM

    To be honest? I don't like the idea. It would certainly open the door to a well load balanced world, but I rather prefer concentrate to a cloud environment instead a DNS tricks with dozen of hosting around the world.

    ReplyDelete
    Replies
      Reply
  7. nuclearcatJanuary 28, 2010 at 4:25 AM

    IMHO will not work.
    1)One-way satellite ISP customers - FAIL. Sometimes they use DNS of terrestrial ISP, and real content retrieved over Sat-ISP (over another IP). In my case for example DNS sometimes is from UK, sometimes from Germany, and sometimes Lebanon.

    2)Multihomed ISP with non-BGP load-balancing - FAIL. DNS can go through one backbone, service over another. In Lebanon for example they have two completely different backbones, USA and European, and sometimes they are chosen in very strange manner.

    3)What if access to DNS done from reserved, so called "gray" ip? 10.x.x.x won't help much.

    Better to use extension thats already exist. And to do that over HTTP. You can get already X-Forwarded-for there, and real ip of the customer.
    If they have their own protocol - embed that extension there.

    ReplyDelete
    Replies
      Reply
  8. Jared MauchJanuary 28, 2010 at 7:07 AM

    And what about IPv6?

    ReplyDelete
    Replies
      Reply
  9. Jean-François GeyelinJanuary 28, 2010 at 8:16 AM

    "Google wants to shave a few dozen milliseconds off the time a HTTP request takes for an extremely small number of users, when accessing a *tiny* fraction of a percent of websites, by creating a major change to the most important protocol on the Internet?"
    Even if just Google uses this protocol, 70% (at least) of the internet users will gain time.
    Kapow.

    ReplyDelete
    Replies
      Reply
  10. Carlo ContavalliJanuary 28, 2010 at 9:10 AM

    One way satellites, multi homed sites, ... and anyone who is using a DNS server far away from his computer are exactly the users who will benefit the most out of this proposal.

    In the current world, most major internet sites will send your browser to different locations based on the IP address of the resolver configured on your computer.

    What we're proposing will allow those internet sites to send your browser to the best location based on your network IP, rather than the one of your resolver.

    Google will not be the only one to benefit, as the extension will be usable by anyone. And it's only a backward compatible DNS extension: not all ISPs or recursive resolvers will need to use it or even know that it exists, even if we do hope that it will be used where it does matter.

    Also, if implemented as we suggest, the data that will be disclosed will not be enough to uniquely identify a user in most of the cases, and will not add anything more to what your computer normally sends when opening an HTTP connection.

    ReplyDelete
    Replies
      Reply
  11. display nameJanuary 28, 2010 at 10:51 AM

    Shaving off the last octet will not protect anyone's privacy. It's nice that they decided to shave off the last 8 bits to save space, but it won't keep anyone safe. If anything you've just narrowed down the list of possible hosts that sent the dns requests from 4 billion to 255.

    Note: I haven't read the RFC, just going by the OP text.

    ReplyDelete
    Replies
      Reply
  12. iuseroffJanuary 28, 2010 at 10:56 AM

    This comment has been removed by the author.

    ReplyDelete
    Replies
      Reply
  13. voretaq7January 28, 2010 at 10:56 AM

    @ Carlo Contavalli - Can't this be done by using the existing DNS LOC resource record specification? If you (or your ISP) want to expose your geographic location simply enter a LOC record in the reverse zone.

    To modify the fundamental operation of DNS, and to do so in such a way as to negate all the benefits of caches along the resolver path, seems arrogant and ill-considered to me.

    ReplyDelete
    Replies
      Reply
  14. iuseroffJanuary 28, 2010 at 11:02 AM

    Hey, Google! Stop breaching our privacy! Your proposal would also allow to you and Chinese government, Big Brother and whoever else to collect certain information in abusive manner. As the result, you're not better than Chinese government in your efforts to trash our privacy now and forever. Oh yeah, and dissidents tracking now made easy with new DNS system? Just as well as imposing censorship? What a great proposal.

    ReplyDelete
    Replies
      Reply
  15. tigermsctJanuary 28, 2010 at 11:19 AM

    Does no one know about a thing called Anycast. Its there in IPv4 not just IPv6 and some content providers use it. You have one IP Address that is advertised to the global routing table from multiple places. The routers along the way actually direct your traffic to the nearest source thus having the same effect as what they want this new extension for.

    When will we stop trying to reinvent the wheel just because someone else though it is and invest in further developing what is already there.

    ReplyDelete
    Replies
      Reply
  16. OttoJanuary 28, 2010 at 11:20 AM

    Great proposal.

    ReplyDelete
    Replies
      Reply
  17. SteveJanuary 28, 2010 at 11:30 AM

    This seems to increase load on all nameservers - both caching/recursive nameservers and authoritative ones.
    I just don't see a compelling benefit to this.

    At the moment an authoritative response can be cached and returned to any other client that makes the same request (i.e. request for A for www.google.com will return the same answer for 10.1.2.3 and 192.168.1.2).

    If this proposal were to be adopted, a caching nameserver has the option of:
    1) do not cache an authoritative response, so the benefits of caching are lost, and both the caching server and the authoritative server will see increased load.

    2) cache per-subnet results separately, so instead of caching 1 result, the caching server has to store N results (where N is the number of subnets served by the caching server). If a cache is storing N answers instead of 1, answers will need to be expired (and re-requested) more frequently, again increasing the load on both the caching server and the authoritative server.

    ReplyDelete
    Replies
      Reply
  18. PeteJanuary 28, 2010 at 11:46 AM

    "Users who wish their full IP address to be hidden can include an edns-client-ip option specifying the wildcard address 0.0.0.0/0."

    How about having the recursive resolver default to this behavior unless the original client specifically sends an edns-client-ip option. Clients opt-in instead of opt-out, which also gives them the choice of how much of their IP address they want to expose.

    ReplyDelete
    Replies
      Reply
  19. lkclJanuary 28, 2010 at 12:12 PM

    guys,

    of _much_ more interest would be to back-port the extensions to DNS that allowed it to act as a peer-to-peer naming service WITHOUT requiring a server AT ALL.

    what? what is this? DNS without a server, how could this EVER be possible? what is this madman talking about?

    take a close look at RFC 1001 and 1002. you will see that the packet formats are IDENTICAL to DNS. all that happened was that the zone field was called "scope", a stupid "mangling" was put onto host names, and an extra DNS type called "Name Query" was added, which is a bit like a DNS server "all" query, except it can be sent to any machine.

    yes, you guessed it: NetBIOS name resolution was derived originally from DNS.

    by dropping all the stupidities (name mangling, "scope") and making use of DNSSEC, an update to DNS to become a true server-independent peer-to-peer service would be absolutely revolutionary.

    and the neat thing is that there already exists a free software implementation on which the changes could be made to work with very little effort, which is in prevalent use today across millions of free software machines for at least twelve years: yes, you guessed it, it's called "nmbd" and it's been part of samba since around 1.9.14 or possibly even earlier.

    ReplyDelete
    Replies
      Reply
  20. bsureJanuary 28, 2010 at 12:20 PM

    This proposal doesn't seem to be all that different from the way the root server system currently returns referrals to requesting lower-level servers via anycast (which uses your IP as a geographic indicator to tell the root server system to reply using the server geographically closest to you). While I don't think that it's an "evil google plot" to get more info from you, I also don't feel that it's all that necessary. If you're really unhappy, create yourself a caching-only server (very easy w/BIND, djbdns, Microsoft, or other dns server software) and dump the contents of the database into your hosts file periodically. (Then you don't use the DNS for the sites that you regularly use.) If you want to pull your tin-foil hat down a bit further over your ears, tunnel your dns lookups through TOR, a SOCKS server, or other similar service. duplicate the system currently in place in the root server system.

    ReplyDelete
    Replies
      Reply
  21. joaopedropereiraJanuary 28, 2010 at 12:24 PM

    I don't like the idea, everyday most we lose our privacy online. And this is one more step for that.

    Technically it seems to be causing more load on the servers and more confusion, because a nameserver don't need to accept what the authoritative server "says" so, one is giving answers for questions but the questioner don't pay attention to it.

    What's good on this? Please Google, start thinking on privacy because lots of people are getting noticed about what's happening online...

    ReplyDelete
    Replies
      Reply
  22. Matt KeenanJanuary 28, 2010 at 12:39 PM

    @Steve

    Exatcly my concern, especially as a hostmaster on a large number of domains. Also this will be vociferously objected by ICANN, they are having enough issues with root scaling without throwing this into the mix. Root servers are going to have enough on their plate in the coming years with DNSSEC, expanding IPv6, increasing number of TLDs without ordering up an O(n) increase in the amount of DNS traffic. I really wish the Google engineers had talked to a few people at IANA / ICANN before launching this kind of silliness.

    @Carlo

    People with asymmetric routing will have problems because the DNS server will serve up depending on the source rouiting, whereas the customer will usually be more concerned about the destination routing. This might be a "nice" idea for content providers, but for network, security and privacy engineers it will be very painful.

    _Local_decisions_should_be_made_by_locally_informed_systems;_this_is_the_basis_of_routing_and_it should_be_the_basis_of_DNS._This_is_how_distributed_systems_work._If_it_is_not_broken_do_NOT_fix_it._

    ReplyDelete
    Replies
      Reply
  23. Rick BlakeJanuary 28, 2010 at 12:49 PM

    First, my location may be private. Please ask first. And the answer is 'no', until I've gotten to the service I wanted and can choose their terms of service, ok?

    Second, what if my address resolves to a corporate router somewhere. I know, that's good enough for load balancing and shortest-path calculations.

    Third, don't add unrelated features to DNS. Location is important to the resource, but not to the requester. Leave DNS alone, unless you're improving security, which this does NOT do.

    Really, this is not good for us. It's marginally good for providers, who should do it some other way.

    And don't get me started on the political and human-rights ramifications of this. Not well thought out, gang. It solves a minor problem and causes many more...

    ReplyDelete
    Replies
      Reply
  24. tedhhiJanuary 28, 2010 at 1:03 PM

    I am a DNS system administrator at a mid-size ISP. At first I was speculative about this proposal based on the comments here. Taking an end-user customer's perspective, I just read the Internet draft, and at this point, I think it sounds reasonable. The privacy fears over a network address as tight as a /24 will probably not match a production deployment, since DNS admins are going to want as few records cached as possible. I don't think there is a valid "privacy" concern here anyway, as it is not a secret to the owner of the authoritative server that a certain IP netblock is accessing their resources.

    Hopefully BIND and other DNS servers will add new configuration directives that will enable DNS admins to populate data about recursion clients' subnets and specify the netmask for each that is to be specified in this protocol. Adding that configuration isn't really more work for DNS admins because typically we already have to configure new netblocks to un-block recursive queries for those clients.

    ReplyDelete
    Replies
      Reply
  25. chachaJanuary 28, 2010 at 2:09 PM

    Only capturing the first 3 octets of the ip address, still narrows the request as having originated from a group of 255 possible addresses. That's pretty useful to someone wanting to track your online behavior. Add to that the recent work done by the EFF showing how you can use non-ip based information from the web request (ie. user agent, accept-encoding, etc.) to create a "fingerprint" of a visitor and you have everything you need to track user behavior pretty darn accurately. Smells fishy to me.

    ReplyDelete
    Replies
      Reply
  26. hollow87January 28, 2010 at 4:11 PM

    Ok, I really don't see what all the hype about privacy is with this. Sure the DNS server gets the first 3 octets of your IP. Which would not have been exposed before to it, since it would only get your revolver's IP.

    With this though it would pass on the first 3 octets of your IP, which doesn't really matter as when you actually go to lets say the website you were making the DNS request for would have your FULL IP address...Imagine that.

    My opinion: I think this is a good idea.

    ReplyDelete
    Replies
      Reply
  27. JulianJanuary 28, 2010 at 6:57 PM

    A great idea Google! As someone who operates distributed servers it would be great to point people to their closest server so they get a faster response time.

    Bit silly for people to be worried about the 3/4 of their ip address to be exposed - as soon as that dns request is completed they'll be sending the full ip address to the website provider to view the website!

    There's a lot of comments from people here who don't understand how DNS, TCP/IP, NAT or Satellite connections work - a lot of mis-information.

    Go read the protocol standards and you'll find that Satellite and private ip addresses (10.*.*.* etc that have to be NAT'd to use the internet) will work with this.

    If you think that your DNS queries should be private - you need to get off the internet. DNS requests have to passed to public servers in order to get the information you need.

    ReplyDelete
    Replies
      Reply
  28. ArnoJanuary 28, 2010 at 7:03 PM

    DNS is not broken. DO NOT MESS WITH IT for a slight performance gain for some (very few) users. If you really need the geographical data, get it on the actual network connection and implement a redirect in the application. Or alternatively require the people to use the Google DNS for maximum performance.

    Doing this by a DNS protocol change is entirely the wrong way and I can only attribute it to mental laziness.

    ReplyDelete
    Replies
      Reply
  29. JulianJanuary 28, 2010 at 7:25 PM

    @arno I'd say doing it in DNS is the right point - moving it up the protocol chain means that you wont have to make a connection and be redirected to a second server. Doing that slows down the response time to the user, resulting in more connections and increased network load.

    Google arn't saying DNS is broken, just that it can be improved with a fairly minor improvement.

    Granted that it wont be of use to 99% of websites that are hosted on a single server. But for any website that is on more than one server (and especially those in a cloud) this will make the users experience so much better.

    Ever had to wait for a website to load because its coming from the other side of the globe? This DNS change will help.

    ReplyDelete
    Replies
      Reply
  30. jrishawJanuary 28, 2010 at 7:34 PM

    Arno: This is not messing with the DNS Protocol, it is simply extending it. Anycast is "messing with dns," as is DNSSEC, by your argument. Invalid.

    Jared Mauch: (Hi) That was my first thought, actually..

    All: There are very few "privacy implications" to this - if you don't want your Internet activity monitored, unplug your computer. I'm a privacy advocate, but the first three octets of my IP is nothing.
    If I'm looking up 'www.google.com' in a DNS request, guess what. Not only is my *full* IP going to be logged once I connect to the site, browser information, hardware platform, and much other info will be sent along -- Complaining that this extension will violate privacy is kind of a silly attempt at a point.

    Allowing your ISP(if they don't already sell your data and habits already) to send this (essentially) geo-data to a nameserver so that it can direct you to a server "closer to you" is brilliant, and I'm glad Google and the guys at UltraDNS see and support this [full disclosure, I use UltraDNS].

    I'd like to see Vixie's point of view on this, but I doubt he'll be posting on blogspot anytime soon ;)

    ReplyDelete
    Replies
      Reply
  31. Mihai DanilaJanuary 28, 2010 at 9:16 PM

    Privacy, schmivacy. Wake up and embrace reality. Privacy is an illusion.

    But this concoction of an extension to the DNS protocol looks like an opportunistic move meant to reduce the pains and aches of a corporation's logistics. Doesn't feel like it's in the spirit of the internet.

    With my 50,000 foot level view of the mechanics of the internet, the benefit of the proposed change eludes me. But you and I are not a part of the internet draft review team, so why don't we wait and see what they have to say about this. I hope they judge the proposal on its merit and dismiss it promptly. Or else, we'll have created a precedent for a series of ridiculous tuning proposals for the internet in an increasingly narcissistic community.

    Like Arno and others said, keep your redirects higher up the protocol stack. And stop whining about how much better off we would all be if we didn't have to create a TCP connection to redirect until you've come up with thorough stats representative of the internet at large.

    Man, people these days.

    ReplyDelete
    Replies
      Reply
  32. arshadJanuary 28, 2010 at 9:46 PM

    its really very nice i enjoyed a lot to visit..Mobiles Handsets

    ReplyDelete
    Replies
      Reply
  33. Viet LaJanuary 28, 2010 at 10:08 PM

    Sound good.

    ReplyDelete
    Replies
      Reply
  34. MickeyCJanuary 29, 2010 at 2:02 AM

    Re: jyaif

    "Even if just Google uses this protocol, 70% (at least) of the internet users will gain time.
    Kapow."

    You don't get it do you? What proportion of Internet users use a DNS resolver that's not in their own country? 0.01%? Less? What percentage of websites are distributed across multiple countries? 0.0001%? Less? Multiply those two figures together and what do you get? I can guarantee you it's not near "70%"

    For the tiny minority of sites that want websites to run from multiple countries, they can either deal with the issue with anycast, or deal with it at the HTTP level. There are many possibilities. It doesn't require a change to DNS

    ReplyDelete
    Replies
      Reply
  35. mihaiJanuary 29, 2010 at 6:09 AM

    @MickeyC it's not just about the percentage of sites but also about the amount of traffic they get.
    Also the big sites are not only distributed across countries but also across zones within the same country ( google, amazon, ebay, yahoo , etc )

    Still I think they could it by using even 2 bytes instead of 3 so people would be less concerned about privacy.
    Also the privacy concern here is not about the sites where the user ends up but about all the intermediary DNS servers that forward a query. Now only the destination site ( well, actually some others too like ad servers that post ads on the site and every device between you and the destination sites or ad servers ) will know who you are but after this is implemented a lot of other third parties that you can't really track will know.

    Someone mentioned this should be opt in instead of opt out and I fully agree with this.

    ReplyDelete
    Replies
      Reply
  36. MickeyCJanuary 29, 2010 at 8:16 AM

    mihai:

    Most people are using a DNS server in the same country that they are in, so Google already makes a good guess about which server to point them to. None of these people will benefit.

    That drops the 70% claim to something far far below 1% even if every single person on the Internet is using Google all the time...

    It would not be feasible to make such a system opt in. They should just use one of the many other methods available to get the user connecting to a close server, rather than fudging DNS.

    ReplyDelete
    Replies
      Reply
  37. Carlo ContavalliJanuary 29, 2010 at 8:27 AM

    Thanks all for the lively debate! We wanted to clarify a few points below.

    Regarding privacy concerns: Every time you visit a site, your browser does a DNS lookup followed by many HTTP connections to fetch the various components of the page (images, frames, or even ads or popups). With each HTTP connection, you are sharing your full IP address. What this draft proposes is giving only the top 24 bits (a partial amount) of this information earlier on in the process, so the DNS server can make better decisions.

    Regarding concerns about modifying the DNS protocol: This proposal is optional. It does not modify the DNS protocol itself but uses EDNS0, a mechanism that is already part of the DNS protocol that allows new extensions to be developed and added. It is similar to having a new header in the HTTP protocol; it can be used and implemented, but is not required.

    Regarding concerns about root or TLD servers: Root servers, ICANN, and owners of TLD servers will not see any increase in load if the specifications are implemented correctly. An improper implementation will just send a few extra bytes with client-ip information attached. There will be no increase in the number of queries or traffic generated. The root and TLD servers will ignore the EDNS0 option, returning a result that will be cached as always.

    Regarding concerns about caches and increased load on recursive resolvers: if you run a recursive resolver that is handling a few networks only, or networks that are topologically close to each other, you will have no need to enable this extension. In contrast, if you are running open resolvers or resolvers serving many different networks, chances are that to reduce the latency experienced by your users, you already invested resources to have multiple resolvers in different locations, finding ways to share the cache or duplicating the content of your caches. The proposed extension allows recursive resolvers to clearly see which results are localized, and for which networks the results can be cached. This will allow resolvers to implement smarter caching algorithms, better decide how to cache results, and to reduce latency by having more precise information about the user's location early on in the process, rather than when they have already opened an HTTP connection.

    ReplyDelete
    Replies
      Reply
  38. cparenteJanuary 29, 2010 at 10:49 AM

    Ha -- I was going to say the same thing, thanks @Julian. I'm all for privacy, but the full IP address will be visible as soon as the connection is made anyway. Seems to me this step simply makes sure the whole connection starts smoother/faster/better, right?

    Discloser comment -- I work for Neustar,and think this is pretty cool.

    ReplyDelete
    Replies
      Reply
  39. Steven RousseyJanuary 29, 2010 at 11:05 AM

    @jrishaw et al: Yes, I get the feeling that people don't understand that their IP address is given to Google when they go to google. However, for people using things like proxies or Tor, having the IP address go up the ISP chain is an information leak. Of course, it always was. This just makes the leak a little bigger.

    For people in free countries and with a rule of law and not half-trying to hide their tracks, this proposal will help make things faster. That is 99.9% of the users in the US/Europe.

    For a very small number of people that use a proxy for http but not for dns, this will be a problem. People using script-kiddie level privacy tools are the ones for which this might make a information leak (to say, Chinese authorities -- though their servers are likely already passing IP info around). For people that really know how to hide their tracks it will make no difference.

    ReplyDelete
    Replies
      Reply
  40. YoursJanuary 29, 2010 at 6:44 PM

    There is no need for this DNS extension as niche networking vendors ALREADY offer appliances which globally load balance DNS requests with very low TTL's and can also act as the Authoritative Server for zones. There are already companies out there which specialize in serving key data for Geo-LBing, anyone ever heard of http://www.quova.com/

    Can Google focus their efforts on more important DNS related items such as DNSSEC which can mitigate spoofing and man in the middle attacks by implementing chains of trust between Authoritive and downstream recursive DNS Servers?

    Hmm? Makes one wonder what settings they already have inside their Chrome browser to track one's www surfing trends?

    -thx

    ReplyDelete
    Replies
      Reply
  41. marionJanuary 29, 2010 at 11:39 PM

    I recently came accross your blog and have been reading along. I thought I would leave my first comment. I dont know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

    Alena

    http://dataentryjob-s.com

    ReplyDelete
    Replies
      Reply
  42. SimonJanuary 31, 2010 at 11:17 AM

    This comment has been removed by the author.

    ReplyDelete
    Replies
      Reply
  43. SimonJanuary 31, 2010 at 11:20 AM

    This appears like a good and important improvement if you want cloud services to be faster, cheaper, greener. For those not directly affected, can perhaps expect some performance improvement from secondary effects when the backbone networks are less filled with cross-country traffic that can rather go local. Let's allow some evolution in the internet protocols. Refusing change is not the way to make the internets' tubes better.

    ReplyDelete
    Replies
      Reply
  44. Valentine GogichashviliFebruary 1, 2010 at 3:09 AM

    And what about privacy? It will make it easy for the governments to control their citizens. Google first makes a lot of noise on the Human Rights Issue in China and then suggests to make the job of repressive regimes even easier! It is disgusting :(

    ReplyDelete
    Replies
      Reply
  45. kiramatali shahFebruary 1, 2010 at 3:10 AM

    After last post on marketing without search engines, I decided to follow up with a strategy you can use to get quality free traffic. One of the easiest ways to get visitors to your web site is to spend money. Nothing is more effortless then paying for traffic. But if you can’t afford it or don’t want to pay, there’s an equally simple but free way to get traffic: ad swaps.

    www.onlineuniversalwork.com

    ReplyDelete
    Replies
      Reply
  46. Chris McElroy aka NameCriticFebruary 4, 2010 at 6:30 PM

    Will this enhance Google Caffeine and Google Local Search? Is that the real reason to want part of the user's IP address and Google wanting the ability to route users to specific servers?

    ReplyDelete
    Replies
      Reply
  47. Gap InfotechFebruary 5, 2010 at 9:20 PM

    Residential Property In Gurgaon
    Website Development Company in Ncr

    nice blog

    ReplyDelete
    Replies
      Reply
  48. bellFebruary 9, 2010 at 11:21 PM

    Why use ip-address? How will this be in IPv6? How much should be sent then? Why not a country/state code in stead? (us/nj) (us/ca) (dk) (de) I would believe the ISP already knows where the customer is located... And it ought to be possible somehow not to send that information.

    ReplyDelete
    Replies
      Reply
  49. TrurlNovember 17, 2010 at 12:58 AM

    Better solution just add into DNS request optional location information (for example Coutry+City). If forwarder has received location from requestor he will send it to authoritative nameservers as is. If got nothing will send own location. In most case location will be from local provider forwarder nameservers. Sometimes - from real client.

    ReplyDelete
    Replies
      Reply
  50. solanaJanuary 1, 2011 at 7:42 AM

    The link "proposal to extend the DNS protocol" (pointing to http://www.ietf.org/id/draft-vandergaast-edns-client-ip-00.txt) is currently broken. It should point to http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01.

    ReplyDelete
    Replies
      Reply
  51. Tim WintleJanuary 17, 2012 at 8:29 AM

    Truri, Bell - Location-based DNS responses are based on the network location of the client - not the Geo-location.

    I.e. If I'm on a mobile device then I want to be be redirected to a server near to my network operator's data link, not to a server near where my device happens to be.

    The IP address is *exactly* the right information to use for this, no other data would give a correct result.

    For people saying that there are already companies who offer this service, this only works if the Authoritative nameservers receive the request direct from the client, and it breaks when a global dns proxy is being used (e.g. ISPs' dns servers, Google DNS, OpenDNS) - this proposal is to fix that and to allow the same service to be implemented correctly (by Google and the existing companies) when the request is coming through a non-authoritative nameserver.

    For IP V6 - it's specified in the link.

    ReplyDelete
    Replies
      Reply
Add comment
Load more...

  

Labels


  • .app
  • .dev
  • #AIY
  • #CSEdWeek
  • #devfest18 #devfeststories #gdg #googledevelopers #developers #community
  • #freeandopen
  • #GDC20
  • #GooglePlay #AndroidDevStory #PlayStore #DeveloperConsole #StoreListingExperiments
  • #growwithgoogle
  • #io12
  • #io13
  • #io14
  • #io15
  • #io16
  • #io17
  • #io18
  • #io2012
  • #io2013
  • #io2014
  • +1
  • 20% project
  • 3d
  • 3D face mesh
  • about.com
  • accelerator
  • Access
  • accessibility
  • Account Linking
  • actions
  • Actions Builder
  • Actions console
  • actions on google
  • Actions SDK
  • actionsongoogle
  • activity
  • Administrative APIs
  • AdMob
  • adobe
  • Adobe Creative Cloud
  • Adobe Creative Cloud Libraries
  • Ads
  • adsense
  • advanced
  • advogato
  • AdWords
  • africa
  • agency program
  • agpl
  • AI
  • AI Principles
  • AIY
  • AIY Projects
  • AIYProjects
  • ajax
  • ajax apis
  • ajax search
  • ajax search books news apis
  • Alfred Camera
  • all for good
  • amarok
  • AMP
  • AMP Cache
  • analytics
  • and Assistant
  • android
  • Android App Development
  • Android Developer
  • android developer certification
  • android developers
  • Android Development
  • Android Studio
  • Android Things
  • Android Tools
  • Android TV
  • android wear
  • android11
  • androidstudio
  • animation
  • Announcement
  • announcements
  • apache
  • api
  • API.AI
  • apis
  • apis console
  • apis explorer
  • apis. charts
  • app
  • app design
  • App dev
  • App Development
  • app engine
  • app indexing
  • app indexing api
  • App Invites
  • apple
  • Application Development
  • apps
  • apps script
  • AR
  • ARCore
  • area 120
  • artifact management
  • Artificial Intelligence
  • asia
  • assistant
  • atom publishing protocol
  • Audio
  • augmented faces
  • Augmented images
  • augmented reality
  • australia
  • Auth
  • authentication
  • authsub
  • automatic speech recognition
  • AutoML
  • awards
  • axsjax
  • barcodes
  • beacon
  • beacons
  • Belarus
  • bespin
  • best practices
  • beta
  • bigquery
  • bitcoin
  • Black Consciousness Day
  • Blockly
  • blogger
  • Bluetooth
  • book search
  • books API
  • bootcamp
  • braintree
  • Brazil
  • british english
  • Brotli
  • browser
  • Build Out
  • building ajax apps
  • BuildOut
  • Bulgaria
  • business
  • business console
  • buzz
  • c++
  • Cache
  • caja
  • caldav
  • calendar
  • camino
  • campfire one
  • caption
  • cardboard
  • CardDAV
  • cast
  • Cast Connect
  • celebrating
  • Certification
  • certification award
  • channel
  • chinese
  • chrome
  • chrome apps
  • chrome dev summit
  • chrome devtools
  • chrome experiment
  • chrome extensions
  • chrome os
  • Chrome OS IO
  • Chrome OS IO19
  • chrome web store
  • Chromebooks
  • chromecast
  • chromium
  • chronoscope
  • cifs
  • classes
  • classroom api
  • client libraries
  • closure tools
  • cloud
  • Cloud anchor
  • Cloud Anchors
  • Cloud Computing
  • cloud datastore
  • Cloud Functions
  • cloud functions for firebase
  • Cloud Next
  • cloud platform
  • cloud portability
  • cloud services
  • cloud sql
  • cloud storage
  • Cloud Study Jam
  • cms
  • coca cola
  • CocoaPods
  • code for educators
  • code jam
  • code review
  • code-in
  • codeedu
  • codelabs
  • coding
  • coffee with a googler
  • Colaboratory
  • collada
  • color
  • Colt McAnlis
  • commerce
  • community
  • community connectors
  • compatibility
  • competition
  • Compilers
  • compression
  • compressorhead
  • computer science
  • Computer Science Education Week
  • computer vision
  • computing heritage
  • conference
  • conferences
  • Console
  • contacts api
  • Containers
  • contest
  • contextual gadgets
  • conversation design
  • conversations
  • Coral
  • Coral updates
  • Core ML
  • couchdb
  • countdown to I/O 2012
  • country support
  • courses
  • COVID
  • COVID-19
  • COVID19DetectProtect
  • CPU
  • crash course
  • Crash Reporting
  • crashlytics
  • creative commons
  • cricket
  • crisis response
  • Croatia
  • Crostini
  • cryptocurrency
  • cryptography
  • css
  • css3
  • Custom Elements
  • custom search
  • custom search api
  • Czechia
  • DA
  • danish linux forum
  • dart
  • Data Compression
  • Data science
  • Data Visualization
  • database
  • Databases
  • Dataset
  • Datasets
  • datastore
  • dataviz
  • Daydream
  • deprecation
  • Depth
  • design
  • desktop
  • desktop apps
  • Dev Tools
  • devart
  • develop
  • developer
  • Developer Advocate
  • Developer Communities
  • Developer Culture
  • developer expert
  • developer features
  • Developer Keynote
  • Developer Preview
  • developer relations
  • developer student clubs
  • developers
  • developers. meetup
  • Development
  • devfest
  • devfest developer chrome maps social wave apps
  • DevFest18
  • DevFestStories
  • Device
  • DFP
  • Dia da Consciência Negra
  • dialogflow
  • differential privacy
  • discovery service
  • diversity
  • django
  • dns
  • do-it-yourself
  • Docker
  • docs
  • documentation
  • documents list api
  • dojo
  • domain
  • domains
  • doodles
  • dot net
  • doubleclick
  • dreamweaver
  • Drive
  • drupal
  • dsc
  • dynamic links
  • earn
  • earth
  • Ebay
  • eclipse
  • eclipsecon
  • eddystone
  • Edge AI
  • Edge TPU
  • Edge TPU Accelerator
  • Edge TPU Dev Board
  • educatio
  • education
  • email
  • EMEA
  • endpoints
  • enterprise
  • Entity Extraction
  • entrepreneurs
  • Error logging
  • Estimator
  • Estimators
  • estonia
  • Ethics
  • Europe
  • event
  • events
  • evolution
  • execution api
  • extensions
  • Fabric
  • face detection
  • Fairness
  • fairness in machine learning
  • faster web
  • FCM
  • FCP
  • featured
  • feeds
  • finance
  • fintech
  • Firebase
  • Firebase Analytics
  • Firebase Cloud Messaging
  • Firebase Dynamic Links
  • firebug
  • firefox
  • firestore
  • firevox
  • firstbeta
  • fitness
  • flutter
  • Flutter 1.2
  • Flutter 1.5
  • Flutter 1.9
  • Flutter at IO
  • Flutter Clock
  • Flutter Create
  • Flutter for desktop
  • Flutter for web
  • Flutter Interact
  • Flutter Live
  • flutter release preview 1
  • flutter release preview 2
  • Follow Us
  • font api
  • Fonts
  • fosdem
  • founders
  • freebsd
  • freenet
  • Fridaygram
  • fusion tables
  • G Suite
  • G Suite Developer
  • G+
  • gadgets
  • Game Developers Conference
  • games
  • gaming
  • gcc
  • gci
  • GCP
  • GDA
  • gdata
  • GDC 2020
  • GDC17
  • GDD
  • gdd07
  • gdd08
  • gdd09
  • GDD11
  • GDE
  • gdg
  • gdl
  • gdl weekly
  • gears
  • geo
  • geolocation
  • geoserver
  • GET
  • getpaid
  • ghop
  • Gigster
  • git
  • github
  • GKE
  • Glass
  • gmail
  • Gmail Add-on
  • Gmail API
  • Gmail APIs
  • GMTC
  • gnome
  • gnome women's summer outreach program
  • Go
  • golang
  • goo.gl
  • Google
  • Google AI
  • Google Analytics
  • Google APIs
  • google apps
  • google apps api
  • google apps for your domain
  • google apps marketplace
  • Google AR
  • google assistant
  • Google Assistant Bluetooth
  • Google Assistant Developer Day
  • Google Assistant IO
  • Google Assistant IO19
  • google assistant sdk
  • Google Brain
  • google buzz
  • Google Cardboard
  • google cast
  • google certification
  • google chart api
  • Google Charts
  • google checkout
  • google chrome
  • Google Cloud
  • Google Cloud Messaging
  • Google Cloud Platform
  • google cloud storage
  • Google Cloud Talks
  • google code
  • google code project hosting
  • google code search
  • google code university
  • google compute engine
  • Google Coral
  • google data apis
  • google data protocol
  • Google Data Studio
  • google developer day
  • google developer days
  • Google Developer Experts
  • Google Developer Groups
  • Google Developer Scholarship
  • google developers
  • Google Developers Academy
  • google developers certification
  • google developers community groups
  • Google Developers Groups
  • Google Developers Live
  • Google Developers site
  • Google Developers University Consortium
  • google docs
  • Google Docs Add-on
  • Google Docs API
  • google doctype
  • google domains
  • Google Drive
  • Google Drive SDK
  • google earth
  • google fit
  • Google Fonts
  • Google For Games
  • google for startups
  • google friend connect
  • google gadgets
  • google gears
  • google grants
  • Google Groups Settings
  • google health
  • Google Home Hub
  • Google I/O
  • Google Identity Platform
  • Google in Asia
  • google io
  • Google IOS Android
  • Google Maps
  • Google Maps Platform
  • google mashup editor
  • Google Noto fonts
  • google pay
  • google pay account
  • google pay api
  • google pay business
  • Google Pay Developers
  • Google Pay India
  • google pay integration
  • google pay support
  • google photos
  • google platform
  • Google Play
  • Google Play Developer API
  • google play services
  • Google Registry
  • google scholarships
  • Google Science Fair
  • Google sheets
  • Google Sheets Add-on
  • Google Sheets API
  • Google Slides
  • Google Slides Add-on
  • Google Slides API
  • google space
  • Google Spreadsheets API
  • google storage
  • google summer of code
  • Google tech talk
  • Google technology
  • google technoloy user groups
  • google tv
  • google visualization api
  • google wallet
  • Google Wave
  • google web elements
  • google web toolkit
  • Google Workspace
  • Google Workspace Add-ons
  • Google Workspace Developer
  • google.org
  • google+
  • GoogleAssistant
  • googlecast
  • googledevelopers
  • googleio
  • googlenew
  • GooglePlay
  • GooglePlay AndroidDev
  • googlewebelements googleio
  • GPE
  • GPGS C++ Games
  • GPT
  • Gradle
  • green linux
  • Groovy
  • Groups API
  • grow
  • grow with google
  • gsoc
  • GSuite
  • gtags
  • gtug
  • guest post
  • guice
  • gulp
  • GWSOP
  • gwt
  • gzip
  • hackathon
  • hacking
  • hackthon
  • hamilton
  • Handwriting
  • hangouts
  • Hangouts Chat
  • Hangouts Chat API
  • haproxy
  • Headset
  • hg
  • hibernate
  • howto
  • hpux
  • html
  • html5
  • http
  • I/O
  • I/O 17
  • I/O 2017
  • I/O Extended
  • I/O Live
  • ical
  • ICYMI
  • identity
  • ietf
  • ignite
  • igoogle
  • iguanas
  • iiw
  • Image Compression
  • image search
  • Imara
  • In-app billing
  • in-app payments
  • in-app purchase
  • incubator
  • India
  • indie
  • Indie Games Accelerator
  • information visualization
  • Instagram
  • integration status
  • intelligentwire
  • interactive music
  • International Women’s Day
  • internationalization
  • internet explorer
  • internet of things
  • internship
  • interviews
  • IO
  • IO17
  • io18
  • IO19
  • IO19 Flutter
  • IO2017
  • ios
  • iOS SDK
  • IoT
  • ipad
  • iphone
  • iPhone Development
  • israel
  • Issue Tracker
  • IWD 2020
  • jaiku
  • japanese
  • java
  • javascript
  • jetpack
  • joomla
  • joomladayus2007
  • joomladayusa
  • JS
  • json
  • karaoke
  • KDE
  • KDE 4.0
  • Keras
  • kernel
  • kernel summit
  • keynote
  • khronos
  • kids
  • kids coding
  • kids coding team
  • kml
  • korean
  • Kotlin
  • Krakow
  • Kubernetes
  • labs
  • lanchpad
  • language
  • languages
  • laptop apps
  • laptops
  • latam accelerator
  • LatAm startups
  • Latest
  • Latin America
  • latitude
  • latvia
  • launch
  • launchpad
  • launchpad accelerator
  • launchpad studio
  • LaunchShow
  • lca
  • Leadership
  • Learning
  • lens
  • lessons
  • licenses
  • linux
  • linux foundation
  • Linux on Chrome OS
  • Linux on Chromebooks
  • linux summit
  • linux virtual server
  • linuxconf eu
  • lithuania
  • Local Home
  • Local Home SDK
  • localization
  • Location
  • LoCo
  • Logging
  • london
  • mac
  • MacFuse
  • Machine
  • machine intelligence
  • machine learning
  • machine learning accelerator
  • maker
  • Makers
  • malware
  • maps
  • maps apis
  • Marketplace
  • material
  • material components
  • material design
  • MDL
  • MediaPipe
  • meetup
  • mercurial
  • Mexico startups
  • Micronaut
  • Microservices
  • MIT CSAIL
  • MIT Media Lab
  • ml
  • ML Kit
  • MLCC
  • mobile
  • Mobile App Development
  • mobile design
  • Mobile Development
  • mobile performance
  • mobile sites
  • mobile speed
  • mobile UX
  • Mobile web
  • Mobile World Congress
  • mod_pagespeed
  • Moderator
  • monetize
  • Monthly roundup
  • MOOC
  • mozilla
  • multi-platform
  • mylar
  • myspace
  • MySQL
  • mythtv
  • named
  • narratives
  • native ads
  • native client
  • nearby
  • Nest
  • Nest WiFi
  • netbsd
  • Next Billion Users
  • non-profit
  • nonsense
  • nosql
  • notifications
  • Noto Serif CJK
  • NPM
  • nss
  • nvidia
  • NYT
  • O3D
  • oauth
  • OAuth playground
  • OAuth2
  • Object Detection and Tracking
  • objective-c
  • OCaml
  • Occlusion
  • ocr
  • ODF
  • office hours
  • oha
  • online payments
  • OOXML
  • open data
  • open source
  • open source blog
  • open source releases
  • open web
  • open-source
  • openajax alliance
  • opengl
  • openid
  • opensocial
  • openssh
  • openssl
  • Optimization
  • oreilly
  • orkut
  • oscon
  • oscon2007
  • osi
  • oss devs
  • ossjam
  • osx
  • pactester
  • page speed
  • PageSpeed
  • palette
  • payment handler
  • payment request api
  • payment web standard
  • payments
  • paypal
  • Peer bonus program
  • performance
  • persistence
  • persistent AR
  • phone
  • photos
  • picasa
  • picasa web
  • places API
  • play services
  • playground
  • plone
  • plone sprint
  • podcast
  • poland
  • Poly
  • polymer
  • Polymer Summit
  • portugal
  • Pose Detection
  • Pose Estimation
  • posix
  • POST
  • PowerMeter API
  • prediction api
  • Prerender
  • preview
  • privacy
  • prizes
  • processing
  • production access
  • programmers
  • programming
  • Progressive Web App
  • Project Connected Home over IP
  • project hosting
  • Project Loon
  • Project Tango
  • prototype
  • proximity
  • pubsubhubbub
  • PWA
  • py3k
  • python
  • python sprint
  • Qualcomm
  • Qualcomm Google
  • rails
  • random hacks of kindness
  • Rasberry Pi
  • React
  • reader
  • releases
  • Remote Config
  • research
  • reserve seats
  • Resources
  • Responsible AI
  • REST
  • result snippets
  • Reto Meier
  • review process
  • Rewarded Ads
  • Rewarded Video Ads
  • rhino
  • Saatchi
  • Safety & Security
  • safety and security
  • salesforce
  • samba
  • Sample dialogs
  • sandbox
  • Santa Tracker
  • Scala
  • scalability
  • scale-ups
  • Sceneform
  • schedule
  • scholarship
  • scholarships
  • scopes
  • Scratch
  • screencast
  • sdk
  • sdks
  • search
  • security
  • Selfie Segmentation
  • Serbia
  • serif
  • Serverless
  • service worker
  • sessions
  • seurat
  • shape
  • Sheets
  • Sheets API
  • shindig
  • shopping
  • Shoreline Amphitheatre
  • shortcuts
  • showcase
  • sidewiki
  • sign-in
  • silverstripe
  • SIMD
  • sitemaps
  • sites api
  • sixapart
  • sketchup
  • Slides API
  • small business
  • small businesses
  • Smart Home
  • Smart Lock for Passwords
  • soap search api
  • soc
  • social
  • social graph
  • solaris
  • solutions challenge
  • souders
  • spa2007
  • Space
  • spdy
  • speakers
  • speech
  • speed
  • speed tracer
  • Spring
  • spyware
  • Stable release
  • Stackdriver
  • standards
  • startup
  • Startup accelerator
  • startup africa roadtrip
  • startups
  • Static Sites
  • STEM
  • storage
  • stories
  • Street View
  • Strobe
  • student programs
  • students
  • stuff
  • style
  • subscribed links
  • subscription
  • subversion
  • summer of code
  • Sundar Pichai
  • SVG
  • sxsw
  • syndication
  • targeted spyware
  • tasks API
  • Team Drives (new)
  • techmakers
  • Technical Writing
  • technology
  • templates
  • TensorFlow
  • tensorflow dev summit
  • TensorFlow Lite
  • TensorFlow Research Cloud
  • tensorRT
  • Test Lab
  • testing
  • text embedding models
  • Tez
  • TF Lite
  • tfdevsummit
  • TFLite
  • themes
  • thought leadership
  • tool
  • Toolkit
  • tools
  • topp
  • TPU
  • TPU Dev Board
  • training
  • Traits
  • tranparency
  • transit
  • translate
  • translation
  • tutorials
  • tv
  • ubiquitous computing
  • ubiquity
  • ubucon
  • ubuntu
  • Udacity
  • UI
  • Ukraine
  • UN
  • UNDP
  • UNICEF
  • unicode
  • unit test
  • Unity
  • universal
  • Universal App Campaigns
  • University
  • unix
  • Update
  • updates
  • url
  • url shortener
  • URLs
  • UX
  • verification
  • video
  • videos
  • Vim
  • virtual keyboard
  • virtual reality
  • visualization
  • voice
  • voice kit
  • voice user interface
  • VR
  • VUI
  • wattpad
  • Wearables
  • Weave
  • web
  • web animations api
  • web apps
  • web components
  • web design
  • web designer
  • web development
  • web exponents
  • web fonts
  • web performance
  • web platform docs
  • web registry
  • webfonts
  • webgl
  • webmaster
  • WebP
  • website optimizer
  • websites
  • webVR
  • weekly roundup
  • WhiteHouse.gov
  • Who's at Google I/O
  • win
  • windows
  • windows programming
  • Winter of Code
  • women developers
  • Women in Tech
  • Women Tech Makers
  • women techmakers
  • WomenTechmakers
  • writing
  • wtm
  • xauth
  • yahoo
  • young developers
  • Young Makers
  • youtube
  • zlib
  • zurich
  • ZXing


Archive


  •     2021
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2014
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2010
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2009
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2008
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2007
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2006
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2005
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
Subscribe
Visit Google Developers for docs, event info, and more.
  • Google
  • Privacy
  • Terms