Smack

Improper handeling of DNS SRV records

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: 3.0.3
  • Fix Version/s: 3.3.0
  • Component/s: Core
  • Labels:
    None
  • Acceptance Test - Add?:
    No

Description

RFC 2052 describes use for DNS SRV records. Each entry has 4 parts: A priority, a weight, a port, and the hostname. When multiple entries are returned:

"A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in pseudorandom order."

Smack currently returns the first entry returned from the DNS server, which may not have the lowest-numbered priority, and then will not attempt any other servers since the other entries are discarded.

Issue Links

blocks

Sub-task - The sub-task of the issue SMACK-386 Add support for see-other-host

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

New Feature - A new feature of the product, which has yet to be developed. SMACK-426 Improve the Exceptions on connect() and login()

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
is related to

Bug - A problem which impairs or prevents the functions of the product. OF-584 Fix DNS SRV support

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jeff Williams added a comment -

We now iterate through all of the DNS SRV records that get returned. "google.com" is a good case since there are 6 records. Technically, we should fall-back if the host in the first SRV record fails (and so on until we run out of SRV records). It won't be possible to do that without a pretty major rewrite of XMPPConnection, and that will have to come in a later version if requested (needed) by someone.

Show
Jeff Williams added a comment - We now iterate through all of the DNS SRV records that get returned. "google.com" is a good case since there are 6 records. Technically, we should fall-back if the host in the first SRV record fails (and so on until we run out of SRV records). It won't be possible to do that without a pretty major rewrite of XMPPConnection, and that will have to come in a later version if requested (needed) by someone.
Hide
Permalink
Leon Roy added a comment -

Not sure that Smack 3.2 fixes this issue. Using Smack 3.2 beta 1 and the library still attempts to connect to the first server in the SRV record list. Even if Openfire is stopped.

Show
Leon Roy added a comment - Not sure that Smack 3.2 fixes this issue. Using Smack 3.2 beta 1 and the library still attempts to connect to the first server in the SRV record list. Even if Openfire is stopped.
Hide
Permalink
Georg Lukas added a comment -

The issue is not fixed universally. First, repeated calls to resolveXMPPDomain() always return one of the lowest-priority servers, even if they are all failed.

Second, the choice among equal-priority servers is failed as well, if all have a weight of 0 (which is legal and encouraged as of RFC 2052). Then always the first entry is returned.

Show
Georg Lukas added a comment - The issue is not fixed universally. First, repeated calls to resolveXMPPDomain() always return one of the lowest-priority servers, even if they are all failed. Second, the choice among equal-priority servers is failed as well, if all have a weight of 0 (which is legal and encouraged as of RFC 2052). Then always the first entry is returned.
Hide
Permalink
Florian Schmaus added a comment -

DNS SRV records are still handled incorrectly:

  • Records with the same priority but different weight aren't randomly distributed by weight
  • Records with the same priority and all 0 weight aren't randomly distributed
Show
Florian Schmaus added a comment - DNS SRV records are still handled incorrectly: Records with the same priority but different weight aren't randomly distributed by weight Records with the same priority and all 0 weight aren't randomly distributed
Hide
Permalink
Florian Schmaus added a comment -

If the patch for proper DNS SRV handling is merged, the see-other-host feature becomes trivial to implement.

Show
Florian Schmaus added a comment - If the patch for proper DNS SRV handling is merged, the see-other-host feature becomes trivial to implement.
Hide
Permalink
Florian Schmaus added a comment -

Current state of the patch: https://github.com/flowdalic/smack/tree/dns

Show
Florian Schmaus added a comment - Current state of the patch: https://github.com/flowdalic/smack/tree/dns

People

  • Assignee:
    Florian Schmaus
    Reporter:
    Jay
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: