{"id":103,"date":"2006-05-05T05:20:00","date_gmt":"2006-05-05T05:20:00","guid":{"rendered":"http:\/\/blog.trungson.com\/?p=103"},"modified":"2006-05-05T05:20:00","modified_gmt":"2006-05-05T05:20:00","slug":"powerdns-geobackend-readme","status":"publish","type":"post","link":"http:\/\/blog.trungson.com\/?p=103","title":{"rendered":"PowerDNS geobackend README"},"content":{"rendered":"<pre>\nPowerDNS geobackend setup notes\n===============================\n\nThese are the steps I went through to set up geobackend for PowerDNS on FreeBSD\n-STABLE.  By the time you read this maybe geobackend is part of the PowerDNS\nmain CVS so perhaps not much of this will apply.  In that case you should skip\nfurther down to the configuration part.\n\nBefore I carry on I should probably point out that if you don't know how DNS\nworks much, or if you have never installed PowerDNS ever before, then you\nprobably won't understand any of this.  In that case you should probably go and\ndo some reading\/practicing before trying to set this up for yourself.  As a\nminimum of DNS knowledge I would say you need to understand:\n\n- Basically how DNS servers answer queries\n\n- What common DNS terms like \"CNAME\" \"RR\" and \"SOA\" mean\n\n- How to use diagnostic utilities such as \"dig\" to test your setup.\n\nSo, how this should work on Linux or any general Unix system.  This didn't work\nfor me so I ended up having to do it another way, but anyhow..\n\n1. Download PowerDNS source from http:\/\/www.powerdns.com\/downloads\/index.php -\n   you want the GPL sources.\n\n2. Edit configure.in in the main directory so that where it has the list of\n   backends at the bottom, you add:\n\n   modules\/geobackend\/Makefile\n\n3. $ cd modules\n\n   and get the geobackend:\n\n   $ cvs -d :pserver:anon@cvs.blitzed.org:\/data\/cvs login\n   (press <return> at password prompt)\n   $ cvs -d :pserver:anon@cvs.blitzed.org:\/data\/cvs co -d geobackend geo-dns\n\n   $ cd ..\n\n   to return to top of build directory.\n\n4. Regenerate the autotools with:\n\n   $ aclocal\n   $ autoheader\n   $ automake --add-missing --copy --foreign\n   $ autoconf\n\n5. Do a .\/configure with the flags you normally would use, but also\n   --with-dynmodules=\"geo\"\n\n6. Install PowerDNS as normal for how you would normally use it.\n\nThis did not work for me on FreeBSD: no matter what combination of autoconf,\nautomake, libtool was installed I would always get one error or another at the\nstage where I was running those commands.  So, after a few hours of messing\naround I decided to just compile the geobackend outside of the PowerDNS source\ntree.  Probably if\/when geobackend is made part of PowerDNS, this will \"just\nwork\", but in the meantime here's what I did:\n\n1. Install PowerDNS from the port \/usr\/ports\/dns\/powerdns as normal.  Do not do\n   a \"make clean\" yet though!  Make sure your PowerDNS works as you'd expect\n   without any of this geobackend stuff before going further.\n\n2. Somewhere else, get the source of our geobackend as above in step 3.\n\n3. Compile geobackend:\n\n   $ c++ -I\/usr\/ports\/dns\/powerdns\/work\/pdns-2.9.15 -O2 -Wall -c geobackend.cc\n   $ c++ -I\/usr\/ports\/dns\/powerdns\/work\/pdns-2.9.15 -O2 -Wall -c ippreftree.cc\n   $ c++ ippreftree.o geobackend.o -Wl,-soname -Wl,libgeobackend.so.0 -shared -o libgeobackend.so\n\n   All of those should compile and link without error.\n\n4. Now you need to copy that shared library to the system library directory, as\n   root:\n\n   # cp libgeobackend.so \/usr\/local\/lib\/\n\n\nNow whichever way you managed to get libgeobackend.so compiled, you are now\nready to configure PowerDNS.  This is what Blitzed's configuration looks like\nright now (but this is very much an experiment so things are bound to get out\nof date quickly).\n\nBy the way, I could not find a SysV-style startup script installed by the\nFreeBSD port so I had to copy one from debian and put it in\n\/usr\/local\/etc\/rc.d\/pdns.sh.  You can get that file here:\nhttp:\/\/nubian.blitzed.org\/pdns.sh\n\nAnd another thing is that the FreeBSD port doesn't add any new users for\nPowerDNS's use.  You probably don't want to run it as root even without our\ncode in it!  So be sure to add some sensible user and group like \"pdns\".\n\nPowerDNS Configuration\n======================\n\nHere is the relevant parts of my \/usr\/local\/etc\/pdns.conf file as running on\nFreeBSD -STABLE:\n\n<textarea name=\"code\" class=\"xml\">\n# -------------------------------------------------------------------------\n# mathie: specify IP to bind, easier, don't run into trouble & stay anonymous\nlocal-address=xxx.xxx.xxx.xxx\nversion-string=anonymous\n\n# To make it run as user@group pdns:pdns instead of root:root\nsetgid=pdns\nsetuid=pdns\n\n# These totally disable query+packet caching for all zones.  This is necessary\n# because otherwise when the exact same question is asked twice in a short\n# period of time (by default, 10 seconds), the same response will be given\n# without any backends getting involved.\n#\n# This is bad for geobackend because obviously every question can potentially\n# require a new answer based only on the IP of the user's nameserver.  Now, it\n# should be noted that if you have other zones in PowerDNS then they will have\n# their query cache disabled as well.  That's not ideal, so you probably want\n# to run a separate instance of PowerDNS just for geobackend.  Maybe one day\n# there will be config options to set per-zone query caching time or something.\nquery-cache-ttl=0\ncache-ttl=0\n\n# Log a lot of stuff.  Logging is slow.  We will disable this when we are happy\n# things are working. :)\nloglevel=7\n\n# But these logs are not interesting at the moment\nlog-dns-details=no\n\n# This disables wildcards which is more efficient.  geobackend doesn't use\n# them, so if none of your backends need them, set this, otherwise comment it\n# out.\nwildcards=no\n\n# The geobackend\nlaunch=geo\n\n# The zone that your geo-balanced RR is inside of.  The whole zone has to be\n# delegated to the PowerDNS backend, so you will generally want to make up some\n# subzone of your main zone.  We chose \"geo.blitzed.org\".\n#\ngeo-zone=geo.blitzed.org\n\n# The only parts of the SOA for \"geo.blitzed.org\" that apply here are the\n# master server name and the contact address.\ngeo-soa-values=ns0.blitzed.org,hostmaster@blitzed.org\n\n# List of NS records of the PowerDNS servers that are authoritative for your\n# GLB zone.\ngeo-ns-records=ns0.blitzed.org,ns1.blitzed.org\n\n# The TTL of the CNAME records that geobackend will return.  Since the same\n# resolver will always get the same CNAME (apart from if the director-map\n# changes) it is safe to return a reasonable TTL, so if you leave this\n# commented then a sane default will be chosen.\n#geo-ttl=3600\n\n# The TTL of the NS records that will be returned.  Leave this commented if you\n# don't understand.\n#geo-ns-ttl=86400\n\n# This is the real guts of the data that drives this backend.  This is a DNS\n# zone file for RBLDNSD, a nameserver specialised for running large DNS zones\n# typical of DNSBLs and such.  We choose it for our data because it is easier\n# to parse than the BIND-format one.\n#\n# Anyway, it comes from http:\/\/countries.nerd.dk\/more.html - there are details\n# there for how to rsync your own copy.  You'll want to do that regularly,\n# every couple of days maybe.  We believe the nerd.dk guys take the netblock\n# info from Regional Internet Registries (RIRs) like RIPE, ARIN, APNIC.  From\n# that they build a big zonefile of IP\/prefixlen -> ISO-country-code mappings.\ngeo-ip-map-zonefile=\/usr\/local\/etc\/zz.countries.nerd.dk.rbldnsd\n\n# And finally this last directive tells the geobackend where to find the map\n# files that say a) which RR to answer for, and b) what actual resource record\n# to return for each ISO country code.  The setting here is a comma-separated\n# list of paths, each of which may either be a single map file or a directory\n# that will contain map files.  If you are only ever going to serve one RR then\n# a single file is probably better, but if you're going to serve many then a\n# directory would probably be better.  The rest of this documentation will\n# assume you chose a directory.\ngeo-maps=\/usr\/local\/etc\/geo-maps\n# -------------------------------------------------------------------------\n<\/textarea>\n\nMap configuration\n=================\n\nAbove you defined a directory which should contain one file for each RR you are\ngoing to serve.  This section describes the format for those files.\n\nThere is a perl script in the geo-dns module\n(http:\/\/cvs.blitzed.org\/geo-dns\/iso2region.pl) which will print out a useful\ntemplate for starting with.  There are just two lines you MUST add for your own\nsetup.  The one that Blitzed is using is here:\nhttp:\/\/nubian.blitzed.org\/irc.geo.blitzed.org\n\nThe first line you must add is the $RECORD line.  This tells the geobackend\nwhich RR within the geo-zone the file is for, so for example the file above\ngives:\n\n        $RECORD irc\n\nmeaning it is for irc.geo.blitzed.org.\n\nThe second line that must be present is the $ORIGIN line:\n\n        $ORIGIN iso.blitzed.org.\n\nThe rest of this file is a list of mappings of ISO country to RR, and the\n$ORIGIN line tells the geobackend how to qualify the RRs.  Any relative RR with\nbe qualified by adding a dot and then this $ORIGIN string onto it.  So all the\nrelative RRs that follow are actually in the \"iso.blitzed.org.\" zone.  If you want to refer to an RR outside the $ORIGIN, put a trailing dot.\n\nThe final mandatory line is the 0 mapping:\n\n        0 pool.blitzed.org.\n\nThis is the \"default\" mapping.  It's possible that you will get a query from an\nIP that is not represented in the nerd.dk zone.  Maybe it is a new allocation\nby a RIR, or maybe something unexpected happened like you got a query from IPv6\nor from an RFC1918 address.  Or, there could be some error elsewhere in the\ngeobackend that makes it want to give up.  In any of these cases it needs to\nreturn a CNAME to a useful default.\n\nThe default chosen for blitzed is \"pool.blitzed.org.\" (note the trailing dot\nputs it outside the $ORIGIN!).  At the moment, pool.blitzed.org is a\nround-robin of A records of all our connected servers, but the best way to\nhandle it is under debate.  Since it is in one of our regular zone files we\ncan change it later how we want.\n\nThe entire rest of the file is optional, and takes the format of an ISO country\ncode (number) and an RR to map it to.  iso2region.pl will have helpfully added\ncomments with the country name so you can see what is what:\n\n        # Belgium\n        56 eu\n\nLines starting with # are comments.  That's mainly so you can tell what the ISO\ncode corresponds to, and maybe later when you are tweaking where all these\ncountries will go to you can add some documentation for why you did it.\n\nThe \"56\" is the ISO country code (see\nhttp:\/\/www.iso.ch\/iso\/en\/prods-services\/iso3166ma\/02iso-3166-code-lists\/index.html)\nfor Belgium.  The \"eu\" tells the geobackend that if a query for\nirc.geo.blitzed.org should come in from someone in Belgium, then it should\nrespond with a CNAME for \"eu.iso.blitzed.org\".  That's it.  That is the RR that\ngets sent back.  Every other line in this file is the same, just code->RR maps.\n\nAt this point you might be wondering when the user gets the actual IP address\nsent to them.  The answer is that we have chosen to make our geobackend only\nrespond with CNAMEs to other RRs that are assumed to be hosted elsewhere in\nDNS.  Our main blitzed.org zone is hosted in bind servers like it has been for\nyears.  In that zone we have entries for every one of the RRs that appears on\nthe right hand side in the director-map.  A list of those RRs is as follows:\n\nan.iso.blitzed.org.\naf.iso.blitzed.org.\nas.iso.blitzed.org.\neu.iso.blitzed.org.\nna.iso.blitzed.org.\noc.iso.blitzed.org.\nsa.iso.blitzed.org.\n\nThese correspond to the ISO names for the regions\/continents (Antarctica,\nAfrica, Asia, Europe, North America, Oceania, South America) and are\nrepresented in our DNS at the moment by either a list of A records of servers\n\"near\" there, or else a CNAME to a \"nearby\" region.  For example we have no\nservers in Antarctica or Asia.  We just CNAME those to \"na.iso.blitzed.org.\" to\nsend those users to North American servers instead.  Doing it this way is just\nour first attempt, we are still experimenting and might decide to do it\ndifferent.  All you need to know is that the geobackend gives the CNAMEs you\ntell it to give, it's your business what those CNAMEs are and what they end up\nresolving to.\n\nDNS configuration\n=================\n\nTime to configure the things that go into your existing DNS setup:\n\n1. The geographically load-balanced zone needs to be delegated to your PowerDNS\n   servers.  For Blitzed we chose \"geo.blitzed.org.\", so:\n\n   geo          NS      ns0.blitzed.org.\n   geo          NS      ns1.blitzed.org.\n   geo          NS      ns2.blitzed.org.\n\n2. The lists of servers that correspond to each CNAME that your director-map\n   can possibly come up with.  The above configuration can only answer one of:\n\n   pool.blitzed.org.\n   an.iso.blitzed.org.\n   af.iso.blitzed.org.\n   as.iso.blitzed.org.\n   eu.iso.blitzed.org.\n   na.iso.blitzed.org.\n   oc.iso.blitzed.org.\n   sa.iso.blitzed.org.\n\n   We have no servers in Antarctica so we just send that to North America:\n\n   an.iso       CNAME   na.iso.blitzed.org.\n\n   Other regions that actually have servers light look like:\n\n   na.iso       A       1.2.3.4 ; Some server in North America\n   na.iso       A       2.3.4.1 ; Some other server in North America\n\n3. Eventually you probably will want to use a more friendly name than something\n   like \"irc.geo.blitzed.org.\".  At that point you could just do the equivalent\n   of:\n\n   irc  CNAME   irc.geo.blitzed.org.\n\n   BEAR IN MIND THAT THERE MIGHT BE BUGS IN THIS BACKEND AND IF YOU DO THIS TO\n   YOUR MAIN POOL AND IT STOPS RESPONDING, SENDS YOUR USERS TO THE WRONG SERVERS,\n   OR EVEN TO THE WRONG NETWORKS, OR ANYTHING ELSE UNFORTUNATE HAPPENS AT ALL,\n   THEN THAT'S JUST TOUGH LUCK AS THIS CODE COMES WITH NO WARRANTY, GUARANTEE\n   OR ASSURANCE OF ANY KIND!\n\nTesting\n=======\n\nOK!  If you're still awake after all that, it is ready to test.\n\nBy the way, at the moment some of the logging from the geobackend is a severity\n\"debug\" (facility \"daemon\" if using FreeBSD port).  The default FreeBSD -STABLE\ninstall does not log daemon.debug to any file.  If you don't add daemon.debug\nto your \/etc\/syslog.conf then you might not see some of the logs I shall talk\nabout later.  Most logging will be removed or made optional anyway as it slows\nthings down.\n\n- Start PowerDNS\n\n  # \/usr\/local\/etc\/rc.d\/pdns.sh start\n\n- Check your logs!  You should see something like this:\n\n<textarea name=\"code\" class=\"xml\">\n  Feb 26 16:07:45 nubian pdns[4661]: PowerDNS 2.9.15 (C) 2001-2004 PowerDNS.COM BV (Feb  9 2004, 23:40:35) starting up\n  Feb 26 16:07:45 nubian pdns[4661]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to t\nhe terms of the GPL version 2.\n  Feb 26 16:07:45 nubian pdns[4661]: Set effective group id to 1023\n  Feb 26 16:07:45 nubian pdns[4661]: Set effective user id to 1023\n  Feb 26 16:07:45 nubian pdns[4661]: Creating backend connection for TCP\n  Feb 26 16:07:45 nubian pdns[4661]: [geobackend] Parsing IP map zonefile\n  Feb 26 16:07:47 nubian pdns[4661]: [geobackend] Finished parsing IP map zonefile: added 53072 prefixes, stored in 132525 nodes using 1590300 bytes of memor\ny\n  Feb 26 16:07:47 nubian pdns[4661]: [geobackend] Parsing director map \/usr\/local\/etc\/geo-maps\/irc.geo.blitzed.org\n  Feb 26 16:07:47 nubian pdns[4661]: [geobackend] Finished parsing 2 director map files, 0 failures\n  Feb 26 16:07:47 nubian pdns[4661]: About to create 3 backend threads\n  Feb 26 16:07:47 nubian pdns[4661]: Done launching threads, ready to distribute questions\n<\/textarea>\n\n  As long as there were no errors, the server is ready, geobackend is probably\n  working.  You should now test with a suitable diagnostic tool:\n\n<textarea name=\"code\" class=\"xml\">\n  $ dig irc.geo.blitzed.org.\n\n  ; <<>> DiG 9.2.2 <<>> irc.geo.blitzed.org.\n  ;; global options:  printcmd\n  ;; Got answer:\n  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59602\n  ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 5, ADDITIONAL: 5\n\n  ;; QUESTION SECTION:\n  ;irc.geo.blitzed.org.           IN      A\n\n  ;; ANSWER SECTION:\n  irc.geo.blitzed.org.    0       IN      CNAME   eu.iso.blitzed.org.\n  eu.iso.blitzed.org.     1       IN      A       195.92.253.3\n  eu.iso.blitzed.org.     1       IN      A       213.193.225.252\n  eu.iso.blitzed.org.     1       IN      A       62.80.124.155\n  eu.iso.blitzed.org.     1       IN      A       80.196.158.72\n  eu.iso.blitzed.org.     1       IN      A       195.22.74.199\n\n  ;; AUTHORITY SECTION:\n  blitzed.org.            3600    IN      NS      sou.nameserver.net.\n  blitzed.org.            3600    IN      NS      bos.nameserver.net.\n  blitzed.org.            3600    IN      NS      iad.nameserver.net.\n  blitzed.org.            3600    IN      NS      phl.nameserver.net.\n  blitzed.org.            3600    IN      NS      sjc.nameserver.net.\n\n  ;; ADDITIONAL SECTION:\n  bos.nameserver.net.     43200   IN      A       203.20.52.5\n  iad.nameserver.net.     43200   IN      A       192.148.252.171\n  phl.nameserver.net.     7200    IN      A       203.56.139.102\n  sjc.nameserver.net.     43200   IN      A       205.158.174.201\n  sou.nameserver.net.     34825   IN      A       194.196.163.7\n\n  ;; Query time: 389 msec\n  ;; SERVER: 192.168.0.5#53(192.168.0.5)\n  ;; WHEN: Tue Feb 10 03:10:14 2004\n  ;; MSG SIZE  rcvd: 322\n\n<\/textarea>\n\n  What does this show?  Well first of all it tells us that we looked for the A\n  record of \"irc.geo.blitzed.org.\" (A records are the default RR for dig).\n  What we actually got back was a CNAME to \"eu.iso.blitzed.org.\"  At that point\n  the work of geobackend and our PowerDNS server as a whole is done.  All it is\n  designed to do is return a CNAME based on the location of the server doing\n  the query.  The server I did that from is in UK, so a response of\n  \"eu.iso.blitzed.org.\" is correct.\n\n  The rest of the data comes from the normal BIND9 nameservers that are\n  authoritative for the \"blitzed.org.\" zone, in this case a list of A records\n  corresponding to our EU servers.  Finally the list of authoritative servers\n  for \"blitzed.org.\" is given, those same BIND9 boxes.\n\n  Meanwhile in the syslog of nubian, we have:\n\n  Feb 10 03:07:02 nubian pdns[32106]: [geobackend] Serving irc.geo.blitzed.org CNAME eu.iso.blitzed.org to 82.195.224.5 (756)\n\n  Here you can see that 82.195.224.5 asked for \"irc.geo.blitzed.org.\" and was\n  served the mapping for ISO code 756: \"eu.iso.blitzed.org.\".  This log notice\n  will be useful for debugging and refining the director-map by hand, but\n  later it will probably be removed or made optional.\n\nOngoing maintenance\n===================\n\nNew IPs are regularly allocated, also there may end up being corrections to the\nnerd.dk zones, so you should arrange to rsync this file every so often.  I'm\nguessing once a week would be adequate.  You may not be satisfied with your\nfirst try at the director-map either, so from time to time you may make\nchanges.  You might also add more map files to your geo-maps directory.\nAnytime those changes happen you will need to tell the geobackend to reread\nthem.  At the moment the best way to do this is:\n\n<textarea name=\"code\" class=\"xml\">\n# pdns_control rediscover\n\nFeb 26 16:10:57 nubian pdns[4661]: Rediscovery was requested\nFeb 26 16:10:57 nubian pdns[4661]: [geobackend] Parsing IP map zonefile\nFeb 26 16:10:58 nubian pdns[4661]: [geobackend] Finished parsing IP map zonefile: added 53072 prefixes, stored in 132525 nodes using 1590300 bytes of memory\nFeb 26 16:10:58 nubian pdns[4661]: [geobackend] Parsing director map \/usr\/local\/etc\/geo-maps\/irc.geo.blitzed.org\nFeb 26 16:10:58 nubian pdns[4661]: [geobackend] Parsing director map \/usr\/local\/etc\/geo-maps\/irc.strugglers.net\nFeb 26 16:10:58 nubian pdns[4661]: [geobackend] Finished parsing 2 director map files, 0 failures\n<\/textarea>\n\nAbout recursive nameservers\n===========================\n\nThere is a small but potentially confusing gotcha in all this regarding\nrecursive nameservers.\n\nNormally the authoritative nameservers for your regular domain will not allow\nrecursion, that is, they will return data only for the domains they are\nauthoritative for, returning pointers to nameservers for everything else.\n\nHere's an example of an authoritative server for blitzed.org that does not\nallow recursion:\n\n<textarea name=\"code\" class=\"xml\">\n$ dig www.bbc.co.uk @sou.nameserver.net\n\n; <<>> DiG 9.2.3 <<>> www.bbc.co.uk @sou.nameserver.net\n;; global options:  printcmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38059\n;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;www.bbc.co.uk.                 IN      A\n\n;; AUTHORITY SECTION:\nuk.                     166680  IN      NS      NS1.NIC.uk.\nuk.                     166680  IN      NS      NS2.NIC.uk.\nuk.                     166680  IN      NS      NS3.NIC.uk.\nuk.                     166680  IN      NS      NS4.NIC.uk.\nuk.                     166680  IN      NS      NS5.NIC.uk.\nuk.                     166680  IN      NS      NSA.NIC.uk.\nuk.                     166680  IN      NS      NSB.NIC.uk.\n\n;; Query time: 56 msec\n;; SERVER: 194.196.163.7#53(sou.nameserver.net)\n;; WHEN: Mon Feb 23 02:22:16 2004\n;; MSG SIZE  rcvd: 161\n<\/textarea>\n\nNote in the flags part the \"rd\", which means \"recursion desired\".  Since this\nserver does not offer recursion to me, all it does is pass back the hostname of\nthe nameservers that can further answer my question (in this case the list of\nnic.uk servers).  My own resolver would then carry on asking questions, which\nis how it should be.\n\nLook what happens if I pick a server that does allow recursion:\n\n<textarea name=\"code\" class=\"xml\">\n$ dig www.bbc.co.uk @bos.nameserver.net\n\n; <<>> DiG 9.2.3 <<>> www.bbc.co.uk @bos.nameserver.net\n;; global options:  printcmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51313\n;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2\n\n;; QUESTION SECTION:\n;www.bbc.co.uk.                 IN      A\n\n;; ANSWER SECTION:\nwww.bbc.co.uk.          899     IN      CNAME   www.bbc.net.uk.\nwww.bbc.net.uk.         300     IN      A       212.58.240.121\n\n;; AUTHORITY SECTION:\nbbc.net.uk.             148544  IN      NS      ns0.thny.bbc.co.uk.\nbbc.net.uk.             148544  IN      NS      ns0.thdo.bbc.co.uk.\n\n;; ADDITIONAL SECTION:\nns0.thny.bbc.co.uk.     62144   IN      A       38.160.150.20\nns0.thdo.bbc.co.uk.     62144   IN      A       212.58.224.20\n\n;; Query time: 321 msec\n;; SERVER: 203.20.52.5#53(bos.nameserver.net)\n;; WHEN: Mon Feb 23 02:27:14 2004\n;; MSG SIZE  rcvd: 164\n<\/textarea>\n\nNote the extra flag that appeared, \"ra\".  This is \"recursion available\", and\nthe server true to its word has gone and got the information for us.\n\nNormally this probably would not be noticeable.  In most cases it does not\nmatter if your own resolver does the work or if some other server does.  This\ngeo-dns project is based totally on the IP address of the server that asks the\nquestion, however, so for this application it is critical.\n\nAs far as geo-dns is concerned, you cannot have any nameserver that allows\nrecursion be authoritative for your main domain.  If you do, then any query\nwhich hits this server will cause it to go out and get the answer itself.  It\nwill hand back answers that are based on its own location, instead of the\nlocation of the client.  After wondering why too many people were getting\nanswers based on the location of bos.nameserver.net instead of their own\nlocation, we finally worked out it had recursion enabled.  This note is to save\nyou the same hassle.\n\nIt is generally recommended anyway that nameservers which are meant to be\nauthoritative for domains do not have recursion enabled\n(http:\/\/www.isc.org\/pubs\/tn\/isc-tn-2002-2.txt), but in this case it is an\nabsolute requirement if you wish to get any sensible results.  Check they are\nnot allowing recursion by use of dig as above before setting up this backend.\n\n(The specific example of bos.nameserver.net has since been fixed (had recursion\ndisabled) so you will not be able to repeat this example)\n\nHosting multiple domains\n========================\n\nYou may have noticed that all of the instructions so far have talked only of\nthe single example domain, geo.blitzed.org, and may be wondering how to serve\nmultiple zones.  The answer is, you don't need to.  The only thing you want to\nserve is individual RRs, and this geobackend does allow you to serve multiple\nof these just by adding files to the geo-maps directory.\n\nSo, assume you now want to apply geo-dns to the RR irc.strugglers.net,  You might\nadd a new director map to your geo-maps directory named \"irc.strugglers.net\"\n(name doesn't matter, just an example).  Inside this file you would have\nsomething like:\n\n        $RECORD irc.strugglers.net\n        $ORIGIN iso.strugglers.net.\n        0 bar.example.com.\n        # List of code->RR maps follow, unqualified RRs are inside\n        # iso.strugglers.net\n\nOnce you now do a \"pdns_control rediscover\", your geobackend will be configured\nto answer for irc.strugglers.net.geo.blitzed.org.  Now the people who run\nstrugglers.net's dns just need to add a handy CNAME in their example.com zone\nfile:\n\nirc     CNAME   irc.strugglers.net.geo.blitzed.org.\n\nYou can check it will work before they add the CNAME:\n\n<textarea name=\"code\" class=\"xml\">\n\n        $ dig +norecurse irc.strugglers.net.geo.blitzed.org. @ns0.blitzed.org\n\n        ; <<>> DiG 9.2.3 <<>> +norecurse irc.strugglers.net.geo.blitzed.org. @ns0.blitzed.org\n        ;; global options:  printcmd\n        ;; Got answer:\n        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3592\n        ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0\n\n        ;; QUESTION SECTION:\n        ;irc.strugglers.net.geo.blitzed.org. IN A\n\n        ;; ANSWER SECTION:\n        irc.strugglers.net.geo.blitzed.org. 3600 IN CNAME eu.iso.blitzed.org.\n\n        ;; Query time: 234 msec\n        ;; SERVER: 82.195.234.5#53(ns0.blitzed.org)\n        ;; WHEN: Thu Feb 26 15:45:36 2004\n        ;; MSG SIZE  rcvd: 73\n\n<\/textarea>\nso that is how you can geo-dnsify RRs in multiple zones.\n\nOther questions, corrections, etc.?\n===================================\n\nPlease subscribe to our \"geo\" list from http:\/\/lists.blitzed.org\/listinfo\/geo\nand tell us about it.  Tell us about how you use this stuff too, we're\ninterested in people's experiences.\n\nAll this is too much for you?\n=============================\n\nWe're still beta-testing this ourselves.  As long as it doesn't place too much\nload on our servers we are open to the idea of doing the PowerDNS part of this\nfor you as well.  We're not ready to do that yet; it will require more\ndevelopment and specification of how you would provide your own director-maps\netc..  If you are interested then please subscribe to the geo list and help us\nwork out the details.\n\nFAQ\n===\n\nQ1. My IRC network is based mostly in one country (e.g. Australia, Brazil, ...)\n    so all my users are from one ISO code and this isn't so useful to me, what\n    can I do?\n\nA1. Well, one of the assumptions made during the design of this backend is that\n    latency and geographical distance doesn't have a good relationship at small\n    scales, even within North America or Europe it probably does not *always*\n    follow that short distance == low latency.\n\n    To improve things further I think you will need to do actual measurements.\n    Or you could look at the amount of hops in the AS path from your client to\n    each of your servers.  Maybe you can come up with more ideas, if so we'd\n    like to hear.\n\n    However, if you are able to get more detailed geographic info from\n    somewhere then you could still feed it into this backend, you'd just have\n    to give up on the ISO country code model.  I can really only see this\n    working for very big countries like Australia and North America.\n\n    Remember also that your servers probably are not 100% reliable!  Say you\n    have 2 US servers; one in California and one in New York.  You find some\n    way to split the US up into two halves with one half going to California\n    and one to New York.  Now suppose the New York server dies.  Half your US\n    users are still being directed there because that's the nearest one!  Worse\n    still, those users probably think that what they are connecting to is a\n    *random* server, yet every single time they get will directed to a dead\n    server.  They may conclude your entire network is dead.\n\n    You would be better advised IMHO to just have one US pool with both servers\n    in.  If either dies, the irc clients will make a few more attempts and get\n    the other.  It might add a few more ms to the RTT, but it's better than not\n    being able to get on at all, and it's better than ending up on a non-US\n    server.  Maybe one day we'll do a high-availability backend too, though. :)\n\n\nQ2. Why is this tied to IRC?  Can I use it for other things?\n\nA2. Yes!  The code itself is not restricted in usefulness to only IRC, it's\n    just that IRC is a good example of a situation where you have a service\n    that is commonly split across many widely-separated servers, lots of widely\n    spread clients, and a serious lack of money for \"real\" solutions.\n\n    It wouldn't be any harder to use it for things like HTTP or many other\n    protocols.\n\n\nQ3. I don't want to run PowerDNS, will you make a custom backend for BIND9?\n\nA3. Probably not unless you're willing to pay or induce us in other ways!\n    PowerDNS is fun, you should try it, maybe you can make it work with only\n    one IP address by use of a forward zone in BIND and putting PowerDNS on a\n    strange port.\n\n\nQ4. I have some ideas for other metrics you could use instead of origin\n    country, like server load or user count, or ... will you implement that\n    too?\n\nA4: In another backend maybe.  Tell us about your ideas, if you can make them\n    sound interesting and useful then maybe we will.\n\nQ5. I serve lots of RRs out of my geobackend and with lots of nameservers I\n    find it hard to keep my geo-maps in sync between them all.  Any hints?\n\nA5. At the moment we use rsync like this:\n\n<textarea name=\"code\" class=\"xml\">\n    07 04 * * 0     pdns    rsync -t rsync:\/\/calzone.hestdesign.com\/countries\/zz.countries.nerd.dk.rbldnsd \/usr\/local\/etc\/powerdns\/zz.countries.nerd.dk.rbldn\nsd && \/usr\/local\/bin\/pdns_control rediscover > \/dev\/null\n    *\/15 * * * *    pdns    NR=$(rsync -rt --delete --stats rsync:\/\/rsync.blitzed.org\/geo\/ \/usr\/local\/etc\/powerdns\/directormaps | awk '\/Number of files trans\nferred\/ { print $5 }'); [ $NR != \"0\" ] && \/usr\/local\/bin\/pdns_control rediscover > \/dev\/null\n\n<\/textarea>\n    Which will take care of getting a new nerd.dk zone weekly and will sync the\n    geo-maps every 15 minutes, doing a rediscover if files were transferred.\n\nContact\n=======\n\nAuthor: Andy Smith <grifferz@blitzed.org> but please direct any questions to\nthe geo list thanks!\n\nhttp:\/\/lists.blitzed.org\/listinfo\/geo\n\n<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>PowerDNS geobackend setup notes =============================== These are the steps I went through to set up geobackend for PowerDNS on FreeBSD -STABLE. By the time you read this maybe geobackend is part of the PowerDNS main CVS so perhaps not much of this will apply. In that case you should skip further down to the configuration [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/blog.trungson.com\/index.php?rest_route=\/wp\/v2\/posts\/103"}],"collection":[{"href":"http:\/\/blog.trungson.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.trungson.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.trungson.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.trungson.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=103"}],"version-history":[{"count":0,"href":"http:\/\/blog.trungson.com\/index.php?rest_route=\/wp\/v2\/posts\/103\/revisions"}],"wp:attachment":[{"href":"http:\/\/blog.trungson.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.trungson.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=103"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.trungson.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}