[reSIProcate] What does DNS blacklisting mean?

Fri Dec 1 13:00:18 CST 2006

	This new DNS code isn't a critical fix (except one small part, and  
this was one of the things that made it into 1.0.2) , so it probably  
won't get backported to the 1.0 release branch. You will probably see  
it when 1.1 rolls around (in January, I hope).

	The assert you are seeing is indeed related to interactions with the  
old code. Basically, this is an assertion that all outstanding DNS  
queries have finished.

Best regards,
Byron Campen

> Yow, I noticed that change yesterday.  I grabbed the new testDns,  
> but it
> didn't like the 1.0.2 version of DnsResult.  Then I grabbed that,  
> it needed
> a lot of other things.  I stuck with the 1.0.2 stack and commented  
> out lines
> 91 through 95 in testDns, which seemed to work.  Those lines call
> DnsResult::blacklistLast().  My last email was using the 1.0.2  
> version of
> testDns.cxx.
>
> I just noticed that the first assert(!dns.requiresProcess()) before  
> the
> load-leveling test in the new testDns.cxx fails.  That may be a  
> result of me
> mixing new and old code.
>
> I'll look further into what happens when things get blacklisted.   
> Soon as I
> get past that assert problem I may find that blacklisted items  
> don't get
> returned.  I also notice theyre only blacklisted for a given time.
>
> Will there be a 1.0.3 soon, or a stable point when I can download
> everything? :)
>
> Regards,
> Dave
>
> -----Original Message-----
> From: Byron Campen
> Sent: Friday, December 01, 2006 11:38 AM
> To: Dave Mason
> Subject: Re: [reSIProcate] What does DNS blacklisting mean?
>
> 	So, before I took a pickaxe to it, DnsResult::next() would result in
> blacklisting the result it had returned previously. I removed this  
> behavior.
> Now you need to explicitly tell DnsResult that you wish to  
> blacklist the
> last returned tuple. (through DnsResult::blacklistLast (), I think)  
> Check
> out the latest revision. (A note: testDns is very different now. It  
> may be
> hard to digest.)
>
> Best regards,
> Byron Campen
>
>> Thanks, that makes sense.  Guess I'm still curious how the DNS layer
>> would know what happened at the SIP layer.  When I run the 1.0.2
>> version of testDns for "sip:yahoo.com", which only has A records, I
>> get a good response but it appears the A records always get
>> blacklisted:
>>
>> STACK | 20061130-161358.478 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:944 | No SRV records for yahoo.com. Trying A records
>> STACK | 20061130-161358.597 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | dns/DnsStub.cxx:371 | DnsStub::Query::go: yahoo.com type(enum): 1
>> proto: 1
>> STACK | 20061130-161358.708 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:693 | Received dns result for: yahoo.com
>> STACK | 20061130-161358.708 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:694 | DnsResult::onDnsResult() 0
>> STACK | 20061130-161358.708 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:712 | Adding [ V4 66.94.234.13:5060 UDP target
>> domain=yahoo.com connectionId=0 ] to result set STACK |
>> 20061130-161358.708 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:712 | Adding [ V4 216.109.112.135:5060 UDP target
>> domain=yahoo.com connectionId=0 ] to result set DnsHandler received
>> yahoo.com STACK | 20061130-161358.708 | dcmlaptop | testDns |
>> RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:143 | Returning next dns entry: [ V4
>> 66.94.234.13:5060 UDP
>> target domain=yahoo.com connectionId=0 ] yahoo.com -> [ V4
>> 66.94.234.13:5060 UDP target domain=yahoo.com connectionId=0 ]  
>> STACK |
>> 20061130-161358.708 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:143 | Returning next dns entry: [ V4
>> 216.109.112.135:5060
>> UDP target domain=yahoo.com connectionId=0 ] DEBUG |
>> 20061130-161358.709 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:1197 | Blacklisting yahoo.com(1): 66.94.234.13
>> DEBUG | 20061130-161358.709 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:1199 | Remove vip yahoo.com(1)
>> yahoo.com -> [ V4 216.109.112.135:5060 UDP target domain=yahoo.com
>> connectionId=0 ] DEBUG | 20061130-161358.709 | dcmlaptop | testDns |
>> RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:1197 | Blacklisting yahoo.com(1): 216.109.112.135
>> DEBUG | 20061130-161358.709 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:1199 | Remove vip yahoo.com(1)
>> STACK | 20061130-161358.709 | dcmlaptop | testDns | RESIP:DNS |
>> 21943 | 1026
>> | DnsResult.cxx:399 | Priming []
>> DNS results for sip:yahoo.com
>> [ V4 66.94.234.13:5060 UDP target domain=yahoo.com connectionId=0 ] [
>> V4 216.109.112.135:5060 UDP target domain=yahoo.com connectionId=0 ]
>>
>> Also, if I change testDns to put this in a loop to do a sequence of 4
>> lookups on the same URI, the ipAddrs always come back in a different
>> order.
>> Is that caused by blacklisting?  (Call dns.lookup 4 times, wait for
>> all to complete(), then print results.)  Guess I was thinking that if
>> something was really "blacklisted" it wouldn't get returned at all on
>> following lookups.
>>
>> DNS results for sip:yahoo.com
>> [ V4 216.109.112.135:5060 UDP target domain=yahoo.com  
>> connectionId=0 ]
>> [ V4 66.94.234.13:5060 UDP target domain=yahoo.com connectionId=0 ]
>> DNS results for sip:yahoo.com [ V4 66.94.234.13:5060 UDP target
>> domain=yahoo.com connectionId=0 ] [ V4 216.109.112.135:5060 UDP  
>> target
>> domain=yahoo.com connectionId=0 ] DNS results for sip:yahoo.com [ V4
>> 216.109.112.135:5060 UDP target domain=yahoo.com connectionId=0 ]  
>> [ V4
>> 66.94.234.13:5060 UDP target domain=yahoo.com connectionId=0 ] DNS
>> results for sip:yahoo.com [ V4 66.94.234.13:5060 UDP target
>> domain=yahoo.com connectionId=0 ] [ V4 216.109.112.135:5060 UDP  
>> target
>> domain=yahoo.com connectionId=0 ]
>>
>> Regards,
>> Dave
>>
>> ________________________________
>>
>> From: Byron Campen
>> Sent: Thursday, November 30, 2006 5:04 PM
>> To: Dave Mason
>> Subject: Re: [reSIProcate] What does DNS blacklisting mean?
>>
>>
>> Ok, in the event that you get a 503 with a Retry-After from a UAS you
>> tried to send to, you are supposed to refrain from sending to that
>> tuple again until the Retry-After has expired. The way we do this is
>> allow tuples to be "blacklisted" for a fixed duration, during which
>> the DNS system will discard any results pointing to that tuple, as it
>> looks them up. If, however, many queries were executed  
>> simultaneously,
>> it is possible that many DnsResults will happily give you a
>> blacklisted tuple that they loaded before you blacklisted it.
>>
>> Best regards,
>> Byron Campen
>>
>>
>> 	Hi,
>>
>> 	Hate to ask a noob question, but what does it mean when a DNS query
>> result
>> 	gets blacklisted?  I saw on the web page it has something to do with
>
>> a
>> 	transmit failure, so I assume I shouldn't use the tuples that get
>> returned
>> 	in the query results vector.  If those results are bad, why do they
>> still
>> 	get returned?  Is there a status flag I should check before using
>> them?
>>
>> 	Regards,
>> 	Dave
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061201/29d77192/attachment.bin>