ipset causes reverse dns lookups?

ipset causes reverse dns lookups?

[Ed W]

Hi, ipset appears to require a reverse dns lookup for say:

     ipset create cp bitmap:ip,mac range 192.168.111.0/24

Why?

In particular if I lock down iptables (-P DROP), then the above command 
takes quite some seconds to complete, rather than instantly if I open up 
iptables.  This is causing me some problems with startup scripts

Am I missing some configuration option? Is this a bug? Why is a reverse 
DNS lookup needed?

ipset 6.9.1, kernel 3.2.13

Thanks

Ed W

Re: ipset causes reverse dns lookups?

[Ed W]

On 16/04/2012 00:26, Ed W wrote:
> In particular if I lock down iptables (-P DROP), then the above 
> command takes quite some seconds to complete, rather than instantly if 
> I open up iptables.  This is causing me some problems with startup 
> scripts
>
> Am I missing some configuration option? Is this a bug? Why is a 
> reverse DNS lookup needed?

eg

$ iptables -I INPUT -j REJECT
$ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24
ipset v6.9.1: Set cannot be created: set with the same name already exists
Command exited with non-zero status 1
real    0m 45.11s
user    0m 0.01s
sys     0m 0.00s

$ iptables -F
$ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24
ipset v6.9.1: Set cannot be created: set with the same name already exists
Command exited with non-zero status 1
real    0m 0.01s
user    0m 0.00s
sys     0m 0.00s


/var/log/messages:
Apr 16 01:14:55 localhost daemon.info dnsmasq[6272]: query[PTR] 
1.1.168.192.in-addr.arpa from 127.0.0.1
Apr 16 01:14:55 localhost daemon.info dnsmasq[6272]: config 192.168.1.1 
is NXDOMAIN-IPv4

What am I doing wrong?

Re: ipset causes reverse dns lookups?

[Ed W]

On 16/04/2012 02:15, Ed W wrote:
> On 16/04/2012 00:26, Ed W wrote:
>> In particular if I lock down iptables (-P DROP), then the above 
>> command takes quite some seconds to complete, rather than instantly 
>> if I open up iptables.  This is causing me some problems with startup 
>> scripts
>>
>> Am I missing some configuration option? Is this a bug? Why is a 
>> reverse DNS lookup needed?
>
> eg
>
> $ iptables -I INPUT -j REJECT
> $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24
> ipset v6.9.1: Set cannot be created: set with the same name already 
> exists
> Command exited with non-zero status 1
> real    0m 45.11s
> user    0m 0.01s
> sys     0m 0.00s

I upgraded to ipset 6.11 and note the same issue.  I also just 
discovered I can repro this when adding to a set, eg:

$ time /usr/sbin/ipset -! -q add cp2 192.168.105.56,58:b0:35:78:0d:f5
Command exited with non-zero status 1
real    1m 0.09s
user    0m 0.00s
sys    0m 0.01s


In this case I have multiple internet connections. Pushing IPs into an 
ipset forces that ip over a particular connection.  If the box is 
currently on some non responsive network, then the resolver isn't 
working correctly and ipset is consequently also slow.

Any ideas how I can get out of this?

Thanks

Ed W

Re: ipset causes reverse dns lookups?

[Jozsef Kadlecsik]

On Mon, 16 Apr 2012, Ed W wrote:

> On 16/04/2012 02:15, Ed W wrote:
> > On 16/04/2012 00:26, Ed W wrote:
> > > In particular if I lock down iptables (-P DROP), then the above command
> > > takes quite some seconds to complete, rather than instantly if I open up
> > > iptables.  This is causing me some problems with startup scripts
> > > 
> > > Am I missing some configuration option? Is this a bug? Why is a reverse
> > > DNS lookup needed?
> > 
> > eg
> > 
> > $ iptables -I INPUT -j REJECT
> > $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24
> > ipset v6.9.1: Set cannot be created: set with the same name already exists
> > Command exited with non-zero status 1
> > real    0m 45.11s
> > user    0m 0.01s
> > sys     0m 0.00s
> 
> I upgraded to ipset 6.11 and note the same issue.  I also just discovered I
> can repro this when adding to a set, eg:
> 
> $ time /usr/sbin/ipset -! -q add cp2 192.168.105.56,58:b0:35:78:0d:f5
> Command exited with non-zero status 1
> real    1m 0.09s
> user    0m 0.00s
> sys    0m 0.01s 
> 
> In this case I have multiple internet connections. Pushing IPs into an ipset
> forces that ip over a particular connection.  If the box is currently on some
> non responsive network, then the resolver isn't working correctly and ipset is
> consequently also slow.

