Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Whois::ConnectionError: Errno::ECONNREFUSED #221

KaibinHuang opened this Issue · 6 comments

3 participants


Hi, everyone. I've got an issue.

irb(main):001:0> gem 'whois','3.0.0'; require 'whois'
=> true
=> "#\n# Query terms are ambiguous.  The query is assumed to be:\n#     \"n\"\n#\n# Use \"?\" to get help.\n#\n\n#\n# The following results may also be obtained via:\n#;q=\n#\n\nNetRange: -\nCIDR: \nOriginAS:       AS6472\nNetName:        NET-207-126-64-0-1\nNetHandle:      NET-207-126-64-0-1\nParent:         NET-207-0-0-0-0\nNetType:        Direct Allocation\nRegDate:        1996-05-17\nUpdated:        2010-01-19\nRef:  \n\nOrgName:        Net Asset\nOrgId:          NAST\nAddress:        8553 N. Beach St.\nCity:           Fort Worth\nStateProv:      TX\nPostalCode:     76244\nCountry:        US\nRegDate:        1996-04-25\nUpdated:        2011-09-24\nRef:  \n\nReferralServer: rwhois://\n\nOrgTechHandle: ZN22-ARIN\nOrgTechName:   Hostmaster\nOrgTechPhone:  +1-866-945-5582 \nOrgTechEmail:\nOrgTechRef:\n\nOrgAbuseHandle: ZN22-ARIN\nOrgAbuseName:   Hostmaster\nOrgAbusePhone:  +1-866-945-5582 \nOrgAbuseEmail:\nOrgAbuseRef:\n\nRTechHandle: ZN22-ARIN\nRTechName:   Hostmaster\nRTechPhone:  +1-866-945-5582 \nRTechEmail:\nRTechRef:\n\nRAbuseHandle: ZN22-ARIN\nRAbuseName:   Hostmaster\nRAbusePhone:  +1-866-945-5582 \nRAbuseEmail:\nRAbuseRef:\n\nRNOCHandle: ZN22-ARIN\nRNOCName:   Hostmaster\nRNOCPhone:  +1-866-945-5582 \nRNOCEmail:\nRNOCRef:\n\n#\n# ARIN WHOIS data and services are subject to the Terms of Use\n# available at:\n#\n\n"

But in version 3.1.1, same code fails for 'Connection refused'

irb(main):001:0> gem 'whois','3.1.1'; require 'whois'
=> true
Whois::ConnectionError: Errno::ECONNREFUSED: Connection refused - Connection refused
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/socket_handler.rb:40:in `call'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/adapters/base.rb:175:in `query'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/adapters/arin.rb:33:in `request'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/adapters/base.rb:107:in `lookup'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/adapters/base.rb:143:in `buffer_start'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/server/adapters/base.rb:106:in `lookup'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/client.rb:94:in `lookup'
    from org/jruby/ext/timeout/ `timeout'
    from /home/hkb/.rvm/gems/jruby-1.7.3/gems/whois-3.1.1/lib/whois/client.rb:91:in `lookup'
    from (irb):2:in `evaluate'
    from org/jruby/ `eval'
    from org/jruby/ `loop'
    from org/jruby/ `catch'
    from org/jruby/ `catch'
    from /home/hkb/.rvm/rubies/jruby-1.7.3/bin/irb:13:in `(root)'

I've tried several other ip addresses. 'Whois' works fine for them.
Could anyone figure out where goes wrong?
Thanks in advance.


I believe this is related to #220. @linrock, any chance you can check this issue?


@weppos Sure, I'll take a look.


I found the problem. The reason this happens is because ARIN queries are attempting to follow referrals as of 3.1.0, but errors while connecting to referral servers aren't handled.

In this particular case, the initial lookup succeeds, but the connection refused error happens when the client attempts to connect to the referral whois server

This issue can be fixed by handling errors when attempting to connect to bad referral servers. For example, wrapping lines 34 and 35 in with a begin/rescue block is a quick fix to silently ignore the failed referral query.

Either way, bad referral servers shouldn't cause the entire query to fail. In this case, debian whois returns the result of the initial lookup and shows an error for the referral query. Maybe there's a good way to do that here as well?


Thanks for looking into this.

I faced the same issue before when dealing with thin registries and it is commented in #186.
So far, I've never handled the issue. I decided to add support for non deep queries (#112) but apart from this there is no progress on the referral error handling.

The way followed by the debian whois is somehow opinionable. I think it's a good approach in that case because it's a CLI library and less content is better than no content at all.

I'm not sure the same approach will be equally good applied to this library. As I said in #112, I was considering to add some kind of error handling, but I haven't really find a good balance so far.

I'm open to suggestions.


Maybe a starting point is to re-raise a Whois::ReferralServerError for failed referral queries rather than just using Whois::ConnectionError? That would at least make it clear that the referral query is failing, and not the initial query. It could also use a nested exception to reference the original error, as you suggested.

I do also think it'd be nice to have an option where the query would just return the partial response and ignore failed referral queries.


Duplicates #186

@weppos weppos closed this
@weppos weppos added the enhancement label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.