subdomain wildcard matching doesn't work

[choi]

Hi Anders,

I want to configure wildcard with your patch, but it seems only able
to match the nomatch entry.

%us:58.24.0.0:15::

=*.test.com:123.123.123.123::us
=*.test.com:321.321.321.321::nomatch

the result always return nomatch entry. have you encountered such
problem?

Regard

Choi

[Anders Brownworth]

Hey,

I hadn't run into this. I'll take a look and test it out...

-Anders

--

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
-----------------------------------------------------------
Anders Brownworth
http://www.anders.com/
ande...@gmail.com

[choi]

any update?

On Nov 30, 10:31 pm, Anders Brownworth <ander...@gmail.com> wrote:
> Hey,
>
> I hadn't run into this. I'll take a look and test it out...
>
> -Anders
>
>
>
>
>
>
>
> On Mon, Nov 30, 2009 at 1:22 AM, choi <digic...@gmail.com> wrote:
> > Hi Anders,
>
> > I want to configure wildcard with your patch, but it seems only able
> > to match the nomatch entry.
>
> > %us:58.24.0.0:15::
>
> > =*.test.com:123.123.123.123::us
> > =*.test.com:321.321.321.321::nomatch
>
> > the result always return nomatch entry.  have you encountered such
> > problem?
>
> > Regard
>
> > Choi
>
> > --
>
> > 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<geoipdns-users%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/geoipdns-users?hl=en.
>
> --
> -Anders
> -----------------------------------------------------------
> Anders Brownworthhttp://www.anders.com/

> ander...@gmail.com

[Pablo D'Ambrosio]

Hi Choi,

I am Paul, not Anders, verify the email. Sorry for the missmatch.

Retarda, Pablo.

Pd: I am a geoipdns (vdns) user.

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

[cia]

%xx:66.66.0.0:16::
+\052.test.com:66.66.66.66:300::us::
+\052.test.com:127.0.0.1:300::nomatch::

if you want to match your us A entry, send a query from 66.66.0.0/16
class dns client ips

i dont like '=' entries altho those should work fine. why would you
use them? if you really want a PTR record created then define it
explicitely in the database. always use '+' records

[cia]

please replace 'xx' with 'us' while reading the data sample above.


so it should read

%xx:66.66.0.0:16::
+\052.test.com:66.66.66.66:300::us::
+\052.test.com:127.0.0.1:300::nomatch::

note the EMPTY fields in my decl
there's
+domain.name:IP_ADDR:TTL::us::
after IP_ADDR there is a TTL. between TTL and the map name there is an
empty field IP_ADDR:TTL::us::
after mapname tehre are 2 empty fields

[cia]

what the hell.
so it should read
%us:66.66.0.0:6::
....
....
....

sorry! :)

[Anders Brownworth]

Choi,

Sorry for the delay in my reply. As Adrian points out, you have to escape the wildcard character, so a complete example might look like this:

------------------------------------------------------

.example.com:1.2.3.4:a:1200

+www.example.com:11.11.11.11:1200::texas

+www.example.com:22.22.22.22:1200::boston

+www.example.com:33.33.33.33:1200::north-carolina

+www.example.com:44.44.44.44:1200::new-york

+www.example.com:99.99.99.99:1200::nomatch

+\052.example.com:55.55.55.55:1200::texas

+\052.example.com:66.66.66.66:1200::boston

+\052.example.com:77.77.77.77:1200::north-carolina

+\052.example.com:88.88.88.88:1200::new-york

+\052.example.com:99.99.99.99:1200::nomatch

%texas:74.0.0.0:8

%boston:71.233.0.0:16

%north-carolina:8.14.33.0:24

%new-york:71.251.0.0:16

------------------------------------------------------

To be clear, vdns / geoipdns is Adrian's "patch", so credit belongs to him.

Adrian also brings up a good point about PTR records. (ha!) It might not make sense to use = notation which constructs both an A record and it's corresponding PTR record but rather use + notation which just constructs A records. If you think about it, vdns is responding differently for the same name depending on where you come from usually to send you to the "most local" server so a particular server's reverse address (PTR record) should probably be globally consistent.

-Anders

--

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
-----------------------------------------------------------
Anders Brownworth
http://www.anders.com/

ande...@gmail.com

[choi]

thanks all for helping, but I still got the same result using the
examples you've provided.

%us:66.66.0.0:16::

+\052.test.com:66.66.66.66:300::us::
+\052.test.com:127.0.0.1:300::nomatch::

still always return nomatch entry ip.

choi

> > geoipdns-user...@googlegroups.com<geoipdns-users%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/geoipdns-users?hl=en.
>
> --
> -Anders
> -----------------------------------------------------------
> Anders Brownworthhttp://www.anders.com/

> ander...@gmail.com

[cia]

choi,
you are exactly right. i never used wildcard records until now and it
doesnt work, exactly as you described it.
why?
because we are using PER-RECORD locmaps.
that means if you have a wildcard +*.deadpony.curacao.com:1.2.3.4....
then:
if a query comes for zombie.deadpony.curacao.com
the server is looking for a LOCMAP for the exact record
zombie.deadpony.curacao.com and not for a LOCMAP on zone curacao.com
or on an evantual wildcard
. i did this to speedup table lookups.
so basically there is no lookup for a LOCMAP assigned to a wildcard
subdomain but for the exact domain name. in the lookup process, the *
character is interpreted literally until one point. which is wrong and
right same time :)

i can fix this. give me few minutes :)

[cia]

new release 1.0r9 available at http://pub.mud.ro/~cia/files/vdns-1.0r9.tgz
this includes the wildcard locmap issue fix
a new compile time flag is defined: WILDCARD_LOCMAP included by
default in conf-cc flags.
if the flag is enabled, then when there is no locmap record for a name
the query will be rewritten for supporting a locmap
record lookup on wildcard label.

i ran some quick tests and it went ok. choi, let me know how it works
for you :)

the data file i ran the tests with:
%sl-usa:75.126.135.0:24
%sl-usa:75.126.154.0:24
%sl-usa:188.26.59.0:24
Zcuracao.com:ns10.blockdos.net.:hostmaster.blockdos.net.::::::60
&curacao.com::ns10.blockdos.net:60
&curacao.com::ns20.blockdos.net:60
+\052.deadpony.curacao.com:1.2.3.4:60::sl-usa
+\052.deadpony.curacao.com:4.3.2.1:60::nomatch
+zombie.deadpony.curacao.com:2.3.4.5:60::sl-usa
+zombie.deadpony.curacao.com:5.4.3.2:60::nomatch

the % record format, again:
%mapname:subnet:netmask:mapset:username
or, if no multiuser support is needed:
%mapname:subnet:netmask

this data format madness shall go away once i release a shell for data
administration which is supposed to hide all the
complexity. stay tuned :)

cheers!

[cia]

notes:
i choose to use a compile-time flag to enable the wildcard locmap
lookup because it adds some headache to the process by doing a query
rewrite (buffer copy) and one more database lookup. since not all
users use wildcards (i don't), most of the people won't need the
payload of default wildcard locmap lookups.

On Dec 4, 2:30 pm, cia <c...@mud.ro> wrote:
> new release 1.0r9 available athttp://pub.mud.ro/~cia/files/vdns-1.0r9.tgz

[choi]

thank you all. new version confirmed working.

choi