Openfire (ARCHIVED)

Refine DNS s2s tree algorithm to account for international domains

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: 2.3.0 Alpha 1
  • Fix Version/s: 3.x
  • Component/s: Core
  • Description:
    Hide

    The DNS search tree algorithm in the s2s should account for international domain names. For example "co.uk" is a common domain name. So, if searching for:

    conference.example.co.uk

    the search should stop at example.co.uk and should not continue to co.uk. The algorithm can be that if the last portion of the domain is a two-letter domain, then stop the search at the 3rd level domain instead of 2nd level domain. However, we need to research this to confirm that this is how international domains work.

    Although this is a minor security issue, it should be fixed.

    Show
    The DNS search tree algorithm in the s2s should account for international domain names. For example "co.uk" is a common domain name. So, if searching for: conference.example.co.uk the search should stop at example.co.uk and should not continue to co.uk. The algorithm can be that if the last portion of the domain is a two-letter domain, then stop the search at the 3rd level domain instead of 2nd level domain. However, we need to research this to confirm that this is how international domains work. Although this is a minor security issue, it should be fixed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matt Tucker added a comment - 09/25/05 05:48 AM

BTW, the relevant code is in OutgoingServerSession around line 160.

Show
Matt Tucker added a comment - 09/25/05 05:48 AM BTW, the relevant code is in OutgoingServerSession around line 160.
Hide
Permalink
Joe Auricchio added a comment - 10/06/05 03:04 AM

There are plenty of domains that do NOT work like this. Quick counterexample: www.sony.jp.

Show
Joe Auricchio added a comment - 10/06/05 03:04 AM There are plenty of domains that do NOT work like this. Quick counterexample: www.sony.jp.
Hide
Permalink
Norman Rasmussen added a comment - 07/04/06 10:11 PM

Perhaps there shouldn't be a DNS search tree at all?

Probably the best way to go forward would be to make a server setting for search depth.

Those admins that don't want ANY 'searching' can set it to 0.
Conservative admins can set it to 1 or 2,
For the existing behaviour it can be set to any higher number - eg: 9.

Show
Norman Rasmussen added a comment - 07/04/06 10:11 PM Perhaps there shouldn't be a DNS search tree at all? Probably the best way to go forward would be to make a server setting for search depth. Those admins that don't want ANY 'searching' can set it to 0. Conservative admins can set it to 1 or 2, For the existing behaviour it can be set to any higher number - eg: 9.
Hide
Permalink
LG added a comment - 11/13/07 03:14 PM

I would close this issue with wont-fix. In UK the ccSLD for companies with commercial interests is .co.uk while in Singapore it's .com.sg. In Germany there are no ccSLDs.
So you would have to build and also manage a list of all ccSLDs, I guess that this is something you don't want to do.

Show
LG added a comment - 11/13/07 03:14 PM I would close this issue with wont-fix. In UK the ccSLD for companies with commercial interests is .co.uk while in Singapore it's .com.sg. In Germany there are no ccSLDs. So you would have to build and also manage a list of all ccSLDs, I guess that this is something you don't want to do.
Hide
Permalink
Norman Rasmussen added a comment - 11/13/07 03:36 PM

The code has been refactored so much since this bug was reported, I'm not even sure the originally reported bug is still present.

What used to happen was: assuming no dns entries were present, lookups for a s2s connection used to check:

transport.example.co.uk, then
example.co.uk, then
co.uk, then
uk

Now there's no where in the xmpp rfc's that say that if a dns lookup fails that you should strip the left most part and re-try. If the behaviour in trunk today is to fail after the first dns lookup, then I think we can just close this ticket as 'fixed-due-to-previous-refactoring'.

Show
Norman Rasmussen added a comment - 11/13/07 03:36 PM The code has been refactored so much since this bug was reported, I'm not even sure the originally reported bug is still present. What used to happen was: assuming no dns entries were present, lookups for a s2s connection used to check: transport.example.co.uk, then example.co.uk, then co.uk, then uk Now there's no where in the xmpp rfc's that say that if a dns lookup fails that you should strip the left most part and re-try. If the behaviour in trunk today is to fail after the first dns lookup, then I think we can just close this ticket as 'fixed-due-to-previous-refactoring'.
Hide
Permalink
Daryl Herzmann added a comment - 01/07/10 01:15 AM

Closing issue for now, can reopen if somebody thinks there is still an issue here...

Show
Daryl Herzmann added a comment - 01/07/10 01:15 AM Closing issue for now, can reopen if somebody thinks there is still an issue here...

People

Dates

  • Created:
    09/25/05 05:46 AM
    Updated:
    01/07/10 01:15 AM
    Resolved:
    01/07/10 01:15 AM
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for igniterealtime.org. Try JIRA - bug tracking software for your team.