IPMAP bug?
Anders
I am seeing a scope related issue looking up source IPs with GeoIP-
DNS. This seems to be a reproducible bug. Here is my test setup:
GeoIP-DNS patched tinydns is running on 10.1.50.92 and I have a "1" in
env/IPMAP. My data file looks like this:
.example.com:10.1.50.92:a:300
%AA:10.1.50.91:10.1.50.91
%BB:10.1.50.0:10.1.50.255
%CC:10.0.0.0:10.255.255.255
%ZZ:0.0.0.0:254.254.254.254
+www.example.com:11.22.33.44:::AA
+www.example.com:22.33.44.55:::BB
+www.example.com:33.44.55.66:::CC
+www.example.com:99.99.99.99:::ZZ
When requesting www.example.com from 10.1.50.91, I get 11.22.33.44 as
expected. (so a /32 address works fine) However, when requesting
www.example.com from 10.1.50.90, I would expect to get 22.33.44.55
(from the BB location record 10.1.50.0/24) but I get 33.44.55.66 from
the CC location record instead.
I defined IPDB_DEBUG in ipdb.c so I could see what was being tested
and I see this when requesting www.example.com from 10.1.50.90:
@4000000048ef9075087c7664 usekey 10.1.50.90/32/
@4000000048ef9075087d2244 usekey 10.5.246.122/31/
@4000000048ef9075087d262c usekey 10.5.246.120/30/
@4000000048ef9075087d262c usekey 10.5.246.120/29/
@4000000048ef9075087d2a14 usekey 10.5.246.112/28/
@4000000048ef9075087d2dfc usekey 10.5.246.96/27/
@4000000048ef9075087d2dfc usekey 10.5.246.64/26/
@4000000048ef9075087d31e4 usekey 10.5.246.0/25/
@4000000048ef9075087d35cc usekey 10.5.246.0/24/
@4000000048ef9075087d35cc usekey 10.5.246.0/23/
@4000000048ef9075087d39b4 usekey 10.5.244.0/22/
@4000000048ef9075087d3d9c usekey 10.5.240.0/21/
@4000000048ef9075087d550c usekey 10.5.240.0/20/
@4000000048ef9075087d7834 usekey 10.5.224.0/19/
@4000000048ef9075087d7c1c usekey 10.5.192.0/18/
@4000000048ef9075087d8004 usekey 10.5.128.0/17/
@4000000048ef9075087d83ec usekey 10.5.0.0/16/
@4000000048ef9075087d83ec usekey 10.4.0.0/15/
@4000000048ef9075087d87d4 usekey 10.4.0.0/14/
@4000000048ef9075087d8bbc usekey 10.0.0.0/13/
@4000000048ef9075087d8fa4 usekey 10.0.0.0/12/
@4000000048ef9075087db2cc usekey 10.0.0.0/11/
@4000000048ef9075087db2cc usekey 10.0.0.0/10/
@4000000048ef9075087db6b4 usekey 10.0.0.0/9/
@4000000048ef9075087dba9c usekey 10.0.0.0/8/
@4000000048ef9075087e6294 0a01325a:852d:7178 + 0001 www.example.com
It looks like the first test against 10.1.50.90/32 fails the way it
should but then it picks a strange IP (10.5.246.122) to continue
testing. I'm guessing there is a shift error somewhere. Because
10.5.246.122 is "past" 10.1.50.0, my IP is never caught in the scope
of the BB record and gets caught in the CC record instead.
Any help is much appreciated. Thanks.
-Anders
Anders
diff djbdns-1.05-geoip-orig/ipdb.c djbdns-1.05-geoip-anders/ipdb.c
65c65
< unsigned int j;
---
> unsigned int j = 0;
A variable used to hold the int value of the source IP used for
testing against ranges in the CDB just needed to be initialized.
-Anders
On Oct 10, 1:35 pm, Anders <ander...@gmail.com> wrote:
> Hi,
>
> I am seeing a scope related issue looking up source IPs with GeoIP-
> DNS. This seems to be a reproducible bug. Here is my test setup:
>
> GeoIP-DNS patched tinydns is running on 10.1.50.92 and I have a "1" in
> env/IPMAP. My data file looks like this:
>
> .example.com:10.1.50.92:a:300
>
> %AA:10.1.50.91:10.1.50.91
> %BB:10.1.50.0:10.1.50.255
> %CC:10.0.0.0:10.255.255.255
> %ZZ:0.0.0.0:254.254.254.254
>
> +www.example.com:11.22.33.44:::AA
> +www.example.com:22.33.44.55:::BB
> +www.example.com:33.44.55.66:::CC
> +www.example.com:99.99.99.99:::ZZ
>
> expected. (so a /32 address works fine) However, when requestingwww.example.comfrom 10.1.50.90, I would expect to get 22.33.44.55
> the CC location record instead.
>
> I defined IPDB_DEBUG in ipdb.c so I could see what was being tested
adrian ilarion ciobanu
the latest patch is:
http://pub.mud.ro/~cia/files/geoipdns-1.0r6.diff
whatever old patches one is using, it has bugs. you noted one but its
not the only :)
new thigs coming with this patch:
1. improved ipdb lookup support
2. performance improvements: the cdb is cached in memory. kevent/inotify
are used on freebsd/linux to notify tinydns about cdb updates. tinydns
works now half-sync/half-async and the open/read/close mechanism that
was in place for every request is gone.
3. multiple bug fixes, etc
2. new compile time flags: you can define the flags with
LOCAL_FLAGS="-DUSE_LOCMAPS=1 -DHAVE_MMAP_READAHEAD=1 -DUSE_SFHASH=1" make
HAVE_MMAP_READAHEAD - adds readahead for mmaped cdb on linux,
USE_SFHASH - use superfast hash instead of cdb hash. on more than 300k
records, it looks better. here are some stats:
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_LOCMAPS - enable ipdb lookup support. without it it will be faster
ok, now about the formats:
when you enable ipdb lookups, you have to doit PER RECORD and not PER ZONE.
there are 2 uints that are being used when doing record lookups: the UID
and the MAP_ID. uid identifies a user (i use the inode of the dns
subdirectory of a user). user may have multiple maps (in one map RO may
have a meaning, in other map may have diff) so we need the MAP_ID.
if you have one single map and one user, just write them :0:0
step 1:
enabling PER_RECORD lookups:
?RECORD_TYPE_OCTALrecord:MAP_ID:UID
for example:
?\000\001loq.mud.ro:1:683021
RECORD_TYPE_OCTAL is defined in dns.h, dns types. in my case im doing
the ipmap for loq.mud.ro A record which is owned by user with UID 683021
and it has map id 1.
step 2:
create map:
%RO:62.102.33.48:62.102.33.55:1:683021
%RO:62.182.16.0:62.182.23.255:1:683021
%RO:62.186.77.64:62.186.77.127:1:683021
%RO:62.186.102.224:62.186.102.255:1:683021
%RO:62.187.218.0:62.187.218.63:1:683021
so, foreach country map add :MAP_ID:UID, easy enough
step 3:
make your records:
+loq.mud.ro:1.2.3.4:3600::RO
+loq.mud.ro:4.3.2.1:3600::~~
if u enable iplookup for a record DONT FORGET TO CREATE A DEFAULT
RECORD. default records are written ~~ (last codes in ascii)
i have no idea when i will put up some real pages for this, i see people
get to be interested. anyway ill announce. ill try to keep up with mlist
in the meantime. apologize for not being too responsive.
so good luck :)
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "geoipdns-users" group.
> To post to this group, send email to geoipdn...@googlegroups.com
> To unsubscribe from this group, send email to geoipdns-user...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/geoipdns-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Anders Brownworth
guess the default record (~~) is new? That's great stuff. Failing back
to the wide scope (0.0.0.0:254.255.255.255) the way I was doing it was
very inefficient. I'll give the new code a try.
Ideally I end up writing a tutorial that demonstrates all of these
things in action. I'll let you know when I get that far.
-Anders
Sent from my iPhone
adrian ilarion ciobanu
> Thanks for these updates and the compile time flags mentioned later. I
> guess the default record (~~) is new?
nope, not new. it was never mentioned. it was written 'XX' but ~~ is
better from the point of view of my management scripts. but anyway, i
expect sysadmins to dig the sh!thole and smell it from inside out before
using it and not treat it as a blackbox ... and its great you and others
are doing it.
>That's great stuff. Failing back
> to the wide scope (0.0.0.0:254.255.255.255) the way I was doing it was
> very inefficient. I'll give the new code a try.
buah! :) see? blackboxes :) outside->inside fixes, the USA style