reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] What does DNS blacklisting mean?

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature