Issues on 64-bit?

[Brian Moon]

Do you know of any issues compiling and use geoipdns on 64-bit systems?
I see several warnings when compiling about mismatched signedness.

vdnsdb.c:337: warning: pointer targets in passing argument 2 of
'ip4_scan' differ in signedness
vdnsdb.c:340: warning: pointer targets in passing argument 2 of
'ip4_num' differ in signedness
vdnsdb.c:349: warning: pointer targets in passing argument 2 of
'cdb_make_add' differ in signedness
vdnsdb.c:362: warning: passing argument 2 of 'uint32_unpack_big' from
incompatible pointer type
vdnsdb.c:365: warning: passing argument 2 of 'uint32_unpack_big' from
incompatible pointer type
vdnsdb.c:368: warning: passing argument 2 of 'uint32_unpack_big' from
incompatible pointer type
vdnsdb.c:371: warning: passing argument 2 of 'uint32_unpack_big' from
incompatible pointer type
vdnsdb.c:374: warning: passing argument 2 of 'uint32_unpack_big' from
incompatible pointer type
vdnsdb.c:426: warning: pointer targets in passing argument 2 of
'ip4_scan' differ in signedness
vdnsdb.c:446: warning: pointer targets in passing argument 2 of
'ip4_scan' differ in signedness
vdnsdb.c:490: warning: pointer targets in passing argument 2 of
'ip4_scan' differ in signedness

I am worried that the defined hash for the NOMATCH_HASH is not lining up
right on a 64-bit system.

When we have:

# LOC Records
%brian:10.1.100.0:24
%private:10.1.0.0:16
# A Records
=dealnews.com:72.5.90.150:120::atl
=dealnews.com:74.217.192.150:120::sfo
=dealnews.com:72.5.90.150:120::private
=dealnews.com:72.5.90.150:120::nomatch
=dealnews.com:74.217.192.150:120::nomatch

DNS requests from 10.1.100.0:24 get no A record.

; <<>> DiG 9.6.0-APPLE-P2 <<>> dealnews.com @brianm.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27137
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;dealnews.com. IN A

;; AUTHORITY SECTION:
dealnews.com. 2560 IN SOA geodns1.dealnews.com.
hostmaster.dealnews.com. 1273555518 16384 2048 1048576 2560

;; Query time: 52 msec
;; SERVER: 10.1.2.102#53(10.1.2.102)
;; WHEN: Tue May 11 08:43:46 2010
;; MSG SIZE rcvd: 85

It as if nomatch simply does not work.




Brian.
--------
http://brian.moonspot.net/

--
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.

[Brian Moon]

More info. If there is no LOC record for an IP address, the nomatch is
used. But, if there is a LOC record and no matching A record, then we
get nothing.

For now we have altered our scripts to always include an A record for
anything we provide a LOC record for. But, this seems like a bug.

[adrian ilarion ciobanu]

nope, I think you are doing a mistake.

if you declare "brian" mapping then you have to use it.
the client comes in. it gets mapped as a "brian" client. but there's no RR for "brian" clients.
so he is served with an empty plate. it is not supposed to go to "nomatch" once he is a "brian" ;)


On Tue, May 11, 2010 at 08:49:09AM -0500, Brian Moon wrote:
> Return-Path: <geoipdns-users+bncCKfO...@googlegroups.com>
> X-Original-To: c...@mud.ro
> Delivered-To: c...@mud.ro
> Received: from r.fw.mail.twinbyte.com (smtp-gw2 [75.126.241.171])
> by destiny.no-mx.com (StinkFish) with ESMTP id 87FEE26187D
> for <c...@mud.ro>; Tue, 11 May 2010 10:43:31 -0500 (CDT)
> Received: from mail-gx0-f204.google.com (unknown [209.85.217.204])
> by r.fw.mail.twinbyte.com (StinkFish) with ESMTP id B6ECBB80A2
> for <c...@mud.ro>; Tue, 11 May 2010 10:51:05 -0500 (CDT)
> Received: by gxk28 with SMTP id 28sf3877453gxk.2
> for <c...@mud.ro>; Tue, 11 May 2010 08:07:40 -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=googlegroups.com; s=beta;
> h=domainkey-signature:received:x-beenthere:received:received:received
> :received:received:received-spf:received:received:received:received
> :message-id:date:from:user-agent:mime-version:to:subject
> :x-original-authentication-results:x-original-sender:reply-to
> :precedence:mailing-list:list-id:list-post:list-help:list-archive
> :sender:list-subscribe:list-unsubscribe:content-type;
> bh=+NfgbaUEK+wxsXZtqLdYVafwZUnjYg2FiE7Di3fCIwo=;
> b=S8l85KRTpcdJRtO07khV4CkYRulgndKVb3zaq8x/MenlpRIrPLwFc02L1rtbyXVDae
> Qs9o+5u5t5KPwuJXApRZwaHGrbZEQAj/QvwUqSBVuoS+nB2PmN/OGg/gTu/FwakxwMRF
> RuYk6PESlIYk0UMVg33R+8PabEcv42V2fQFCc=
> DomainKey-Signature: a=rsa-sha1; c=nofws;
> d=googlegroups.com; s=beta;
> h=x-beenthere:received-spf:message-id:date:from:user-agent
> :mime-version:to:subject:x-original-authentication-results
> :x-original-sender:reply-to:precedence:mailing-list:list-id
> :list-post:list-help:list-archive:sender:list-subscribe
> :list-unsubscribe:content-type;
> b=3WSHvvJdi3ohGE50I75s0PTpixNupBLOfEVN1PiMN/12abPx7I0lOyRksVBu3oY/NR
> fEIAi0d4NMifG38WoZ+v3jwc5niB+jEkok0U9DYq7seViD5VIBwPxwd+T8cv1XvXyM+J
> fiFMMNl27fBTXpSfF1aUMHu6GFh2IwpQXHO8c=
> Received: by 10.101.137.4 with SMTP id p4mr113354ann.68.1273590460310;
> Tue, 11 May 2010 08:07:40 -0700 (PDT)
> X-BeenThere: geoipdn...@googlegroups.com
> Received: by 10.101.177.32 with SMTP id e32ls2371148anp.5.p; Tue, 11 May 2010
> 08:07:40 -0700 (PDT)
> Received: by 10.151.16.35 with SMTP id t35mr7167120ybi.19.1273590459838;
> Tue, 11 May 2010 08:07:39 -0700 (PDT)
> Received: by 10.229.190.197 with SMTP id dj5mr666967qcb.12.1273585758815;
> Tue, 11 May 2010 06:49:18 -0700 (PDT)
> Received: by 10.229.190.197 with SMTP id dj5mr666953qcb.12.1273585752866;
> Tue, 11 May 2010 06:49:12 -0700 (PDT)
> Received: from smtp.dealnews.com (smtp.dealnews.com [72.5.90.27])
> by gmr-mx.google.com with ESMTP id 19si1216218qyk.9.2010.05.11.06.49.12;
> Tue, 11 May 2010 06:49:12 -0700 (PDT)
> Received-SPF: pass (google.com: domain of br...@moonspot.net designates 72.5.90.27 as permitted sender) client-ip=72.5.90.27;
> Received: (qmail 2738 invoked from network); 11 May 2010 13:49:03 -0000
> Received: from unknown (HELO mail.dealnews.com) (10.1.10.7)
> by -H with ESMTPS (DHE-RSA-AES256-SHA encrypted); 11 May 2010 13:49:03 -0000
> Received: (qmail 32587 invoked from network); 11 May 2010 13:49:10 -0000
> Received: from h105.248.18.98.static.ip.windstream.net (HELO macdough.local) (bri...@98.18.248.105)
> by -H with ESMTPA; 11 May 2010 13:49:10 -0000
> Message-ID: <4BE96...@moonspot.net>
> Date: Tue, 11 May 2010 08:49:09 -0500
> From: Brian Moon <br...@moonspot.net>
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
> MIME-Version: 1.0
> To: geoipdn...@googlegroups.com
> Subject: Issues on 64-bit?
> X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
> domain of br...@moonspot.net designates 72.5.90.27 as permitted sender)
> smtp.mail=br...@moonspot.net
> X-Original-Sender: brian...@gmail.com
> Reply-To: geoipdn...@googlegroups.com
> Precedence: list
> Mailing-list: list geoipdn...@googlegroups.com; contact
> geoipdns-u...@googlegroups.com
> List-ID: <geoipdns-users.googlegroups.com>
> List-Post: <http://groups.google.com/group/geoipdns-users/post?hl=en_US>,
> <mailto:geoipdn...@googlegroups.com>
> List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:geoipdns-...@googlegroups.com>
> List-Archive: <http://groups.google.com/group/geoipdns-users?hl=en_US>
> Sender: geoipdn...@googlegroups.com
> List-Subscribe: <http://groups.google.com/group/geoipdns-users/subscribe?hl=en_US>,
> <mailto:geoipdns-use...@googlegroups.com>
> List-Unsubscribe: <http://groups.google.com/group/geoipdns-users/subscribe?hl=en_US>,
> <mailto:geoipdns-user...@googlegroups.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> X-Spam-Status: No, score=1.2 required=7.5 tests=SPF_NEUTRAL shortcircuit=no
> autolearn=no version=3.2.5
> X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
> smtp-gw3.server4sale.net
> X-Spam-Level: *

--
adrian ilarion ciobanu
adri...@ciobanu.name
http://pub.mud.ro/~cia
+40 788 319 497

