From: Jason M. <ja...@mo...> - 2007-12-20 14:14:50
|
I am running dkim-milter version 2.4.0 (with sendmail 8.14.1) and have = noticed some strange behavior that I was not expecting. After starting, it listens on tcp port 8891 as expected: ]# netstat -atunp | grep dkim tcp 0 0 127.0.0.1:8891 0.0.0.0:* = LISTEN 8536/dkim-filter If I send a message that gets signed, there is no change to the ports it = listens on. If I receive a message that gets verified (in this case a msg without a = signature), it starts listening on a random udp port: ]# netstat -atunp | grep dkim tcp 0 0 127.0.0.1:8891 0.0.0.0:* = LISTEN 8536/dkim-filter udp 0 0 0.0.0.0:35969 0.0.0.0:* = 8536/dkim-filter If it receives another message, the UDP port number that it listens on = does not change. But if I restart the process, and it verifies another = message, then it listens on a different udp port (which appears to = increment). ]# netstat -atunp | grep dkim tcp 0 0 127.0.0.1:8891 0.0.0.0:* = LISTEN 8916/dkim-filter udp 0 0 0.0.0.0:35971 0.0.0.0:* = 8916/dkim-filter This is not causing any usability problems, but I do find it = interesting. At one point, I was able to netstat the DNS query, and it = was sent from a low numbered udp port. Not these high numbers that = dkim-milter is listening on after a verify. Are there any concerns with = this peculiar behavior? Jason |
From: Murray S. K. <ms...@se...> - 2007-12-20 18:15:39
|
On Thu, 20 Dec 2007, Jason Molzen wrote: > If I send a message that gets signed, there is no change to the ports it > listens on. > > If I receive a message that gets verified (in this case a msg without a > signature), it starts listening on a random udp port: > > ]# netstat -atunp | grep dkim > tcp 0 0 127.0.0.1:8891 0.0.0.0:* LISTEN 8536/dkim-filter > udp 0 0 0.0.0.0:35969 0.0.0.0:* 8536/dkim-filter I think the socket used for DNS queries is allocated and assigned a port number (the latter is done when the descriptor first gets used) but it's not listening for arriving datagrams other than replies. It's probably just the descriptor used to make DNS queries which is kept open between queries. > This is not causing any usability problems, but I do find it > interesting. At one point, I was able to netstat the DNS query, and it > was sent from a low numbered udp port. Not these high numbers that > dkim-milter is listening on after a verify. Are there any concerns with > this peculiar behavior? For the DNS query to come from a low-numbered port (i.e. under 1024), the resolver would have to (a) be running as root, and (b) explicitly bind to a low port number using bind() or bindresvport(). I don't which resolver you're using, but that code certainly does not exist in libar. Can you include a sample from tcpdump? |
From: Jason M. <ja...@mo...> - 2007-12-20 19:35:46
|
> I think the socket used for DNS queries is allocated and assigned a port > number (the latter is done when the descriptor first gets used) but it's > not listening for arriving datagrams other than replies. It's probably > just the descriptor used to make DNS queries which is kept open between > queries. If thats the case, should it clean up and close the udp listener once it has received its reply? >> This is not causing any usability problems, but I do find it >> interesting. At one point, I was able to netstat the DNS query, and it >> was sent from a low numbered udp port. Not these high numbers that >> dkim-milter is listening on after a verify. Are there any concerns with >> this peculiar behavior? > > For the DNS query to come from a low-numbered port (i.e. under 1024), the > resolver would have to (a) be running as root, and (b) explicitly bind to > a low port number using bind() or bindresvport(). I don't which resolver > you're using, but that code certainly does not exist in libar. Using the built-in libar. My sample from tcpdump shows that you are correct. Its the DNS query. I could not find the low numbered outbound port that I had reported on earlier. > Can you include a sample from tcpdump? ]# tcpdump -n -nn -p -s 0 -t -X -vvv dst or src port 32768 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 72) 24.187.214.157.32768 > 167.206.112.138.53: [bad udp cksum a250!] 6763+ TXT? gamma._domainkey.gmail.com. (44) 0x0000: 4500 0048 0000 4000 4011 32f4 18bb d69d E..H..@.@.2..... 0x0010: a7ce 708a 8000 0035 0034 07f7 1a6b 0100 ..p....5.4...k.. 0x0020: 0001 0000 0000 0000 0567 616d 6d61 0a5f .........gamma._ 0x0030: 646f 6d61 696e 6b65 7905 676d 6169 6c03 domainkey.gmail. 0x0040: 636f 6d00 0010 0001 com..... IP (tos 0x0, ttl 244, id 33532, offset 0, flags [DF], proto: UDP (17), length: 458) 167.206.112.138.53 > 24.187.214.157.32768: [udp sum ok] 6763 q: TXT? gamma._domainkey.gmail.com. 1/4/4 gamma._domainkey.gmail.com. TXT "k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIhyR3oItOy22ZOaBrIVe9m/iME3RqOJeasANSpg2YTHTYV+Xtp4xwf5gTjCmHQEMOs0qYu0FYiNQPQogJ2t0Mfx9zNu06rfRBDjiIU9tpx2T+NGlWZ8qhbiLo5By8apJavLyqTLavyPSrvsx0B3YzC63T4Age2CDqZYA+OwSMWQIDAQAB" ns: gmail.com. NS ns2.google.com., gmail.com. NS ns3.google.com., gmail.com. NS ns4.google.com., gmail.com. NS ns1.google.com. ar: ns1.google.com. A 216.239.32.10, ns2.google.com. A 216.239.34.10, ns3.google.com. A 216.239.36.10, ns4.google.com. A 216.239.38.10 (430) 0x0000: 4500 01ca 82fc 4000 f411 fa74 a7ce 708a E.....@....t..p. 0x0010: 18bb d69d 0035 8000 01b6 002c 1a6b 8180 .....5.....,.k.. 0x0020: 0001 0001 0004 0004 0567 616d 6d61 0a5f .........gamma._ 0x0030: 646f 6d61 696e 6b65 7905 676d 6169 6c03 domainkey.gmail. 0x0040: 636f 6d00 0010 0001 c00c 0010 0001 0000 com............. 0x0050: 012c 00e7 e66b 3d72 7361 3b20 743d 793b .,...k=rsa;.t=y; 0x0060: 2070 3d4d 4947 664d 4130 4743 5371 4753 .p=MIGfMA0GCSqGS 0x0070: 4962 3344 5145 4241 5155 4141 3447 4e41 Ib3DQEBAQUAA4GNA 0x0080: 4443 4269 514b 4267 5144 4968 7952 336f DCBiQKBgQDIhyR3o 0x0090: 4974 4f79 3232 5a4f 6142 7249 5665 396d ItOy22ZOaBrIVe9m 0x00a0: 2f69 4d45 3352 714f 4a65 6173 414e 5370 /iME3RqOJeasANSp 0x00b0: 6732 5954 4854 5956 2b58 7470 3478 7766 g2YTHTYV+Xtp4xwf 0x00c0: 3567 546a 436d 4851 454d 4f73 3071 5975 5gTjCmHQEMOs0qYu 0x00d0: 3046 5969 4e51 5051 6f67 4a32 7430 4d66 0FYiNQPQogJ2t0Mf 0x00e0: 7839 7a4e 7530 3672 6652 4244 6a69 4955 x9zNu06rfRBDjiIU 0x00f0: 3974 7078 3254 2b4e 476c 575a 3871 6862 9tpx2T+NGlWZ8qhb 0x0100: 694c 6f35 4279 3861 704a 6176 4c79 7154 iLo5By8apJavLyqT 0x0110: 4c61 7679 5053 7276 7378 3042 3359 7a43 LavyPSrvsx0B3YzC 0x0120: 3633 5434 4167 6532 4344 715a 5941 2b4f 63T4Age2CDqZYA+O 0x0130: 7753 4d57 5149 4441 5141 42c0 1d00 0200 wSMWQIDAQAB..... 0x0140: 0100 0036 8500 0d03 6e73 3206 676f 6f67 ...6....ns2.goog 0x0150: 6c65 c023 c01d 0002 0001 0000 3685 0006 le.#........6... 0x0160: 036e 7333 c12f c01d 0002 0001 0000 3685 .ns3./........6. 0x0170: 0006 036e 7334 c12f c01d 0002 0001 0000 ...ns4./........ 0x0180: 3685 0006 036e 7331 c12f c168 0001 0001 6....ns1./.h.... 0x0190: 0000 0001 0004 d8ef 200a c12b 0001 0001 ...........+.... 0x01a0: 0000 0013 0004 d8ef 220a c144 0001 0001 ........"..D.... 0x01b0: 0000 0013 0004 d8ef 240a c156 0001 0001 ........$..V.... 0x01c0: 0000 0013 0004 d8ef 260a ........&. |
From: Murray S. K. <ms...@se...> - 2007-12-20 22:25:57
|
On Thu, 20 Dec 2007, Jason Molzen wrote: >> I think the socket used for DNS queries is allocated and assigned a port >> number (the latter is done when the descriptor first gets used) but it's >> not listening for arriving datagrams other than replies. It's probably >> just the descriptor used to make DNS queries which is kept open between >> queries. > > If thats the case, should it clean up and close the udp listener once it has > received its reply? Nope. As I said, it's kept open between queries. There's little sense closing down the socket when I'd just have to re-create it moments later for the next query. Moreover, there could be lots of pending replies; it's not a one-to-one relationship between sockets and queries. |