DNS Query Refused
If you have reached this page because:
- your email bounced with a "Query Refused" message
- you received a TXT record response of "Query Refused. See http...
- you received an A record response of 127.0.0.1
- spamassassin is firing the URIBL_BLOCKED rule
Read below for more information...
"Query Refused" Explained
URIBL provides public lookups over DNS for low volume usage. If you spam check a large amount of email, or you use a shared DNS platform for resolution, you may receive a response saying the query was refused. That said, Public DNS providers such as OpenDNS or Google Public DNS are effected due to the high volume of queries they generate, as are many other internet service providers (ISP) that use caching nameservers for their customer base.
If you are unsure which DNS server is being blocked, a blocked TXT query from the effected device will indicate the IP address of the nameserver that is being blocked:
$ host -tTXT 126.96.36.199.multi.uribl.com
188.8.131.52.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 184.108.40.206]"
c:\> nslookup -q=txt 220.127.116.11.multi.uribl.com
18.104.22.168.multi.uribl.com text =
"127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 22.214.171.124]"
If an email you sent bounced, and included a link to this page, then it was rejected because the receiver has not implemented URIBL lookups correctly. URIBL uses bitmask responses to indicate a domain being listed. Our Implementation guidelines provide the bitmask responses. All queries that we refuse, we return a 127.0.0.1 response to, as bit 0x1 is not used for domain classification. SpamAssassin supports the 0x1 bitmask response, and provides a URIBL_BLOCKED rule which will fire if the query was refused by URIBL.
If you send a query to "black.uribl.com" and we deliver a 127.0.0.1 response back to that query, that is not a positive listing. Only 127.0.0.2 responses indicate a listing on black.uribl.com. Really you should be using multi.uribl.com for resolution, and doing proper bitmask checking. If your software does not support bitmask checking of the 4th octet, contact your software vendor, or stop using URIBL completely.
Low Volume Workaround?
If you are low volume user, you have a few options. Possibly changing your nameservers from a public dns provider (ie opendns/google) to your local ISP may solve it. If your local ISP is also effected because they are very large (ie cox/att/comcast/etc), you may need to use your own recursive DNS solution. If your company has DNS servers, point to them for resolution. Alternatively, you could setup a caching nameserver on the loopback of the machine doing the spam checking, and point the DNS to localhost.
For those that have no solution for the DNS workarounds listed above, we provide commercial Datafeed Service.
If you need more information regarding this issue, please contact the URIBL DNS Admin