[Brian Moon]

Can you explain where in this flow we are falling through the cracks?

* 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:
o read the mapname and username hashes from LOQ record
o build the geoip location query using: the client IP, the
mapname hash and the username hash
o 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


Because the way I read it, we should be getting:

o 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)

Or am I reading this wrong?

Brian.
--------
http://brian.moonspot.net/

[cia]

its not a but. i assumed that once the user creates a map for a class
then he wants to do something with it.
if he forgets to create a map for those users then its a bug but on
their side :)
you can use this "bug of mine" to do blacklisting ;)

if you arent doint anything with "brian" then delete it.
it makes sense to me

why is this a bug? its not. is it? no.

> For more options, visit this group athttp://groups.google.com/group/geoipdns-users?hl=en.

[Brian Moon]

We are using the geo ip dns to load balance our two data centers. When
one data center goes down, we want all queries to get the IP address of
the data center that is up. We had read the docs in such a way that we
thought that a LOC with no + record would get the nomatch. If you are
saying that is not how it works, then we will go with our work around as
the actual way it should work. As of now, if we see a data center is
down, we write out an A record for that location, but with the up data
center IP address. That seems to be working. And apparently, that is how
it is supposed to work. We just misunderstood.

Brian.
--------
http://brian.moonspot.net/

[cia]

no, a LOC with no RR will be served exactly like that, no RR.

I would say that for load balancing you will be better with other
solutions and if
you really want to doit at dns level maybe multiple RRs for the same
name will help.

geoip was written mostly for country-routing, think STATIC routing not
DYNAMIC (for real LBs). the load balacing done with
geoip isn't dynamic. in fact i would say it's just not LB.

to be honest the original idea of writing geoipdns was for filtering
zombies at application layer by country. e.g. having a customer with
an online store targeting US citizens ... will make some sense that in
case of an attack (ddos) to minimize the source window ...
so because zombies are doing dns queries like crazy to catch the ips
changing on the attacked side ... had some sense to doit.


if you need a LB architect let me know. i'm a system architect with
some experience in the field ;)

On May 12, 9:12 am, Brian Moon <br...@moonspot.net> wrote:
> We are using the geo ip dns to load balance our two data centers. When
> one data center goes down, we want all queries to get the IP address of
> the data center that is up. We had read the docs in such a way that we
> thought that a LOC with no + record would get the nomatch. If you are
> saying that is not how it works, then we will go with our work around as
> the actual way it should work. As of now, if we see a data center is
> down, we write out an A record for that location, but with the up data
> center IP address. That seems to be working. And apparently, that is how
> it is supposed to work. We just misunderstood.
>
> Brian.

> --------http://brian.moonspot.net/

[Brian Moon]

On 5/12/10 8:04 AM, cia wrote:
> no, a LOC with no RR will be served exactly like that, no RR.

Good. Now that we know that 100%, we can make it work.

> I would say that for load balancing you will be better with other
> solutions and if you really want to doit at dns level maybe multiple
> RRs for the same name will help.

No, we need to only give one IP per request and we want it to be
constant unless there is a problem.

> geoip was written mostly for country-routing, think STATIC routing
> not DYNAMIC (for real LBs). the load balacing done with geoip isn't
> dynamic. in fact i would say it's just not LB.

yes, perhaps load balancing is a bad term. We want to serve people via
their closest data center, statically. The only time that someone in say
Oregon should get our east coast IP is when our west coast data center
is down. We are not doing real time traffic management via dns.

> to be honest the original idea of writing geoipdns was for filtering
> zombies at application layer by country. e.g. having a customer with
> an online store targeting US citizens ... will make some sense that
> in case of an attack (ddos) to minimize the source window ... so
> because zombies are doing dns queries like crazy to catch the ips
> changing on the attacked side ... had some sense to doit.

We will keep that original intent in mind in case it would be useful to us.

> if you need a LB architect let me know. i'm a system architect with
> some experience in the field ;)

Thanks.

Brian Moon
dealnews.com

FYI, you can officially list us as users of the software on the wiki if
you like.

[Anders Brownworth]

yes, perhaps load balancing is a bad term. We want to serve people via their closest data center, statically. The only time that someone in say Oregon should get our east coast IP is when our west coast data center is down. We are not doing real time traffic management via dns.

For what its worth (and it may not be worth much as I guess you are probably talking about web traffic) another use for GeoIPDNS is to serve location specific SRV records. So in your example, the SRV records for a request made from Oregon would list both East and West servers but West coast servers at higher preference levels than East coast servers. This would allow instantaneous failover without administrator intervention but of course relies upon sound application level SRV support. I use this for SIP records in a VoIP service because SRV is fairly widely supported in the SIP world.

--
-Anders
-----------------------------------------------------------
Anders Brownworth
http://www.anders.com/
ande...@gmail.com