Hostname and IP address are both supported as input and resolved 
internally by getaddrinfo. That can generate DNS lookups, depeding on the 
resolver library. What kind of system do you use, with which 
resolver/libc version?

I could suppress DNS lookups with the price of calling twice getaddrinfo.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset causes reverse dns lookups?

[Ed W]

On 16/04/2012 09:08, Jozsef Kadlecsik wrote:
> Hostname and IP address are both supported as input and resolved
> internally by getaddrinfo. That can generate DNS lookups, depeding on the
> resolver library. What kind of system do you use, with which
> resolver/libc version?

Thanks so much for replying!

This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, 
then dns. Local dnsmasq is installed.

I can very clearly observe that on something like "ipset add", if I add 
something that isn't quite an IP address then it generates a name 
lookup. What I'm confused by is why the reverse ip lookup for the ip 
address?  I have traced it back I think to the parser.c code, but I 
concede I'm stuck understanding even what is generating the lookup?  You 
mention resolver, so presumably it's a side effect of some other call, 
but could you spare a minute to explain the trigger please?  (just 
interested in the background in case it occurs elsewhere?)

> I could suppress DNS lookups with the price of calling twice getaddrinfo.

You are presumably giving me a clue as the source here!

It would not appear to be a significant performance decrease for the 
normal situation to call twice?  Given the outside edge case of 1+ min 
delays I'm definitely interested in such a change?

Is there any chance of a tentative patch or at least a stronger hint at 
what I should change in order that I could deploy something quite 
imminently?  Its become a bit of a blocker here...  Obviously I'm asking 
with as much icing as possible and a huge cherry on top...

Thanks Jozsef

Ed W

Re: ipset causes reverse dns lookups?

[Jozsef Kadlecsik]

On Mon, 16 Apr 2012, Ed W wrote:

> On 16/04/2012 09:08, Jozsef Kadlecsik wrote:
> > Hostname and IP address are both supported as input and resolved
> > internally by getaddrinfo. That can generate DNS lookups, depeding on the
> > resolver library. What kind of system do you use, with which
> > resolver/libc version?
> 
> Thanks so much for replying!
> 
> This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then dns.
> Local dnsmasq is installed.
> 
> I can very clearly observe that on something like "ipset add", if I add
> something that isn't quite an IP address then it generates a name lookup. What
> I'm confused by is why the reverse ip lookup for the ip address?  I have
> traced it back I think to the parser.c code, but I concede I'm stuck
> understanding even what is generating the lookup?  You mention resolver, so
> presumably it's a side effect of some other call, but could you spare a minute
> to explain the trigger please?  (just interested in the background in case it
> occurs elsewhere?)

That comes from the implementation of "getaddrinfo" in uclibc then. ipset 
itself does not force reverse DNS lookups.
 
> > I could suppress DNS lookups with the price of calling twice getaddrinfo.
> 
> You are presumably giving me a clue as the source here!
> 
> It would not appear to be a significant performance decrease for the normal
> situation to call twice?  Given the outside edge case of 1+ min delays I'm
> definitely interested in such a change?
> 
> Is there any chance of a tentative patch or at least a stronger hint at what I
> should change in order that I could deploy something quite imminently?  Its
> become a bit of a blocker here...  Obviously I'm asking with as much icing as
> possible and a huge cherry on top...

Try the following untested patch:

diff --git a/lib/parse.c b/lib/parse.c
index 30efdb6..8b86492 100644
--- a/lib/parse.c
+++ b/lib/parse.c
@@ -8,6 +8,7 @@
 #include <errno.h>				/* errno */
 #include <limits.h>				/* ULLONG_MAX */
 #include <netdb.h>				/* getservbyname, getaddrinfo */
+#include <string.h>				/* str* */
 #include <stdlib.h>				/* strtoull, etc. */
 #include <sys/types.h>				/* getaddrinfo */
 #include <sys/socket.h>				/* getaddrinfo, AF_ */
@@ -687,6 +688,18 @@ call_getaddrinfo(struct ipset_session *session, const char *str,
 	hints.ai_protocol = 0;
 	hints.ai_next = NULL;
 
+	if (family == NFPROTO_IPV6) {
+		if (strchr(str, ':') != NULL)
+			hints.ai_flags |= AI_NUMERICHOST;
+	} else {
+		if (strspn(str, "0123456789.") == strlen(str))
+			hints.ai_flags |= AI_NUMERICHOST;
+	}
+	if ((err = getaddrinfo(str, NULL, &hints, &res)) != 0)
+		hints.ai_flags &= ~AI_NUMERICHOST;
+	else
+		return res;
+
 	if ((err = getaddrinfo(str, NULL, &hints, &res)) != 0) {
 		syntax_err("cannot resolve '%s' to an %s address: %s",
 			   str, family == NFPROTO_IPV6 ? "IPv6" : "IPv4",

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset causes reverse dns lookups?

[Amos Jeffries]

On 16/04/2012 9:55 p.m., Jozsef Kadlecsik wrote:
> On Mon, 16 Apr 2012, Ed W wrote:
>
>> On 16/04/2012 09:08, Jozsef Kadlecsik wrote:
>>> Hostname and IP address are both supported as input and resolved
>>> internally by getaddrinfo. That can generate DNS lookups, depeding on the
>>> resolver library. What kind of system do you use, with which
>>> resolver/libc version?
>> Thanks so much for replying!
>>
>> This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then dns.
>> Local dnsmasq is installed.
>>
>> I can very clearly observe that on something like "ipset add", if I add
>> something that isn't quite an IP address then it generates a name lookup. What
>> I'm confused by is why the reverse ip lookup for the ip address?  I have
>> traced it back I think to the parser.c code, but I concede I'm stuck
>> understanding even what is generating the lookup?  You mention resolver, so
>> presumably it's a side effect of some other call, but could you spare a minute
>> to explain the trigger please?  (just interested in the background in case it
>> occurs elsewhere?)
> That comes from the implementation of "getaddrinfo" in uclibc then. ipset
> itself does not force reverse DNS lookups.

FWIW, I have recently been dealing with user complains with other 
software when built with uclibc. The uclibc implementation has been 
caught ignoring AI_NUMERICHOST and performing full remote resolution 
when passed numeric IPs for conversion.

AYJ

Re: ipset causes reverse dns lookups?

[Ed W]

On 16/04/2012 10:55, Jozsef Kadlecsik wrote:
> Try the following untested patch:
>

Thanks for the idea.  I'm not 100% sure I'm testing correctly, but I 
rebuilt and I see no change...


Does the following strace help any?

$ /tmp/strace /tmp/ipset add cp2 192.168.105.56,58:b0:35:78:0d:f5
execve("/tmp/ipset", ["/tmp/ipset", "add", "cp2", 
"192.168.105.56,58:b0:35:78:0d:f5"], [/* 16 vars */]) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9cc000
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=6754, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
mmap2(NULL, 6754, PROT_READ, MAP_SHARED, 3, 0) = 0x4f9ca000
close(3)                                = 0
stat("/etc/ld.so.preload", 0x5cc84aec)  = -1 ENOENT (No such file or 
directory)
open("/lib/libmnl.so.0", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=17580, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0L\25\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 24576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4f9c3000
mmap2(0x4f9c3000, 13016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 
0) = 0x4f9c3000
mmap2(0x4f9c7000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x3) = 0x4f9c7000
close(3)                                = 0
munmap(0x4f9c9000, 4096)                = 0
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=91276, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0|\"\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 94208, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4f9ac000
mmap2(0x4f9ac000, 85844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 
0) = 0x4f9ac000
mmap2(0x4f9c1000, 4120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x15) = 0x4f9c1000
close(3)                                = 0
munmap(0x4f9c9000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\333\0\0004\0\0\0"..., 
4096) = 4096
mmap2(NULL, 397312, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4f94b000
mmap2(0x4f94b000, 365288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 
0) = 0x4f94b000
mmap2(0x4f9a5000, 4904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x59) = 0x4f9a5000
mmap2(0x4f9a7000, 19752, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4f9a7000
close(3)                                = 0
munmap(0x4f9c9000, 4096)                = 0
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=91276, ...}) = 0
close(3)                                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0
close(3)                                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0
close(3)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=25236, ...}) = 0
munmap(0x4f9ca000, 6754)                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9cb000
set_thread_area({entry_number:-1 -> 6, base_addr:0x4f9cb6a0, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, 
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\254#\3\273", 4)               = 4
close(3)                                = 0
mprotect(0x1409c000, 8192, PROT_READ)   = 0
mprotect(0x4f9c7000, 4096, PROT_READ)   = 0
mprotect(0x4f9c1000, 4096, PROT_READ)   = 0
mprotect(0x4f9a5000, 4096, PROT_READ)   = 0
mprotect(0x4f9d4000, 4096, PROT_READ)   = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
brk(0)                                  = 0x142dc390
brk(0x142e0390)                         = 0x142e0390
brk(0x142e1000)                         = 0x142e1000
socket(PF_NETLINK, SOCK_RAW, 12)        = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=11097, groups=00000000}, [12]) = 0
time(NULL)                              = 1334580838
sendto(3, "\34\0\0\0\1\6\1\0g\26\214O\0\0\0\0\2\0\0\0\5\0\1\0\6\0\0\0", 
28, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 28
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\34\0\0\0\1\6\0\0g\26\214OY+\0\0\2\0\0\0\5\0\1\0\6\0\0\0\0\0\0\0"..., 
256}], msg_controllen=0, msg_flags=0}, 0) = 28
sendto(3, 
"$\0\0\0\f\6\1\0h\26\214O\0\0\0\0\2\0\0\0\5\0\1\0\6\0\0\0\10\0\2\0"..., 
36, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 36
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"H\0\0\0\f\6\0\0h\26\214OY+\0\0\2\0\0\0\5\0\1\0\6\0\0\0\10\0\2\0"..., 
256}], msg_controllen=0, msg_flags=0}, 0) = 72
socket(PF_NETLINK, SOCK_RAW, 0)         = 4
bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(4, {sa_family=AF_NETLINK, pid=11097, groups=00000000}, [12]) = 0
time(NULL)                              = 1334580838
sendto(4, "\24\0\0\0\22\0\1\3f\26\214O\0\0\0\0\0\0\0\0", 20, 0, 
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\340\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 3012
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\4\0\0\0\3\20\0\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 2996
brk(0x142e2000)                         = 0x142e2000
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\334\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\0\3\7\0\0\0\200\0\0\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 2988
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\n\0\0\0C\20\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 2984
brk(0x142e3000)                         = 0x142e3000
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\320\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\0\2\r\0\0\0\321\20\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 2972
brk(0x142e4000)                         = 0x142e4000
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\20\0\0\0C\20\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 1008
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\24\0\0\0\3\0\2\0f\26\214OY+\0\0\0\0\0\0\20\0\0\0C\20\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
sendto(4, "\24\0\0\0\26\0\1\3g\26\214O\0\0\0\0\0\0\0\0", 20, 0, 
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"0\0\0\0\24\0\2\0g\26\214OY+\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 268
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"@\0\0\0\24\0\2\0g\26\214OY+\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 384
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, 
msg_iov(1)=[{"\24\0\0\0\3\0\2\0g\26\214OY+\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
brk(0x142e5000)                         = 0x142e5000
close(4)                                = 0
open("/etc/hosts", O_RDONLY)            = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x5cc842c8) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "# /etc/hosts: Local Host Databas"..., 4096) = 1061
read(4, "", 4096)                       = 0
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x5cc83f70) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "# Generated by resolvconf\nsearch"..., 4096) = 174
read(4, "", 4096)                       = 0
close(4)                                = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 28) = 0
send(4, "\0\2\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
recv(4, 
"\0\2\205\203\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 512, 
MSG_DONTWAIT) = 45
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 28) = 0
send(4, "\0\3\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
65, 0) = 65
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.105.212")}, 28) = 0
send(4, "\0\4\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("8.8.8.8")}, 28) = 0
send(4, "\0\5\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("8.8.4.4")}, 28) = 0
send(4, "\0\6\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 28) = 0
send(4, "\0\7\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
recv(4, 
"\0\7\205\203\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 512, 
MSG_DONTWAIT) = 45
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 28) = 0
send(4, "\0\10\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
65, 0) = 65
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)                                = 0
stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.105.212")}, 28) = 0
send(4, "\0\t\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 
45, 0) = 45
poll([{fd=4, events=POLLIN}], 1, 5000^C <unfinished ...>

Re: ipset causes reverse dns lookups?

[Jozsef Kadlecsik]

On Mon, 16 Apr 2012, Ed W wrote:

> On 16/04/2012 10:55, Jozsef Kadlecsik wrote:
> > Try the following untested patch:
> 
> Thanks for the idea.  I'm not 100% sure I'm testing correctly, but I rebuilt
> and I see no change...

See the message from Amos in this thread: if uclibc ignores 
AI_NUMERICHOST, then I can't workaround that :-(.
 
Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset causes reverse dns lookups?

[Jozsef Kadlecsik]

On Tue, 17 Apr 2012, Amos Jeffries wrote:

> On 16/04/2012 9:55 p.m., Jozsef Kadlecsik wrote:
> > On Mon, 16 Apr 2012, Ed W wrote:
> > 
> > > On 16/04/2012 09:08, Jozsef Kadlecsik wrote:
> > > > Hostname and IP address are both supported as input and resolved
> > > > internally by getaddrinfo. That can generate DNS lookups, depeding on
> > > > the
> > > > resolver library. What kind of system do you use, with which
> > > > resolver/libc version?
> > > Thanks so much for replying!
> > > 
> > > This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then
> > > dns.
> > > Local dnsmasq is installed.
> > That comes from the implementation of "getaddrinfo" in uclibc then. ipset
> > itself does not force reverse DNS lookups.
> 
> FWIW, I have recently been dealing with user complains with other software
> when built with uclibc. The uclibc implementation has been caught ignoring
> AI_NUMERICHOST and performing full remote resolution when passed numeric IPs
> for conversion.

That'd bad, because then DNS lookup is always performed - and cannot be 
switched off. Hopefully they'll fix the issue in uclibc. Thanks the info.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset causes reverse dns lookups?

[Ed W]

On 16/04/2012 14:48, Jozsef Kadlecsik wrote:
> On Mon, 16 Apr 2012, Ed W wrote:
>
>> On 16/04/2012 14:20, Jozsef Kadlecsik wrote:
>>> On Mon, 16 Apr 2012, Ed W wrote:
>>>
>>>> On 16/04/2012 10:55, Jozsef Kadlecsik wrote:
>>>>> Try the following untested patch:
>>>> Thanks for the idea.  I'm not 100% sure I'm testing correctly, but I
>>>> rebuilt
>>>> and I see no change...
>>> See the message from Amos in this thread: if uclibc ignores
>>> AI_NUMERICHOST, then I can't workaround that :-(.
>> Could you please investigate keeping your changes and I will separately
>> investigate fixing/patching uclibc.  I found Amos' referenced post and it
>> gives some background on what is needed to resolve this
> Sure.
>

I have now implemented a fix in uclibc.  The current patch I submitted 
is not optimised by the AI_NUMERICSERV option, so whilst leave it in if 
there is no harm, it's not necessary for uclibc.  Performance has 
improved dramatically!

Thanks for all the help - very much appreciated!

Ed W