[reSIProcate] DNS not returning entries after 408?

[Byron Campen]

	We can't unblacklist stuff that was blacklisted because of a 503. If  
all of the available servers are keeling over from overload, and  
sending 503s, we are supposed to just shut up and wait for the  
blacklists to expire. However, it is reasonable to say that this  
behavior is not warranted in cases where we have blacklisted due to a  
timeout. If we wish to treat these two scenarios differently, maybe a  
greylisting concept is what we should use.

Best regards,
Byron Campen

> Before the recent changes, that way I understood it the  
> blacklisting was supposed to work as follows:
>
> 1.        Only blacklist an entry if there other DNS entries to try.
>
> 2.       If we have ended up blacklisting all entries from a  
> particular lookup, then un-blacklist them all and let the next  
> request start the cycle again.
>
> Scott
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org  
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf  
> Of Byron Campen
> Sent: Thursday, December 07, 2006 2:01 PM
> To: Jeremy Geras
> Cc: resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] DNS not returning entries after 408?
>
>
>
>           This is happening because the stack is blacklisting the  
> tuple that your server was running on, because it didn't respond.  
> This blacklist (currently) lasts 32s. I was thinking about making  
> this duration configurable. Does anyone want to have a discussion  
> about whether blacklisting on a UDP timeout is something we want to  
> be doing? It seems to me that we might need to have a concept of  
> "greylisting", where greylisted tuples will only be used if they  
> are all that remains to be tried. (This is opposed to a blacklisted  
> tuple, which we should never try, since chances are we have been  
> explicitly told, with a 503, to leave the tuple alone for a while.)  
> Any thoughts? (anyone?)
>
>
>
> Best regards,
>
> Byron Campen
>
> Hi,
>
>
>
> I’m using the latest code from SVN (updated today), and I’ve  
> encountered an issue with DNS in the following case:
>
>
>
> Client                                          Registrar
>
>       REGISTER (due to user login)------------->
>
>       <---------------------------------- 200 OK
>
>
>
> (at this point the Registrar becomes unavailable – its IP is still  
> reachable, but nothing is listening on UDP port 5060)
>
>
>
>       re-REGISTER (due to Expires timer)------->
>
>
>
> (~ 30 seconds go by and then I get a 408 from DUM)
>
> (client sits idle for ~ 30 seconds more)
>
>
>
>       REGISTER -------------------------------->
>
>
>
> (Get a 503 Service Unavailable immediately from DUM)
>
> (sit idle for any amount of time)
>
>
>
>       REGISTER -------------------------------->
>
>       <---------------------------------- 200 OK
>
>
>
>
>
> My client is set up to use only UDP as a transport.  I’m using  
> DUM.  I’ve looked at the logs, and it seems the reason I’m getting  
> the 503 is that there aren’t any DNS entries for my registrar: “Ran  
> out of dns entries for 192.168.1.172. Send 503”.  But this doesn’t  
> make sense, as there definitely should be entries (and since I can  
> register if I try once again after I get the 503).
>
>
>
> If I go back to an older revision (6609 which is from back in  
> September), I don’t have this issue – i.e. I don’t get the 503, my  
> last REGISTER actually goes out on the wire and I get my expected  
> 200 OK.
>
>
>
> Any thoughts?
>
>
>
> Thanks,
>
>  - Jeremy -
>
>
>
>
>
> _______________________________________________
>
> resiprocate-devel mailing list
>
> resiprocate-devel at list.resiprocate.org
>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061207/6a994594/attachment.htm>