Geoipdns
From PuB
GeoIPdns is an authoritative dns server software written on top of djbdns which improves request processing speed and enhances the IP geolocation support tinydns already has.
GeoIPdns is written for and supported by Server4Sale, being successfully used together with Deadsnail in Server4Sale blockdos network. The blockdos geoipdns installation, called Veridns, adds new features like dnsbl and asn peering based rules support
Updates
The current geoipdns version is 1.0r8. This version has been running on VeriDNS servers for more than a month without any problems. It just works out of the box.
The TODO list got smaller but I am already working to provide better round-robin support for multihomed names and also for including true OSPF support based on ASN peerings and ... rbl filters for crazy people.
License
This work is under whatever license terms djbdns is... i think it's just "public" so you can use it the same way you do with a public free-of-charge toilet. it's freakin' messy but it does its job!
Warning
This software is written on top of djbdns package specifically for tinydns and tinydns-data programs. That is, geoipdns is authoritative-only dns service.
Although the author is using geoipdns on production servers (50k zones with 5 to 10 requests per second) without any problems for months (no crashes, no restarts, etc), there is no guarantee that is will work this way for you. You are on your own.
Lastly, on Linux you will need a kernel version of at least 2.6.16 for this software to work. BSD systems should work without limitations starting with the first version that has kqueue support and VNODE events support.
This software was tested on:
- debian linux, 32/64bit platforms running 2.6.24-etchnhalf.1 linux kernel and inotify-tools version 3.3.2, libc version 2.3.6 (inotify interface was introduced with libc 2.4, although incomplete)
- freebsd 7.0, 32/64 bit platforms - clean and simple, no what-ifs
Why is not geoipdns released anymore as a djbdns patch?
Because the changes are way too big and i simply can't consider it as a djbdns patch anymore. Plus i introduced some incompatibilities with djbdns original code with respects to data formats (loc records changed, new records appeared). I am forced to fork.
GeoIpDNS described as a djbdns/tinydns patch
If you are seeing GeoIpDNS as a djbdns patch then you may understand things easier:
This patch contains code for speeding up request processing and for enhancing the IP location support that is already present in tinydns.
Request processing happens faster now because data.cdb is kept in memory and is reloaded only when needed. Basically, when processing a new request, instead of per-request open/read/close database operation as it was before, now we have a per-request read database operation. The system will be queried for events to see if data.cdb has changed lately. The data will be reloaded again only when there are events from the filesystem. Any update on data.cdb is seen immediately and the database is remapped into memory. The query-for-events operation is done before each request is processed. Multiple changed-events are read as a single event because the events of the same type are merged into a single one. The event reads are guaranteed by the system and geoipdns implementations to be non-blocking, wheter there are pending events or not. In the worst case reading a pending event will translate into a single close_cdb/open_cdb operation. The event management is done with kqueue on BSD systems and inotify on Linux. Again, you will need a kernel version greater than 2.6.13 for this patch to work on Linux.
Also, you now have a chance to replace the CDB hash function with superfast hash by using the compile-time flag -DUSE_SFHASH. (described below) This will give you some more performance improvements: less hashtable collisions, smaller hashtable distances.
By using USE_LOCMAPS flag one can enable geoipdb support. You can redirect your website's visitors to the nearest server directly from DNS before any HTTP request processing, you can blacklist a country or an ISP among other things. The tinydns LOC records definition are extended to support names instead of 2 character codes for identification. In fact, as you will see below, a LOC record will be looked up in the process by a 3 string identifiers tuple (username,mapname,location). The record lookup with USE_LOCMAPS enabled does not involve string operations. The string identifiers are translated into (hopefully) unique hash numbers using the same superfast hash when the data.cdb is built.
Compile-time Flags
USE_SFHASH
If defined at compile time, USE_SFHASH will use a superfast hash implementation instead of cdbhash while working with cdb database. superfast hash is faster, produces less collisions and gives smaller distances in the hash table.
Here are some stats comparing the performance of cdbhash against sfhash:
cdbhash:
- number of records: 310391
- key min/avg/max length: 8/21/78
- val min/avg/max length: 2/38/202
- hash tables/entries/collisions: 256/620782/229865
- hash table min/avg/max length: 2082/2425/2842
- hash table distances:
- d0: 80526 25%
- d1: 40543 13%
- d2: 39038 12%
- d3: 38963 12%
- d4: 38627 12%
- d5: 13787 4%
- d6: 8423 2%
- d7: 7491 2%
- d8: 6897 2%
- d9: 6772 2%
- >9: 29324 9%
sfhash:
- number of records: 310391
- key min/avg/max length: 8/21/78
- val min/avg/max length: 2/38/202
- hash tables/entries/collisions: 256/620782/229648
- hash table min/avg/max length: 2084/2425/2920
- hash table distances:
- d0: 80743 26%
- d1: 40509 13%
- d2: 39108 12%
- d3: 39001 12%
- d4: 38871 12%
- d5: 13825 4%
- d6: 8562 2%
- d7: 7507 2%
- d8: 6871 2%
- d9: 6734 2%
- >9: 28660 9%
USE_TOUCH_RELOADS
If defined at compile time, USE_TOUCH_RELOADS will give the admin a chance to force reloading data.cdb into memory only by touching data.cdb, without rebuilding the data feeds or restarting the server. This could be useful when data.cdb is kept mmapped as long as there is no change-event generated from the filesystem and the sysadmin needs for some weird non-provable reason to force reloading data.cdb from the filesystem.
USE_LOCMAPS
USE_LOCMAPS enables IP CDB lookups. Unless defined at compile time, there will be no client IP lookup done for a request and you will have no LOC and LOQ records support. In the original tinydns implementation, IP lookup was made for each request requiring 4 data.cdb queries. In geoipdns implementation, unless enabled at compile time, the ip lookups are disabled. If enabled at runtime, geoipdb ip lookups will be done only for the records that are geoip-aware - that is, only for the records configured with a LOQ record.
if before with tinydns you had the following format for LOC records:
%CC:192.168.25
and the LOC-enabled record was something like:
+loc.examaple.com:1.2.3.4:3600::CC
now the format is:
%usa-customers:1.14.0.0:16:optional-loc-lookup-info:optional-loc-lookup-info
and the LOC-enabled record is:
+loc.example.com:1.2.3.4:3600::usa-customers:optional-LOC-lookup-map-info:optional-LOC-lookup-map-info
or just
+loc.example.com:1.2.3.4:3600::usa-customers
HAVE_MMAP_READAHEAD
On Linux, if you have a kernel newer than 2.5.46 you can use this flag to populate the page tables for a file mapping by doing read-ahead. Since on linux you are forced to upgrade your kernel to 2.6.16 or newer for using this software, you will have readahead support for your mmap implementation. Debian, Ubuntu and Gentoo users should have no problems with doing this upgrade. For fans of other linux distros - i don't know.
geoip Databases Support
The geoip database is hosted together with all your standard records in the same data.cdb file. Because the CDB record format is (key,val) and doesn't have support for external (user specified) key compare functions, IP classes can't be used as keys. A %loc record is deaggregated in IPv4 CIDR IP/netmask format and the IP lookup can take as much as 32 CDB lookups. (constant time)
The deaggregation algorithm does its best to compress the IP classes into a small number of IPv4 CIDR IP/netmask classes. However, it depends heavily on what the IPv4 inputs look like. The MaxMind database, for example, gives you some big IPv4 CIDR numbers because of poorly formed IPv4 classes. The deaggregation algorithm is subject to change soon as well, but this won't affect functionality.
Many Users, Many Maps
I'm going to introduce the multi-terms. Because I have to manage DNS installs where there are many users managing their own zones, I need an easy way to identify their zones and their geoip location maps. tinydns becomes somewhat of a multi-user environment, at least for the system administrator.
I keep the user zones, one per file, in a user directory usually located in a DNS data directory.Besides the zone files the user has, the user directory also host an xml file in which geoip maps are defined.
Because one geoip location map per user can be a limitation, we're going to accept multiple geolocation maps per user. We are going to assign map names for each user's geoip location map. You are encouraged to see what a geolocation XML config file looks like below, in the management scripts and usage sections.
However, if you are not interested in multi- functionality - and you probably aren't, you may just ignore usernames and map names when building the xml configuration file. This will effectively make things work in single-user mode. See below.
LOQ record types
Note: LOQ records are now internally managed by geoipdns - that is, their existence is not made public to the user and the user has no business in managing LOQ records directly. Unless you are interested to understand how things are working you may safely skip this section.
If you enabled geoip location support at compile time with -DUSE_LOCMAPS=1 then you are able to specify geoip-aware records. For the sake of not searching possible geoip-aware records to match each request, geoipdns is using an internal record, the-LOQ that will be looked up to find if the record (qtype,fqdn) requested in the query is geoip-aware. When building data.cdb, if vdnsdb sees a geoip default entry for a record (defined by nomatch target) then it will transparently add a LOQ record for the (qtype,fqdn) that is being worked on.
suppose you add this geoip-aware record:
+www1.locz.mud.ro:12.12.12.12:300::usa-datacenter +www1.locz.mud.ro:23.23.23.23.:300::eu-datacenter +www1.locz.mud.ro:1.2.3.4:300::nomatch
when vdnsdb parses the nomatch target it will automatically create the internal record
?\000\001www1.locz.mud.ro:0:0
where in fact www1.locz.mud.ro will be in label-len dns packet format. \000\001 stands for this is an IN A record and the '0:0' are username hash and map name hash which are missing in our setup so the hash ids will be zero.
so when a request comes in geoipdns checks first if the record defined by (query_type,fqdn) in the request has geoip-aware records by looking up the LOQ record. if there is no LOQ record then it will proceed serving the client with no geoip lookups for the client's ip. If the record is geoip-aware it will start looking for an entry that matches the tuple (clientip,map_name,user_name) if map name and user name is defined or only (clientip) if you have a no-multi-user no-multi-map database.
'What you should keep from this story is that geoipdns is using the nomatch target for deciding if a record is or is not geoip-aware. So you should always have the nomatch target defined for a record if you want that record to be registered as geoip-aware!
While this approach adds some complexity, you shouldn't be aware of it. Plus, it adds speed at runtime and again, take it like: what I just saw isn't really there. forget about it ;)
Note: The "Q" from "LOQ" stands for "Q"uery - query if this record has geoip locations enabled.
LOC record types
The same as LOQ records, the LOC records are to be used and may be defined if you compile your tinydns with USE_LOCMAPS flag. A LOC record looks like:
%europe:1.2.3.0:24:nearest-server:johndoe
Normally you will have multiple europe LOC records inside the map nearest-server for user johndoe. The map named nearest-server will also contain entries for usa, asia, africa and so on defining where possible clients will be located for serving a dns record. Although you can define them by hand I advise on using the management script described below.
At runtime a LOC record says that if I find that this client's IP taken together with mapname and username that were found in the LOQ record for this (query_type,fqdn) will geomap to europe then I will reply with the requested record defined for the tuple (europe,mapname,username). see the flow of the request in the next section.
Flow of a DNS request with USE_LOCMAPS Enabled
When USE_LOCMAPS is not defined at runtime, the flow described here is totally gone, out of request flow picture.
You can see the flow by looking at tdlookup.c/respond()
- Request arrives
- Check if geoip location maps are enabled for the (fqdn,record_type) requested in the query by searching for a LOQ record
- If no LOQ record is found: do the lookup for a non-geoip-aware record
- If a LOQ record is found:
- read the mapname and username hashes from LOQ record
- build the geoip location query using: the client IP, the mapname hash and the username hash
- search for the LOC hash matching (ip,maphash,userhash). (this search will always return at least the nomatch record in case the client's ip doesn't match any predefined target)
- geoipdns searches for the record taking into consideration the hash of LOC name found
- geoipdns returns the result if there is one including any non-geoip-aware entries found for the record
what happens when vdnsdb finds geoip-aware records in its input
- geoip-aware record is found
- build hash for the LOC name
- add the record with the LOC hash built before
- if the LOC is nomatch then add LOQ for the respective (record_type,fqdn) - see next why we add the LOQ record only when reading nomatch targets
The Default (nomatch) geoip Location Record
If you want to make a record geoip-aware then you have to define a nomatch target for it. If you don't do this the record will not be created with a LOQ entry and even if you define your targets for it those will not be looked up properly.
The nomatch target is looked up by geoipdns when the client's ip does not match the real targets you defined. So if you have targets europe and usa and the client is from africa (but you have no target africa defined) the user will be served with the default nomatch entry.
Your nomatch (default) target should be named exactly like that: nomatch. Thats because the default LOC hash that will be searched in the database is the hash for the nomatch string. If you want to change it you have to redefine the default hash by rebuilding it with superfast hash function (see cdb.h:NOMATCH_HASH #define macro).
Very important: MAKE SURE YOU ARE COMPILING WITH -DUSE_SFHASH WHEN HAVING USE_LOCMAPS ENABLED! OTHERWISE NOTHING WILL WORK. USE_SFHASH is enabled by default. You want to leave it like that.
Why are you forced to create nomatch targets? I have two reasons:
- The biggest reason: it keeps me away from adding multiple LOQ entries for a geoip-aware record. At the time LOQ entries are added for a record i have no chance of searching if i don't have a LOQ entry already added for that record. If I want to do that i would have to keep track of each record separately while building data.cdb. As a rule (although i cannot force it): don't add multiple nomatch targets. The data.cdb size will increase with few bytes for each but thats the only bug and we can live with it for now.
- The second biggest reason: You are advised to be a bastard operator from hell when managing something like a dns-auth service, but don't be too much! I know you want to blacklist everything that doesn't match your targets but don't do this by not adding a nomatch target. If your dns server is authoritative for that fqdn then you should serve something. I'm doing blacklists in nomatch target by serving 127.0.0.1. You can also do a blacklist for a predefined target by not creating any records for that target. The clients that get classified with the respective target will get no response if there's no record for it.
Make sure you understand the nomatch targets. Together with the LOQ records it builds the heart and the brain of geoipdns ;)
Setting up LOC-based Records (geoip-aware records)
Note: you can read this section even if you're going to use the management scripts. It will help you understand things
If you don't want to use the management scripts below, you can create geoip-aware records by hand like this:
setup the geolocation maps
the format of LOC record is:
%target:ipnet:bitnetmask:mapname:username
in a single-user environemnt the username isn't used, so the record format can also be:
%target:ipnet:bitnetmask:mapname
Mapnames are used to identify different maps. You may have a map that creates targets for Romania and Hungary and you will use that map for some records. For other records, you may need to create one single target for Tanzania. You do this by creating a new map with a target "tanzania" which will hold all Tanzania IPs. Unless you know for sure that you will use one single map for life, I advise you to use map names. If you are sure you can ignore them, the LOC record may look like:
%target:ipstart:bitnetmask
Let's use a single-user setup with multiple map names. The LOC records will look like (for example, some snippets):
%gate2:74.86.99.145:30:forpub: %gate1:75.126.154.121:30:forpub: %romania:217.156.0.0:16:forpub: %romania:217.115.208.0:32:forpub: %romania:217.73.160.0:20:forpub: %north-america:217.116.248.96:29:forpub: %north-america:217.116.231.64:28:forpub: %north-america:217.116.226.224:28:forpub: %allow:79.115.30.31:32:private: %ro-server:195.254.152.0:23:nearhome: %ro-server:195.254.140.0:23:nearhome: %ro-server:195.254.132.0:22:nearhome: %us-server:209.197.236.144:29:nearhome: %us-server:209.197.227.0:24:nearhome: %us-server:209.197.225.192:27:nearhome:
Above I defined 3 maps:
- nearhome - for serving content from the nearest server which has the targets:
- ro-server - will serve romanian clients from the server located in romania
- us-server - will serve usa clients from the server located in north-america
- forpub - for serving some weird public content, some go blackhole, some go bananas - has the targets:
- gate1 - this is a range of ips from north-america target redefined as gate2 - i suspect something weird so i have a special rule - they will go the server where i host only legal content ;)
- gate2 - this is very suspicious. i would rather blacklist them forever being a real b.o.f.h. i will not create any record for gate2 so they will get no answer back from me. gate1 and gate2 are very easy to manage as exceptions from defined maps by using the management scripts
- romania - romanian clients will be served from the server hosting romanian pages
- north-america - north-american clients will be served from the server hosting english pages
- private - site that allows only one ip (mine) to access. the rest will be looped back to localhost in the nomatch target - has the targets:
- allow - allow only my ip
add the records based on the targets defined above
#private map records +private.mud.ro:24.23.22.21:300::allow:private +private.mud.ro:127.0.0.1:300::nomatch:private #forpub map records +pub.mud.ro:1.2.2.1:300::north-america:forpub +pub.mud.ro:1.4.4.1:300::romania:forpub +pub.mud.ro:127.0.0.13:300::gate1:forpub #no entry for gate2, they will get no answer back from this dns server +pub.mud.ro:32.32.32.32:300::nomatch:forpub #nearhome map records .... ....
I hope you got the idea. Altough i gave examples only for IN A records you will be doing the same for any record type: NS,SOA,MX,TXT,CNAME (you sure you know what CNAME means??),PTR,SRV,TXT,etc. Now:
Build your data.cdb file
Installation Procedure
- If you are using Linux, make sure you have inotify support in your kernel and libc. You may need to download the inotify userspace libraries as well if you don't already have them. (necessary under Debian - package name: inotify-tools). You need a kernel version of at least 2.6.16 and libc 2.4 or inotify-tools package, version 3.3.2
- Download geoipdns source package from here: http://pub.mud.ro/~cia/files/vdns-src.tgz
- Modify your conf-home to reflect install path
- Run make and make setup check. If you need to do touch-reloads, make it with LOCAL_CFLAGS="-DUSE_TOUCH_RELOADS=1". if you need to see debug output, add -DDEBUG_MODE=1 to LOCAL_CFLAGS.
- A successfull instalation will give you two binaries, vdnsd and vdnsdb in $conf-home/bin. You can setup vdnsd for running the same as tinydns (use a run script in your dns-auth service directory). vdnsdb on the other hand should be called with cat inputfiles | vdnsdb data.tmp data.cdb or with a feed similar to cat (vdnsdb data.tmp data.cdb < datafeed) altough old style is supported as well (if no arguments are given for data temp and cdb name it will lookup a data file in the current directory and build there data.cdb)
Management Scripts
The management scripts (well, its just one for now, to be honest) gives you a lot of power while managing dns LOC records and maxmind database updates.
Download
You can download the management scripts archive from here
Installation
untargz the archive. check that you have the following perl modules installed on your system. If you dont, get them from CPAN:
- Data::Dumper
- File::Basename
- IO::Uncompress::Unzip
- LWP::Simple
- Number::Interval
- Storable;
- Text::CSV_XS
- Tie::Handle::CSV
- XML::Simple
an easy way to check if you have them is by running:
perl -i -e '
foreach ((qw(Data::Dumper File::Basename IO::Uncompress::Unzip LWP::Simple Number::Interval Storable Text::CSV_XS Tie::Handle::CSV XML::Simple)))
{ eval "use $_;"; if ($@) { print "$_ 404_NOTFOUND\n"; } else { print "$_ 200_OK\n";} }'
if an outputline contains Module::Name 404_NOTFOUND that means you have to install that module. when everything it's in its place you will get:
Data::Dumper 200_OK File::Basename 200_OK IO::Uncompress::Unzip 200_OK LWP::Simple 200_OK Number::Interval 200_OK Storable 200_OK Text::CSV_XS 200_OK Tie::Handle::CSV 200_OK XML::Simple 200_OK
Next step: edit veridns/cfg.pm. Ignore the garbage, set $cf_wdir to the path were data will be dumped. Set $cf_geoip_dumpdir to a temp folder path where storables, archives and such will be kept.
using ipdb_update.pl script
With ipdb_update.pl you can keep an up-to-date copy of maxmind geoip database.
- run perl ipdb_update.pl chkupdate=1
you will get some output like this:
parse chkupdate=1 checking for updates ipdb: mirroring done rebuilding master db REBUILD_MASTER: __start ipdb::save store_to=/var/service/vdns/tmp/ipmaps.sto REBUILD_MASTER: __end
now you have a local copy of geoip maxmind database as a perl storable dump. next time when you will run the script if there are no updates you will get in the output:
parse chkupdate=1 checking for updates ipdb: resource not modified, mirroring skipped
You may want to install a cronjob to run monthly and download updates. If you install it to run on 3rd day of each month i guess you will be fine with updates ( they usually happen at the end of each month).
configuring your LOC records with xml
With ipdb_update.pl you can generate your LOC records (there may be tons of them) with a simple XML configuration file. The XML tags are:
- ipmaps - the root tag, accepts an attribute "out" which tells the script to what file LOC records should be written. ipmaps may have as children map tags. ipmaps may also have one more attribute, the username in case there is a dns multi-user environment.
- map - a map will contain targets: the mapit tags and exceptions: the exceptions/except tags. it may have an attribute mname which defines the map name
- mapit has 2 attributes, from and to
- from says what to map: from may be a comma delimited list of country codes or a comma delimited list of ipv4 CIDR classes or a list of both
- to says where to map: to becomes the LOC record name
- exceptions/except - i love them. with exceptions i can re-map ip classes from mapit. its a very handy shortcut. if i have a map for USA ips and i need to blacklist a /24 class from USA maps then i use an exception. That will remove my /24 class from USA map and add the new rule for it as defined by my exception. the from and to attributes have the same meaning as for mapit tag.
<ipmaps out="map2-loc.data"> <map mname="forpub"> <mapit from="US,CA" to="north-america" /> <mapit from="RO" to="romania" /> <exceptions> <except from="75.126.134.18/32" to="gate1" /> <except from="75.126.154.120/30" to="gate1" /> <except from="75.126.241.171/32" to="gate2" /> <except from="74.86.99.144/30" to="gate2" /> </exceptions> </map> <map mname="private"> <mapit from="79.115.30.31/32" to="allow" /> <!-- nomatch will serve 127.0.0.14 --> </map> <map mname="nearhome"> <mapit from="US,CA" to="us-server"/> <mapit from="RO" to="ro-server"/> <!-- in nomatch i will give some default server ip --> </map> </ipmaps>
a second example:
<ipmaps out="map1-loc.data"> <map > <mapit from="US,CA" to="north-america" /> <mapit from="RO" to="romania" /> <exceptions> <except from="75.126.134.18/32" to="gate1" /> <except from="75.126.154.120/30" to="gate1" /> <except from="75.126.241.171/32" to="gate2" /> <except from="74.86.99.144/30" to="gate2" /> </exceptions> </map> </ipmaps>
after you built your config.xml file (or maybe you built 10 of them) run the ipdb_update.pl script:
perl ipdb_update.pl configs=config.xml,config2.xml,config34.xml
This command will build your LOC records from your country-code rules, ipv4 cidr classes rules and exceptions and will save them in the file specified by ipmaps/out attribute. Voila!!
sample output from building LOC records based on xml config:
parse configs=map-sample1-single_user-many_maps.xml
compile map-sample1-single_user-many_maps.xml
out map2-loc.data
dumptoout ./map2-loc.data
map_country US to north-america
map_country CA to north-america
map_country RO to romania
check exception 75.126.134.18/32,gate1 against mapid forpub
chk_except_match: {75.126.133.168, 75.126.136.127}, {75.126.134.18, 75.126.134.18}
chk_except_match: new_tgt_left: 75.126.133.168, 75.126.134.17
chk_except_match: new_tgt_right: 75.126.134.19, 75.126.136.127
check exception 75.126.154.120/30,gate1 against mapid forpub
chk_except_match: {75.126.151.248, 75.126.158.111}, {75.126.154.121, 75.126.154.122}
chk_except_match: new_tgt_left: 75.126.151.248, 75.126.154.120
chk_except_match: new_tgt_right: 75.126.154.123, 75.126.158.111
check exception 75.126.241.171/32,gate2 against mapid forpub
chk_except_match: {75.126.239.152, 75.126.242.79}, {75.126.241.171, 75.126.241.171}
chk_except_match: new_tgt_left: 75.126.239.152, 75.126.241.170
chk_except_match: new_tgt_right: 75.126.241.172, 75.126.242.79
check exception 74.86.99.144/30,gate2 against mapid forpub
chk_except_match: {74.86.98.240, 74.86.101.127}, {74.86.99.145, 74.86.99.146}
chk_except_match: new_tgt_left: 74.86.98.240, 74.86.99.144
chk_except_match: new_tgt_right: 74.86.99.147, 74.86.101.127
map_ip 79.115.30.31/32 to allow
map_country US to us-server
map_country CA to us-server
map_country RO to ro-server
part of LOC data generated by the script:
%gate2:74.86.99.145:74.86.99.146:forpub: %gate1:75.126.154.121:75.126.154.122:forpub: %romania:217.156.0.0:217.156.127.255:forpub: ... ... %allow:79.115.30.31:79.115.30.31:private: %ro-server:217.156.0.0:217.156.127.255:nearhome: %ro-server:217.115.208.0:217.115.223.255:nearhome: %ro-server:217.73.160.0:217.73.175.255:nearhome: ... ... %us-server:4.79.65.192:4.79.244.223:nearhome: %us-server:4.43.114.16:4.79.65.159:nearhome: %us-server:4.42.209.240:4.43.114.7:nearhome: %us-server:4.37.2.0:4.42.209.231:nearhome:
GeoIpDNS Configuration Examples
samples of geoipdns usages, will be updated soon.
TODO list
planned for the next release: 1.0r9:
- add reliable round robin support. serving all the registered ips for a name does not guarantee anything on the other side (dns caches, resolvers, browsers). we need to serve the next ip at a time (think of reading circle queues elements one by one) for multihomed names with a very low ttl (60 seconds)
- add ospf support by using peering informations between ISPs
- MAYBE: make the core fully async for supporting rbl dns tests on client ip. return something bad to blacklisted client ips.
most of the above is done:
- PRI=VERY_HIGH keep the LOQ records internal to geoipdns only. The user shouldn't manage them directly but the LOQ records should be created for a (fqdn,type) when it is made geoip-aware - DONE in version 1.0r7
- PRI=HIGH don't force the user to specify UID=0,MAPID=0 if he doesn't need a multi-user environment - DONE in version 1.0r7
- PRI=HIGH use real names/tags (yes, strings) instead of 2chars codes to identify IP classes. - DONE in version 1.0r7
- PRI=VERY_HIGH add real support for NAPTR,SRV,AAAA records. Add ipv6 support for udp listener. -not planned yet
- PRI=HIGH make IPv4 CIDR ipclass deaggregation algorithm greedy - try to split the ip interval in as bigger classes as it is possible - DONE
- PRI=? add support for DNSBL- and ASN_peering- based rules/filters - DONE only for VeriDNS environments
- PRI=LOW add support for a fixed-length record database format useful for installs where live updates are happening often
- PRI=MEDIUM add more management scripts, eventually a GUI interface via http - if someone wants to do this you are more than welcome!
GeoIpDNS sponsors
This work is generously and constantly sponsored by Server4Sale. VeriDNS with Deadsnail are part of Server4Sale blockdos network.
Show your support
Please support this project by making a donation via PayPal. Your support will keep quality software open and freely available.
You can also help me and help you the same time by buying DNS hosting for your business within VeriDNS network or by getting protected by Server4Sale blockdos network. And you get to work with me directly ;)
Thank you
GeoIpDNS users
If you are using this patch then send me an email and I'll list you here as a happy (or not!) user. Your mail body will be included but don't abuse the space :). You may include details related to your business and your business logo.
- Anders Brownworth is using this patch to server geographically aware SRV records in conjunction with a VoIP service. He has (somewhat out of date) an article on setting up some VoIP stuff on his blog, mentioning this patch.
- Daniel Leonardo Albe says that he's using (or planning to use) this patch to prove how a CDN at ISP level works from inside
- dealnews.com is using GeoipDNS as a simple static ospf implementation at dns level
Related resources
- tinydns homepage
- tinydns resources:patches,additional informations,technical support providers
- superfast hash
Guarantees
I make no guarantees for any of my software or articles unless I specifically say so. (e.g. under the terms of a contract).
You can get screwed if you misuse this information. use at your own risk.
