Re: ip-port.torhosts.nighteffect.us and exim

["Joseph B. Kowalski" <jbk@xxxxxxx>]

On Thu, 26 Apr 2007 08:45:39 -0700 Mike Cardwell 
<tor@xxxxxxxxxxxxxxxxxx> wrote:
>I've been looking into how to use this with Exim4. I just thought 
>I'd
>share it here for the benefit of the archives.
>
>warn dnslists    = 
>$interface_port.${sg{$interface_address}{\N^(\d+)\.(\d+)\.(\d+)\.(\
>d+)$\N}{\$4\.\$3\.\$2\.\$1}}.ip-port.torhosts.nighteffect.us
>     log_message = This connection is coming from a tor node that 
>allows exiting to this ip/port combination
>
>The ACL simply logs the connection, it doesn't perform a 
>rejection, or
>adding a header to the message or anything else. That part is left 
>to
>the reader or the exim users mailing list.
>
>It was made slightly more difficult to use by the fact that I had 
>to
>reverse the 4 octets of the IP address of the host being connected 
>to. I
>understand why this was done though and agree with it.
>
>Just out of interest, why do lookups that return positive results 
>take
>such a long time? This is what I typically get:
>
>server:~# time host 20.136.234.85.109.123.123.123.123.ip-
>port.torhosts.nighteffect.us
>20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us 
>has address 127.0.0.2
>Host 20.136.234.85.109.123.123.123.123.ip-
>port.torhosts.nighteffect.us not found: 2(SERVFAIL)
>Host 20.136.234.85.109.123.123.123.123.ip-
>port.torhosts.nighteffect.us not found: 2(SERVFAIL)
>
>real    0m23.451s
>user    0m0.030s
>sys     0m0.010s
>
>The first line of response is pretty quick, then there are long 
>delays
>before each SERVFAIL...
>
>If the lookup returns an NXDOMAIN, there are no SERVFAILS so the 
>lookups
>are much faster. I'm not a DNS expert so I'm not sure what is 
>happening
>that causes the SERVFAIL's...
>

Hi Mike,

There are a couple of things going on here. First, the reason why 
you see the first line returned from the 'host' command as 
successful, followed by two 'SERVFAIL' lines is that the 'host' 
command, by default, sends an 'A' request followed by an 'AAAA' 
(IPv6 Lookup) and 'MX' (Mail Exchanger) request. The DNSEL server 
only supports 'A' requests, and so in the case of the second and 
third queries, the DNSEL server is actually returning a 'NOTIMP' 
(Not Implemented) error message, and your local upstream DNS server 
is returning that to you as a 'SERVFAIL' error message. If you run 
the 'host' command with the "Type" flag set, you can prevent 'host' 
from sending the 'AAAA' and 'MX' requests altogether, eliminating 
the two error lines. For example, your query could be:

time host -t A 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us

Second, to address the speed issue, it's likely that your local 
upstream DNS server has some method of operation that really slows 
things down when there is an error returned from the DNSEL server, 
like the two 'NOTIMP' messages I described above. It may be 
retrying those same 'AAAA' and 'MX' requests several times before 
returning the 'SERVFAIL' message to you, holding things up a bit. 
So, the good news is, the speed issue is probably already gone just 
by you using the "Type" flag with the 'host' command, like I 
discussed above. Personally, I know there is no extra delay from 
the DNSEL server when it's returning a 'SERVFAIL', 'NOTIMP', or 
'NXDOMAIN' message, as opposed to a successful lookup.

If necessary, for troubleshooting, you can easily see where the 
delay is occuring by taking your upstream DNS provider out of the 
loop temporarily by telling the 'host' command to talk to the DNSEL 
server directly. So, you could do this (If you still wanted it to 
do the 'A', 'AAAA', and 'MX' requests:

time host 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us 216.55.190.201

Or do this (To exclude the 'AAAA' and 'MX' requests):

time host -t A 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us 216.55.190.201

This will let you see the real speed that the DNSEL server is 
responding with.


Please let me know if you have any other questions. I hope that 
helped!


Best regards,


Joe Kowalski