DNS / resolveSrv help

[Joshua Cohen]

I'm trying to resolve an internal host using an SRV record, but it doesn't seem to be cooperating. I can resolve the record just fine from the command line:

$ host -t SRV _someInternalSrvRecord._tcp

_someInternalSrvRecord._tcp.mysearchdomain.com has SRV record 0 0 2181 some01.fqdn.com

_someInternalSrvRecord._tcp.mysearchdomain.com has SRV record 0 0 2181 some02.fqdn.com

_someInternalSrvRecord._tcp.mysearchdomain.com has SRV record 0 0 2181 some03.fqdn.com

But when I try to resolve via node, it doesn't work:

var dns = require("dns");

dns.resolveSrv("_someInternalSrvRecord._tcp", function(err, data) {

    if (err) {

        console.log("ERR! %j", err);

    } else {

        console.log("RESOLVED: %j", data);

    }

});

$ node srv.js
ERR! {"stack":"Error: ENOTFOUND, Domain name not found\n    at IOWatcher.callback (dns.js:74:15)","message":"ENOTFOUND, Domain name not found","errno":4,"code":"ENOTFOUND"}

Has anyone used node to successfully perform SRV resolution? If so, is there something obvious I'm missing here?

Thanks!

Joshua

[Ben Noordhuis]

Works for me with the current master. Below is what a query for
_jabber._tcp.google.com prints:

RESOLVED: [{"priority":20,"weight":0,"port":5269,"name":"xmpp-server4.l.google.com"},{"priority":20,"weight":0,"port":5269,"name":"xmpp-server3.l.google.com"},{"priority":20,"weight":0,"port":5269,"name":"xmpp-server1.l.google.com"},{"priority":5,"weight":0,"port":5269,"name":"xmpp-server.l.google.com"},{"priority":20,"weight":0,"port":5269,"name":"xmpp-server2.l.google.com"}]

[Joshua Cohen]

Hmm, interesting. If I add our search domain directly to the domain I'm looking up it works, but without it fails (i.e. _someInternalSrvRecord._tcp.mysearchdomain.com works but _someInternalSrvRecord._tcp fails). I'm unfortunately not familiar enough with ares or with SRV resolution in general to speculate why that might be though. Will have to dig more...

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Matt]

Because raw DNS libraries don't do the same things that full-on resolvers do (which requires knowledge of, and reading, /etc/resolv.conf, and thus the equivalent on Windows too, which probably involves reading the registry or something nasty).

tl;dr: Always use the FQDN.

[Joshua Cohen]

We've got different search domains for QA vs Prod, so that's why in other stacks we rely on /etc/resolv.conf for the search domain. I can work with this though and just configure the search domain based on the environment and manually append it before resolving. Thanks for the clarification!

[dhruvbird]

Slightly unrelated, but I've pulled out some code from Astro's node-
xmpp and made it a library: https://github.com/dhruvbird/dns-srv

It basically handles connecting to any of the endpoints of a set of
SRV records so that you don't have to manually cycle through them to
connect.

Usage:

var srv = require('dns-srv');
var net = require('net');

var sock = new net.Stream();
srv.connect(sock, ['_xmpp-client._tcp'], "gmail.com", 5222);

sock.on('error', function() { console.error('meh...'); })
.on('connect', function() { console.log('yeah baby!!'); });


Regards,
-Dhruv.

On Jun 21, 8:09 am, Joshua Cohen <defea...@gmail.com> wrote:
> We've got different search domains for QA vs Prod, so that's why in other
> stacks we rely on /etc/resolv.conf for the search domain. I can work with
> this though and just configure the search domain based on the environment
> and manually append it before resolving. Thanks for the clarification!
>
>
>
>
>
>
>
> On Mon, Jun 20, 2011 at 8:44 PM, Matt <hel...@gmail.com> wrote:
> > Because raw DNS libraries don't do the same things that full-on resolvers
> > do (which requires knowledge of, and reading, /etc/resolv.conf, and thus the
> > equivalent on Windows too, which probably involves reading the registry or
> > something nasty).
>
> > tl;dr: Always use the FQDN.
>

> > On Mon, Jun 20, 2011 at 9:17 PM, Joshua Cohen <defea...@gmail.com> wrote:
>
> >> Hmm, interesting. If I add our search domain directly to the domain I'm
> >> looking up it works, but without it fails (i.e. _someInternalSrvRecord._
> >> tcp.mysearchdomain.com works but _someInternalSrvRecord._tcp fails). I'm
> >> unfortunately not familiar enough with ares or with SRV resolution in
> >> general to speculate why that might be though. Will have to dig more...
>

> >> On Mon, Jun 20, 2011 at 8:01 PM, Ben Noordhuis <i...@bnoordhuis.nl>wrote: