GNOME Bugzilla – Bug 629274
GNetworkService does not do fallback when there is no SRV record
Last modified: 2010-10-28 19:23:27 UTC
Some XMPP servers incorrectly return a CNAME from SRV lookups, as shown in the dig output below. In particular, some people see similar behaviour from chat.facebook.com (in the case of Facebook it depends where on the Internet you are - I don't get this myself). g_socket_client_connect_to_service currently responds to this by failing with G_IO_ERROR_FAILED. We have a workaround in Wocky (telepathy-gabble's XMPP library) to catch this error and try resolving the domain as A or AAAA instead. From my reading of the RFC, it should quietly fall back to looking up the A or AAAA record for the desired domain, and using the port from /etc/services (which won't work for all services, but is enough for XMPP). For services that don't necessarily have a useful port number in /etc/services, it might be useful to provide a version of g_socket_client_connect_to_service that takes a default port number. Telepathy bug: https://bugs.freedesktop.org/show_bug.cgi?id=28051 The relevant section of <http://tools.ietf.org/html/rfc2782>: A SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one: Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, QTYPE=SRV. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR which specifies the requested Service and Protocol in the reply: [some stuff] else Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A for each address record found, try to connect to the (protocol, address, service) ---------------------------------- dig output: smcv@reptile% dig -t SRV _xmpp-client._tcp.jabber.rwth-aachen.de ; <<>> DiG 9.7.1-P2 <<>> -t SRV _xmpp-client._tcp.jabber.rwth-aachen.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43224 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_xmpp-client._tcp.jabber.rwth-aachen.de. IN SRV ;; ANSWER SECTION: _xmpp-client._tcp.jabber.rwth-aachen.de. 168111 IN CNAME vm01.jabber.rwth-aachen.de. ;; AUTHORITY SECTION: rwth-aachen.de. 10800 IN SOA zs1.rz.rwth-aachen.de. hostmaster.rwth-aachen.de. 2010091008 43200 7200 1814400 10800 ;; Query time: 64 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Sep 10 14:39:53 2010 ;; MSG SIZE rcvd: 130
(In reply to comment #0) > From my reading of the RFC, it should quietly fall back "it" means GSocketClient here.
(In reply to comment #0) > g_socket_client_connect_to_service currently responds to this by failing with > G_IO_ERROR_FAILED Yeah, as you suggested in the telepathy bug, this is an additional bug on top of the failure-to-fallback. It probably ought to be G_RESOLVER_ERROR_NOT_FOUND. > From my reading of the RFC, it should quietly fall back to looking up the A or > AAAA record for the desired domain, and using the port from /etc/services > (which won't work for all services, but is enough for XMPP). Yup. This belongs in GNetworkService I think, not above (g_socket_client_connect_to_service) or below (g_resolver_lookup_service). > For services that > don't necessarily have a useful port number in /etc/services, it might be > useful to provide a version of g_socket_client_connect_to_service that takes a > default port number. And corresponding GNetworkService API. Less important for 2.26 though
Created attachment 170490 [details] [review] GNetworkService: fall back when there is no valid SRV record Hm... jabber.rwth-aachen.de seems to have gotten fixed, and BIND won't even let me configure an equivalently broken record to test against (it complains if I try to make an A or CNAME record containing a "_"). Do you have anywhere else to test this against?
ah well. committed. if it doesn't fix the problem for the original reporters then they'll eventually report it again and then we'll have a test case Attachment 170490 [details] pushed as e410131 - GNetworkService: fall back when there is no valid SRV record
(In reply to comment #3) > Hm... jabber.rwth-aachen.de seems to have gotten fixed, and BIND won't > even let me configure an equivalently broken record to test against > (it complains if I try to make an A or CNAME record containing a "_"). Sorry, I must have missed this comment earlier. I think the trick is to make a wildcard CNAME like this: badger.example.com. A 1.2.3.4 *.example.com. CNAME badger.example.com. and try to connect to XMPP with JID me@jabber.example.com?
ok, after playing around with adding wildcard CNAMEs to non-existent hostnames, I realized that all you need to do is test against a domain that just doesn't have a SRV record at all: danw@desktop:tests (master)> ./resolver xmpp-client/tcp/example.com Service: xmpp-client/tcp/example.com Error: No service record for '_xmpp-client._tcp.example.com' danw@desktop:tests (master)> ./resolver -c xmpp-client/tcp/example.com Address: 192.0.32.10:5222 Address: [2620:0:2d0:200::10]:5222 The first example, using GResolver directly, fails. The second example, using GSocketConnectable, now falls back to using the domain, as it's supposed to. (There was a small bug in the synchronous GSocketConnectable case for GNetworkService, which is now fixed.)