[sip-comm-dev] DNS hacks


#1

Hey folks,

I have just committed some DNS hacks, so please shout out in case you
see improper behaviour that might be related to DNS resolution (see
r7951 through r7966).

The point of the patch was to make SC work better in certain cases where
NAT boxes/DNS relays silently drop NAPTR and SRV queries without even
sending an error response.

Prior to the patch SC such DNS behaviour would have caused SC to fail or
take incredibly long while logging into XMPP and SIP accounts.

With the new patch, SC would try to detect when a DNS server is taking
longer than normal to respond to a query. Currently our tollerance is of
1500ms. Once this happens SC would start duplicating all DNS queries to
both the default DNS and a backup resolver that we preconfigure (i.e. a
public name server such as OpenDNS or Google). We call this "redundant mode"

While in redundant mode, SC would always take the first DNS response
that comes to either of its duplicated queries.

SC would exit redundant mode if it sees that the primary DNS starts
providing prompt responses again (i.e. faster than those of the backup
resolver). It currently takes three consecutive DNS queries with a
prompt response from the primary server for SC to go back to normal.

The main goal of the patch was not to modify default resolution
procedures but to rather complete them. In that respect, the backup DNS
servers would never substitute the primary one for example. We simply
start asking a second DNS.

So that's about it.

Comments are most welcome especially if you see an issue with either the
above scheme or the code that implements it.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey

With the new patch, SC would try to detect when a DNS server is taking
longer than normal to respond to a query. Currently our tollerance is of
1500ms. Once this happens SC would start duplicating all DNS queries to
both the default DNS and a backup resolver that we preconfigure (i.e. a
public name server such as OpenDNS or Google). We call this "redundant
mode"

Does it make sense to use Google's DNS servers when they don't answer SRV queries (they let srv-queries time out even if a record exists)?

And just in case you wonder about DNS responses being slow when everything else seems to be in order, it might as well be a bug in the JRE:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7006496

Regards,
Ingo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

На 20.12.10 23:49, Bauersachs Ingo написа:

With the new patch, SC would try to detect when a DNS server is
taking longer than normal to respond to a query. Currently our
tollerance is of 1500ms. Once this happens SC would start
duplicating all DNS queries to both the default DNS and a backup
resolver that we preconfigure (i.e. a public name server such as
OpenDNS or Google). We call this "redundant mode"

Does it make sense to use Google's DNS servers when they don't answer
SRV queries

Not sure I follow:

  ~$ host -t SRV _sip._udp.iptel.org 8.8.8.8
  Using domain server:
  Name: 8.8.8.8
  Address: 8.8.8.8#53

  _sip._udp.iptel.org has SRV record 0 0 5060 sip.iptel.org.

(they let srv-queries time out even if a record exists)?

That's actually what residential gateways would do. I've never heard of
or experienced such behaviour with Google's DNS.

Cheers,
Emil

And just in case you wonder about DNS responses being slow when
everything else seems to be in order, it might as well be a bug in
the JRE: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7006496

Regards, Ingo

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

···

For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Not sure I follow:
...

Never mind. Apparently the ICT idiots blocked requests to external DNS servers completely from the university network. :frowning:

Sorry,
Ingo


#5

На 21.12.10 00:18, Bauersachs Ingo написа:

Not sure I follow: ...

Never mind. Apparently the ICT idiots blocked requests to external
DNS servers completely from the university network. :frowning:

And that's exactly why we always first ask the local DNS servers :slight_smile:

Incidentally, we are currently not handling the case where the local
servers wrongly reply that no SRV records exist for domains that do have
them. In such cases we take their word for granted. We may work on that
soon too.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net