Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-2474

proton with cyrus-sasl queries DNS for short hostname

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Open
    • Major
    • Resolution: Unresolved
    • proton-c-0.35.0
    • None
    • python-binding
    • None

    Description

      My python-qpid-proton 0.35.0 client hangs for about four seconds on every new connection operation to my broker. The problem is that the client tries to look up its own hostname's A and AAAA DNS records before completing the SASL exchange (and my DNS server takes a while for missing records.)

      Steps to reproduce:

      1. Set up a CentOS 8 or 9 host.
      2. Install cyrus-sasl-devel
      3. Install python-qpid-proton. Ensure it's dynamically linked to cyrus-sasl (/lib64/libsasl2.so.3).
      4. Ensure the unqualified (short) hostname from the "hostname" command is not present in /etc/hosts.
      5. Connect to a broker with ANONYMOUS SASL and no SSL.

      Actual results:
      Immediately after Proton receives the sasl.mechanisms message, but before Proton sends the sasl.init / sasl.outcome AMQP messages, it makes two DNS queries (A and AAAA) for my host's unqualified hostname.

      The AAAA request takes a while to answer (3.5 seconds). This makes makes the pn_transport_push() call hang here:

      -> exec(cmd, globals, locals)
        <string>(1)<module>()
        /home/vagrant/dns.py(51)<module>()
      -> Container(HelloWorld()).run()
        /usr/lib64/python3.6/site-packages/proton/_reactor.py(180)run()
      -> while self.process():
        /usr/lib64/python3.6/site-packages/proton/_reactor.py(245)process()
      -> event.dispatch(self._global_handler)
        /usr/lib64/python3.6/site-packages/proton/_events.py(162)dispatch()
      -> _dispatch(handler, type.method, self)
        /usr/lib64/python3.6/site-packages/proton/_events.py(125)_dispatch()
      -> handler.on_unhandled(method, *args)
        /usr/lib64/python3.6/site-packages/proton/_reactor.py(876)on_unhandled()
      -> event.dispatch(self.base)
        /usr/lib64/python3.6/site-packages/proton/_events.py(162)dispatch()
      -> _dispatch(handler, type.method, self)
        /usr/lib64/python3.6/site-packages/proton/_events.py(123)_dispatch()
      -> m(*args)
        /usr/lib64/python3.6/site-packages/proton/_handlers.py(1241)on_selectable_readable()
      -> n = t.push(b)
        /usr/lib64/python3.6/site-packages/proton/_transport.py(304)push()
      -> n = self._check(pn_transport_push(self._impl, binary))
      

      Expected Results:

      proton with cyrus-sasl should behave the same way it does without cyrus-sasl: it should authenticate quickly, without looking up the IP address of its own short hostname.

      Extra information:

      This only happens when I build against cyrus-sasl-devel. When I do not have cyrus-sasl-devel available, then the package from PyPI does not link against cyrus-sasl, and there is no DNS request. (The qpid-proton package in EPEL is built against cyrus-sasl, and that  is where I discovered this bug.)

      If the client can resolve its unqualified (short) hostname to an IP, then there is no delay. For example, if my Proton client's hostname is myclient.example.com, I can fix the delay by adding the following entry to /etc/hosts:

      127.0.0.1   myclient localhost
      

      or by ensuring my DNS server will immediately return A or AAAA records for the unqualified "myclient" name.

      Attachments

        Activity

          People

            Unassigned Unassigned
            ktdreyer Ken Dreyer
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: