[
https://issues.apache.org/jira/browse/PROTON-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458610#comment-17458610
]
Ken Dreyer commented on PROTON-2474:
------------------------------------
I've reproduced this independently of Proton, at
[https://github.com/cyrusimap/cyrus-sasl/issues/700]
Since Proton has its own SASL implementation that does not contact DNS, it
should be possible to make Cyrus stop querying DNS too.
> proton with cyrus-sasl queries DNS for short hostname
> -----------------------------------------------------
>
> Key: PROTON-2474
> URL: https://issues.apache.org/jira/browse/PROTON-2474
> Project: Qpid Proton
> Issue Type: New Feature
> Components: python-binding
> Affects Versions: proton-c-0.35.0
> Reporter: Ken Dreyer
> Priority: Major
>
> 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:*
> # Set up a CentOS 8 or 9 host.
> # Install cyrus-sasl-devel
> # Install python-qpid-proton. Ensure it's dynamically linked to cyrus-sasl
> ({{{}/lib64/libsasl2.so.3{}}}).
> # Ensure the unqualified (short) hostname from the "{{{}hostname{}}}"
> command is not present in {{{}/etc/hosts{}}}.
> # 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:
> {noformat}
> -> 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))
> {noformat}
> *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:
> {noformat}
> 127.0.0.1 myclient localhost
> {noformat}
> or by ensuring my DNS server will immediately return A or AAAA records for
> the unqualified "myclient" name.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
