James Server
  1. James Server
  2. JAMES-302

Functionality of org.apache.james.dnsserver.DNSServer.getByName(String) is not symetric to java.net.InetAddress.getByName(String)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.0, 2.3.0, 2.3.1, 2.3.2
    • Fix Version/s: 3.0-M2
    • Component/s: DNSServer
    • Labels:
      None
    • Environment:
      Tested on WIN2000, JDK 1.4.1_01-b01

      Description

      org.apache.james.dnsserver.DNSServer.getByName(String) does not always return the same result as java.net.InetAddress.getByName(address). Sometimes an exception is thrown when the standard implementation does not.

      When passed a fully qualified domain name the results are the same. When passed a hostname or the special name 'localhost', a java.net.UnknownHostException is thrown by org.apache.james.dnsserver.DNSServer while java.net.InetAddress resolves the addresses correctly.

      This is a critical issue as in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), but in the noted circumstances it doesn't perform the same. Dependent code breaks.

      Here are the contrasting examples...

      // FAILS
      String address = "localhost";
      java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
      return inetAddress;

      // FAILS
      String address = "hostname";
      java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
      return inetAddress;

      // SUCCEEDS
      String address = "localhost";
      java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
      return inetAddress;

      // SUCCEEDS
      String address = "hostname";
      java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
      return inetAddress;

        Issue Links

          Activity

          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12566739 ] jira [ 12581746 ]
          Mark Thomas made changes -
          Workflow jira [ 32035 ] Default workflow, editable Closed status [ 12566739 ]
          Norman Maurer made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Norman Maurer added a comment -

          Eric documented how it work, so close it

          Show
          Norman Maurer added a comment - Eric documented how it work, so close it
          Hide
          Norman Maurer added a comment -

          +1!

          Show
          Norman Maurer added a comment - +1!
          Hide
          Eric Charles added a comment -

          http://svn.apache.org/viewvc?rev=1031509&view=rev

          Javadoc of the DNSService API updated to reflect the non-symetric behaviour.

          Can be closed if OK for everyone.

          Show
          Eric Charles added a comment - http://svn.apache.org/viewvc?rev=1031509&view=rev Javadoc of the DNSService API updated to reflect the non-symetric behaviour. Can be closed if OK for everyone.
          Norman Maurer made changes -
          Fix Version/s 3.0-M2 [ 12315479 ]
          Fix Version/s 3.0 [ 10427 ]
          Affects Version/s 2.3.2 [ 12312493 ]
          Affects Version/s 2.3.1 [ 12312465 ]
          Affects Version/s 2.3.0 [ 12312103 ]
          Affects Version/s 2.2.0 [ 10747 ]
          Affects Version/s 3.0 [ 10427 ]
          Hide
          Norman Maurer added a comment -

          Let us fix this before 3.0-M2

          Show
          Norman Maurer added a comment - Let us fix this before 3.0-M2
          sravan made changes -
          Link This issue is duplicated by JAMES-795 [ JAMES-795 ]
          Stefano Bagnara made changes -
          Assignee Norman Maurer [ norman ]
          Hide
          Stefano Bagnara added a comment -

          Just to remember Norman a thing :-P

          Show
          Stefano Bagnara added a comment - Just to remember Norman a thing :-P
          Alan Cabrera made changes -
          Link This issue is duplicated by JAMES-345 [ JAMES-345 ]
          Alan Cabrera made changes -
          Link This issue is duplicated by JAMES-345 [ JAMES-345 ]
          Hide
          davide.bz added a comment -

          I unsuccessully try to use fetchmail ...

          I have downloaded the source code and debug ...

          The problem was an unknow host exception ....

          The problem by me is with localhost. In MessageProcessor there is a line:

          // Default is "localhost"
          if (domainBuffer.length() == 0)
          domainBuffer.append("localhost");

          Then at method

          protected String computeRemoteAddress()

          the

          validatedAddress = org.apache.james.dnsserver.DNSServer.getByName(address).getHostAddress();

          will throw an exception !!!!!
          I note because my dns does not resolve localhost !!! How to escape this?

          I have added this code and now work:

          if (address.equals("localhost"))
          validatedAddress = "127.0.0.1";
          else
          validatedAddress = org.apache.james.dnsserver.DNSServer.getByName(address).getHostAddress();

          Show
          davide.bz added a comment - I unsuccessully try to use fetchmail ... I have downloaded the source code and debug ... The problem was an unknow host exception .... The problem by me is with localhost. In MessageProcessor there is a line: // Default is "localhost" if (domainBuffer.length() == 0) domainBuffer.append("localhost"); Then at method protected String computeRemoteAddress() the validatedAddress = org.apache.james.dnsserver.DNSServer.getByName(address).getHostAddress(); will throw an exception !!!!! I note because my dns does not resolve localhost !!! How to escape this? I have added this code and now work: if (address.equals("localhost")) validatedAddress = "127.0.0.1"; else validatedAddress = org.apache.james.dnsserver.DNSServer.getByName(address).getHostAddress();
          Norman Maurer made changes -
          Fix Version/s 3.0 [ 10427 ]
          Fix Version/s 2.4.0 [ 12311645 ]
          Stefano Bagnara made changes -
          Fix Version/s 2.4.0 [ 12311645 ]
          Affects Version/s 2.4.0 [ 12311645 ]
          Affects Version/s 2.2.0 [ 10747 ]
          Fix Version/s 2.3.0 [ 12310796 ]
          Hide
          Stefano Bagnara added a comment -

          We voted to move this out from our 2.3 roadmap

          Show
          Stefano Bagnara added a comment - We voted to move this out from our 2.3 roadmap
          Stefano Bagnara made changes -
          Fix Version/s 2.3.0 [ 12310796 ]
          Fix Version/s 2.3.0a1 [ 10690 ]
          Hide
          Danny Angus added a comment -

          "I seem to remember reading in some RFC that mail should always rely on DNS information and should not be delivered base on local host tables"

          For SMTP this is largely correct, SMTP mail hosts may differ widely from other domain hosts and it is the MX records that mail is principally interested in.

          However resolving IP addresses isn't quite the same thing, and may be required in James for other things, such as IP or hostname black/white lists or resolution of hosts for conectionsto other services/protocols.

          I think the crux of the matter is in the classnames though, dnsserver.DNSServer.getByName() clearly implies that the lookup will be resolved by DNS not by refrence to /etc/hosts

          Lets be clear about what behaviour we want here, and why.

          Why "in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), " in the first place?

          Show
          Danny Angus added a comment - "I seem to remember reading in some RFC that mail should always rely on DNS information and should not be delivered base on local host tables" For SMTP this is largely correct, SMTP mail hosts may differ widely from other domain hosts and it is the MX records that mail is principally interested in. However resolving IP addresses isn't quite the same thing, and may be required in James for other things, such as IP or hostname black/white lists or resolution of hosts for conectionsto other services/protocols. I think the crux of the matter is in the classnames though, dnsserver.DNSServer.getByName() clearly implies that the lookup will be resolved by DNS not by refrence to /etc/hosts Lets be clear about what behaviour we want here, and why. Why "in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), " in the first place?
          Hide
          Arjan Veenstra added a comment -

          The issue is not specific for localhost. localhost is by no means a special name, but is normally declared as 127.0.0.1 in the OS host file. Some testing here (on a linux machine) shows that java.net.InetAddress.getByName returns addresses specified in the host file, while DNSJava does not.
          When I remove the localhost line in the host file java.net.InetAddress.getByName will no longer 'resolve' localhost. When I add other lines and they will be 'resolved' by java.net.InetAddress.getByName, but not by DNSJava.

          Hostnames within the local domain (as declared in /etc/resolv.conf) are correctly resolved by DNSJava overhere. My guess whould be that DNSJava is unable to determine the localdomain on (your?) windows machine.

          I seem to remember reading in some RFC that mail should always rely on DNS information and should not be delivered base on local host tables, so the DNSJava behaviour might just be more correct, at least when it comes to mail delivery. (And, sadly, pretty inconvenient in most other situations.)

          Show
          Arjan Veenstra added a comment - The issue is not specific for localhost. localhost is by no means a special name, but is normally declared as 127.0.0.1 in the OS host file. Some testing here (on a linux machine) shows that java.net.InetAddress.getByName returns addresses specified in the host file, while DNSJava does not. When I remove the localhost line in the host file java.net.InetAddress.getByName will no longer 'resolve' localhost. When I add other lines and they will be 'resolved' by java.net.InetAddress.getByName, but not by DNSJava. Hostnames within the local domain (as declared in /etc/resolv.conf) are correctly resolved by DNSJava overhere. My guess whould be that DNSJava is unable to determine the localdomain on (your?) windows machine. I seem to remember reading in some RFC that mail should always rely on DNS information and should not be delivered base on local host tables, so the DNSJava behaviour might just be more correct, at least when it comes to mail delivery. (And, sadly, pretty inconvenient in most other situations.)
          Hide
          Stefano Bagnara added a comment -

          I've tested dnsjava2 and it works like the previous 1.6.
          getByName("localhost") throw the UnknownHostException.

          Show
          Stefano Bagnara added a comment - I've tested dnsjava2 and it works like the previous 1.6. getByName("localhost") throw the UnknownHostException.
          Steve Brewin made changes -
          Priority Critical [ 2 ] Minor [ 4 ]
          Steve Brewin made changes -
          Status Resolved [ 5 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Hide
          Steve Brewin added a comment -

          Whilst fetchmail patches have worked around this issue, the issue still remains.

          It is no longer critical until the next time we stumble and expect that our DNSServer code responds in the same way as java.net code on simple queries, which I believe it should.

          The problem boils down to our DNS code not treating 'localhost' as special, whereas the java.net code and most other similar implementations do.

          As I recall, the expectation was that the underlying DNSJava code would fix this. Maybe release 2.0 does. I havn't had time to check.

          Until we can confirm that we are 'symetric', I would rather keep this open as a reminder.

          Show
          Steve Brewin added a comment - Whilst fetchmail patches have worked around this issue, the issue still remains. It is no longer critical until the next time we stumble and expect that our DNSServer code responds in the same way as java.net code on simple queries, which I believe it should. The problem boils down to our DNS code not treating 'localhost' as special, whereas the java.net code and most other similar implementations do. As I recall, the expectation was that the underlying DNSJava code would fix this. Maybe release 2.0 does. I havn't had time to check. Until we can confirm that we are 'symetric', I would rather keep this open as a reminder.
          Stefano Bagnara made changes -
          Fix Version/s 2.1.3 [ 10599 ]
          Fix Version/s 2.3.0 [ 10690 ]
          Description org.apache.james.dnsserver.DNSServer.getByName(String) does not always return the same result as java.net.InetAddress.getByName(address). Sometimes an exception is thrown when the standard implementation does not.

          When passed a fully qualified domain name the results are the same. When passed a hostname or the special name 'localhost', a java.net.UnknownHostException is thrown by org.apache.james.dnsserver.DNSServer while java.net.InetAddress resolves the addresses correctly.

          This is a critical issue as in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), but in the noted circumstances it doesn't perform the same. Dependent code breaks.

          Here are the contrasting examples...

          // FAILS
          String address = "localhost";
          java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
          return inetAddress;

          // FAILS
          String address = "hostname";
          java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
          return inetAddress;

          // SUCCEEDS
          String address = "localhost";
          java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
          return inetAddress;

          // SUCCEEDS
          String address = "hostname";
          java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
          return inetAddress;
          org.apache.james.dnsserver.DNSServer.getByName(String) does not always return the same result as java.net.InetAddress.getByName(address). Sometimes an exception is thrown when the standard implementation does not.

          When passed a fully qualified domain name the results are the same. When passed a hostname or the special name 'localhost', a java.net.UnknownHostException is thrown by org.apache.james.dnsserver.DNSServer while java.net.InetAddress resolves the addresses correctly.

          This is a critical issue as in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), but in the noted circumstances it doesn't perform the same. Dependent code breaks.

          Here are the contrasting examples...

          // FAILS
          String address = "localhost";
          java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
          return inetAddress;

          // FAILS
          String address = "hostname";
          java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address);
          return inetAddress;

          // SUCCEEDS
          String address = "localhost";
          java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
          return inetAddress;

          // SUCCEEDS
          String address = "hostname";
          java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address);
          return inetAddress;
          Stefano Bagnara made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Fix Version/s 2.1.3 [ 10599 ]
          Hide
          Stefano Bagnara added a comment -

          From the Steve comment I understand this issue is resolved.

          Show
          Stefano Bagnara added a comment - From the Steve comment I understand this issue is resolved.
          Steve Brewin made changes -
          Link This issue is duplicated by JAMES-345 [ JAMES-345 ]
          Hide
          Steve Brewin added a comment -

          Fix is in James 2.1.1 RC1

          Show
          Steve Brewin added a comment - Fix is in James 2.1.1 RC1
          Steve Brewin made changes -
          Link This issue is depended upon by JAMES-300 [ JAMES-300 ]
          Hide
          Steve Brewin added a comment -

          Maybe stating the obvious, but in the code examples "localhost" is literal while "hostname" is symbolic.

          Replace "hostname" by a valid hostname within your local domain. For instance, a hostname of "james" should work within the local domain of "apache.org" just as well as the fully qualified name "james.apache.org".

          Show
          Steve Brewin added a comment - Maybe stating the obvious, but in the code examples "localhost" is literal while "hostname" is symbolic. Replace "hostname" by a valid hostname within your local domain. For instance, a hostname of "james" should work within the local domain of "apache.org" just as well as the fully qualified name "james.apache.org".
          Steve Brewin made changes -
          Field Original Value New Value
          Link This issue is depended upon by JAMES-300 [ JAMES-300 ]
          Hide
          Steve Brewin added a comment -

          There is a general issue with the way that 'localhost' is being resolved in this release, as per the link.

          Show
          Steve Brewin added a comment - There is a general issue with the way that 'localhost' is being resolved in this release, as per the link.
          Steve Brewin created issue -

            People

            • Assignee:
              Norman Maurer
              Reporter:
              Steve Brewin
            • Votes:
              3 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development