DNS - Query failure 9560

[superman20]

Under what circumstances would hMailServer return the following error:

Code: Select all

DNS - Query failure. Treating as temporary failure. Query: 145.128/26.22.121.128.in-addr.arpa, Type: 12, DnsQuery return value: 9560.
Could not retrieve PTR record for IP (false)! 128.121.22.145

Except for IP's that aren't actually resolvable, I only ever see this for the IP above. I run my own local caching DNS server. When I query for that IP directly from my own DNS server it always resolves to the correct name. If the error code follows the Win32 error codes, then 9560 means "DNS name contains an invalid character". I assume it's upset about the forward slash (??), but the 3 DNS servers I tested seemed OK with it. Here is the response from my own DNS Server:

Code: Select all

Response received from 127.0.0.1:

Authoritative response (AA): No
Recursion available (RA): Yes
Truncated (TC): No

Answer section:
CNAME-record for 145.22.121.128.in-addr.arpa:
    Alias for = 145.128/26.22.121.128.in-addr.arpa
    TTL = 81669 (22 hours, 41 minutes, 9 seconds)
PTR-record for 145.128/26.22.121.128.in-addr.arpa:
    Points to = ntt-5.lastpass.com
    TTL = 81670 (22 hours, 41 minutes, 10 seconds)

I'd appreciate any advice on this matter.

[Dravion]

Contact your Hostmaster or DNS-Server Admin of your domain and correct the wrong ptr entry in your reverse lookup zone.

[superman20]

Dravion, this is not my domain and I have no control over it. I am the Hostmaster and DNS-Server Admin of MY domains. Their entry is correct, technically...

It appears that the slash is indeed fine. It is possible to delegate "in-addr.arpa" authority for less than one class C network (256 IP addresses). See RFC 2317 (http://www.rfc-editor.org/rfc/rfc2317.txt). I think that perhaps hMailServer isn't handling this correctly.

[jimimaseye]

Are you able to fully reproduce this at will? Or do you receive from this server only occasionally?

If you have the control to perform further tests, could you please

1, do a test to prove the error still exists
2, then stop restart Hmailserver SERVICE
3, do the test again.

We know that there are strange buggettes regarding DNS lookups with HMS where it reports 'temporary query failures' despite the reality being that the lookups do actually still perform (its just the wording of the report back that is wrong) and the above test will prove whether this comes in to that category or whether it is physically failing.

[superman20]

This seems difficult to easily test since this happens doing the reverse lookup on the connecting IP. I'm open to suggestions if you have any ideas on how to test that.

I did search all my logs (for which I only keep 6 months of). I had 13 connections from this IP range and 100% of them have the resolution problem.

[superman20]

Let me also clarify that I have dozens of these types errors, but all of the other IP's that I have manually checked really do not have PTR records so the error is correct/proper.

[superman20]

Sorry for the multiple posts. I found some places where Windows wasn't showing correct search results. I downloaded a real search program (Agent Ransack). Using this tool, I actually found 474 hits for DNS Query 9560 failures that also have a "/" in the DNS record and follow the same format as RFC 2317 (and cover lots of IP ranges...not just the range I first mentioned). I'm really starting to convince myself that hMailServer has a problem with these kinds of records.

Incidentally, I also found this error 36 times for domains that really had illegal characters.

[Dravion]

Hmm, OK Superman20...
It looks like you doing some DNS things on you private computers host file instead of using a real DNS-Server or you are using some crappy Hobby DNS-Server because you using your local loopback interface (127.0.0.1) as DNS-Server which doenst is an AUTHORITATIVE DNS-Server at all

i am the Hostmaster and DNS-Server Admin of MY domains

... well, then this must be your domain because
no one can query your DNS-Server from outside because it is running on you local loopback adapter (127.0.0.1)

Howto fix this:
First install A REALDNS-Serversoftware (like Bind) (its avaiable for Windows to, dont use MS-DNS, its crap to) and read the ISC ARM-Manuals https://www.isc.org/downloads/bind/doc/bind-9-10/

A sane LAN-DNS-Response should look like this:

Code: Select all

dig -t MX  +nocmd incubator.net.projects +answer @ns1.incubator.net.projects

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27963
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;incubator.net.projects. IN MX

;; ANSWER SECTION:
incubator.net.projects. 3600 IN MX 10 mail.incubator.net.projects.
incubator.net.projects. 3600 IN MX 20 smtp.incubator.net.projects.

;; AUTHORITY SECTION:
incubator.net.projects. 3600 IN NS ns1.incubator.net.projects.

;; ADDITIONAL SECTION:
mail.incubator.net.projects. 3600 IN A 194.241.203.110
smtp.incubator.net.projects. 3600 IN A 194.241.203.161
ns1.incubator.net.projects. 3600 IN A 194.241.203.104

;; Query time: 0 msec
;; SERVER: 194.241.203.104#53(194.241.203.104)

[superman20]

Dravion,
I think you are confused about my situation. Like I stated before, I have a local caching DNS server whose sole purpose is to provide DNS lookups for hMailServer to speed up the mail analyzing process. It only listens on interface 127.0.0.1 because I don't want it to be authoritative for any domain or used outside of hMailServer. The problem here is that when an IP connects to my mail server to deliver mail and hMailServer does a reverse DNS lookup on that connected IP and it finds an "in-addr.arpa" delegation (which is perfectly legal according to RFC 2317), then it chokes. Note that my local DNS can actually resolve those IP's to names through the "in-addr.arpa" delegation but hMailServer cannot.

[jimimaseye]

Hi Supes......

the reason I was asking about doing the testing before was because we have demonstrated in the past the HMS has some oddities. In summary:

when doing DNSBL lookups it either finds a record which could mark it positive or negative (depending on the returne code given) or if the record deosnt exist it should also then return a negative. By and large this was ok. However, it has been noted that (especially in 5.6.4) some lookups start returning a 'dns query failure 11002 (I think)' in the logs instead of the more clean looking 'no record found'. In these cases it was easy to assume it was DNS failing but just like in your example doing a MANUAL lookup on the same dns server DOESNT return a query failure (the 'error' only happens in HMS). And stopping and restarting HMS simply stopped this happening and 'zero record' lookups started appearing in the log correctly again (even of the exact same message/addresses).

HOWEVER... I have since proven that despite these ugly 'dns query error' entries appearing in the logs suggesting that HMS isnt doing the lookup correctly, I have proved and convinced myself that actually the lookups ARE being performed correctly and where a record is to be found, it is found, and where no record is found then its just a wrong wording/phrasing being entered in the logs. In short, HMS is guilty of 'getting stuck' with its wording/handling of what is used to go in the log file BUT crucially it still does the lookups correctly (it just doesnt look like it does). Details here: viewtopic.php?p=180806#p180806

THIS is why I was asking about you reproducing the problem.

Now you have since gone on to say that you see MANY of your reported errors in your log files - many of which you say are genuine. I would like to know why you say they are genuine? I ask because I have NEVER seen this error and Im pretty sure that there are businesses out there that do not have PTR records.

My point is.....
...I strongly suspect that HMS is guilty of something buggy, yes, but just like the other query DNS problems I described above its more likely to be the 'sticky, incorrect wording' that is appearing in the log files rather than it actually not detecting records that otherwise are there to be detected and read.

In short: dont worry, its just a logging error and not an actual functionality error. Solution: Stop looking at your log files.

(p.s Martin has said that the problem I described above is fixed in the next release so your problem may also be fixed with the same patch). https://github.com/hmailserver/hmailserver/issues/133

[superman20]

jimimaseye,
Thanks for the response. I have read many of the DNS discussions on the forum. The forums have quite a few DNS threads and I believe there are several "problems" at play and this all leads to confusion as I believe they have different solutions. So, let me begin my rebuttal...

First, I want to disregard any discussion about DNSBL resolutions. I know those lookups aren't 100% reliable (no matter who does them) and while I have some of those errors as well, I typically don't pay much attention to them as they really seem temporary and don't necessarily follow a pattern of failure. If there is a bug there and Martin has fixed something there, then great...I look forward to that fix.

I really want to focus solely on the point where hMailServer does a reverse lookup on the connecting IP. The error message I get back from hMailServer isn't overly descriptive, but Win32 error code 9560 means "DNS name contains an invalid character" and that description is 100% consistent IF you believe that hMailServer does not like the forward slash in the "in-addr.arpa" delegation. The only other time I get error 9560 is when one of my users tries to send an email to a domain with illegal characters and then hMailServer will properly give this error when it does an MX lookup.

The other thing that really has me convinced is when I finally did a proper search of my log files and found 474 instances of these errors all associated with the same phenomenon...."in-addr.arpa" delegation, i.e., a forward slash in a CNAME record. I'm seeing lots of IP addresses setup this way so others MUST be seeing this as it seems to be a common configuration for larger businesses. I'm manually going through the logs now trying to find an example IP of this that would easy for you or Martin to replicate. Currently, I'm only finding lastpass, banks, and voip providers which really wouldn't be easy for you to setup a temporary account from them to get test e-mails from.

If you want a flavor of what these kinds of IP's return, then go to http://mxtoolbox.com/ReverseLookup.aspx and enter my original post IP of 128.121.22.145. You'll see that it resolves to a CNAME of "145.128/26.22.121.128.in-addr.arpa" and then you have to resolve that to the actual name of "ntt-5.lastpass.com". hMailServer clearly gets "145.128/26.22.121.128.in-addr.arpa" on the first part of the IP lookup but it seems to get stuck there and can't resolve that to its final destination of "ntt-5.lastpass.com".

I'll post back if I can find an IP that has this setup and would be easy for you to get mail from yourself.

[SorenR]

Short explanation....

Someone have been overly clever wrt. subnetting on their DNS...

It's perfectly legal, however before RFC 2181 only a "-" dash was legal...

dig -x 128.121.22.145

Code: Select all

C:\WINDOWS>dig -x 128.121.22.145

; <<>> DiG 9.9.8-P3 <<>> -x 128.121.22.145
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36890
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;145.22.121.128.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
145.22.121.128.in-addr.arpa. 9308 IN    CNAME   145.128/26.22.121.128.in-addr.arpa.
145.128/26.22.121.128.in-addr.arpa. 9308 IN PTR ntt-5.lastpass.com.

;; AUTHORITY SECTION:
128/26.22.121.128.in-addr.arpa. 9252 IN NS      NS0.LASTPASS.COM.
128/26.22.121.128.in-addr.arpa. 9252 IN NS      NS1.LASTPASS.COM.

;; Query time: 0 msec
;; SERVER: 192.168.0.50#53(192.168.0.50)
;; WHEN: Tue Apr 12 19:22:55 Romance Daylight Time 2016
;; MSG SIZE  rcvd: 161

DNS server is BIND running on my NAS.

[jimimaseye]

If there is a firm belief that HMS is at fault then you should log it in github (trying to explain and prove). https://github.com/hmailserver/hmailserver/issues/

[superman20]

I can do that but I feel like people aren't drinking the cool-aid like I am.

I've finished polling through all of my logged errors. Unfortunately, most of the IP's setup this way seem to be organizations where getting an account is non-trivial and most likely not free or bulk SMTP services and its unclear which company actual sent the mail. I did find 3 possible exceptions:
1) Email from IP 72.166.183.236 (cartwheel@e.target.com). So perhaps if you sign up to receive cartwheel notifications from Target, you'd get similar e-mails. I think cartwheel is their coupon service...but not sure.
2) My own VOIP provider (voip.ms) has this issue. So if someone is game, I can setup your e-mail address to receive my voice-mails (temporarily of course...unless you want to hear when my mother calls).
3) You can sign up for a lastpass account (free), but it appears from the logs that not all of their e-mail comes from an IP with this particular setup. It seems to be about 50/50.

Let me know if someone wants to try and independently replicate. If I have time, I might can go through the source code and pin down a more definitive reason why it's not working, but I may not have time for that in the near future due to work constraints.

[jimimaseye]

PM sent

[SorenR]

Further to the matter... Notice that "-" and "/" are interchangeable... I have substituted "-" with "/" in the quoted text for clarity.

ip address block math
Let's assume you have the situation of 5 usable addresses out of a block of 8. Your ISP tells you your block starts at a.b.c.82 and its used by your gateway (router). The math is fairly straightforward: if your ISP allocates IP block efficiently, which almost all do, then for a given subnet all addresses are allocated with the same block size. So if you have a block of 8, you share a subnet with 32 other customers who also have a range starting at something divisible by 8. In our example:

82 / 8 = 10 (integer division, no remainder)
10 * 8 (block size) = 80.

In our example, your IP block starts at a.b.c.80, not a.b.c.82 like the ISP said. This math will work the same for any IP address in your range, and if you have a larger block, such as "13 usable", or 16, you divide and multiply by 16 instead of 8.

block naming and network size
The block is important because there is a "best practice" for reverse DNS naming conventions. Not all ISPs abide by it, but it is how we setup your reverse DNS by default. We can handle just about any naming convention an ISP can throw at us, but we prefer to do things right if at all possible. The best-practice convention for classless reverse DNS naming of the IP address a.b.c.d is:
d.block address/network size.c.b.a.in-addr.arpa

In our example, that would be:
82.80/29.c.b.a.in-addr.arpa

Notice there are two components, the block start address, and the network size. Network size is very similar to a subnet mask, but is in fact different because it differentiates the size of your subnet. The table below lists sizes of various networks up to a full class "C". We can handle any size network including class "C". If you need services for a block larger than 128, contact support for custom pricing information.

More here: http://www.nettica.com/Articles.aspx?A=3

Now, where to put the blame... OS? Compiler? Included tool? - I haven't got the foggiest idea...

[jimimaseye]

I have just performed and confirmed by means of a test from the same email supplier Superman uses (the VOIP notification, example (2) in his last post):

Code: Select all

"SMTPD"	3532	101	"2016-04-12 20:31:02.741"	"107.6.67.234"	"SENT: 354 OK, send."
"TCPIP"	3532	"2016-04-12 20:31:03.068"	"DNS - Query failure. Treating as temporary failure. Query: 234.232/29.67.6.107.in-addr.arpa, Type: 12, DnsQuery return value: 9560."
"DEBUG"	3532	"2016-04-12 20:31:03.068"	"Could not retrieve PTR record for IP (false)! 107.6.67.234"

[jimimaseye]

Now, where to put the blame... OS? Compiler? Included tool? - I haven't got the foggiest idea...

Well, I guess it should start with Martin to see what he thinks.

[SorenR]

Now, where to put the blame... OS? Compiler? Included tool? - I haven't got the foggiest idea...

Well, I guess it should start with Martin to see what he thinks.

As far as I can see HMS is using DNSAPI.DLL from C:\Windows\System32 (yes, I'm on an old system) and most versions AFAICS support up to RFC 952.... We really like it to support as a minimum RFC 2181...

Anyways, if someone fancy a challenge I could suggest replacing the "/" in the search string with a "-" as it was used for quite some time before the "/" was introduced.

My OS is too old so I can't edit/compile a recent version of HMS... Search for "DNSAPI.DLL" and work your way backwards

[superman20]

OK...I'm going to get fired over this because I'm way behind at work now...but anyway....I took a quick peak at the code and I think I found the problem:

In the function

Code: Select all

DNSResolver::Resolve_

all of the records are properly returned from the OS API call...so no OS problem. However, in the loop trying to find the correct record the code explicitly looks for the in-addr.arpa IP in this line...

Code: Select all

if (pDnsRecord->wType == wType && sSearchFor.Equals(name))

So in my example, code is looking for "234.67.6.107.in-addr.arpa" as an exact string match but the DNS record returned actually has "234.232/29.67.6.107.in-addr.arpa". The code needs to detect and resolve the Class C delegation syntax so that "234.67.6.107.in-addr.arpa" == "234.232/29.67.6.107.in-addr.arpa" and then everything will be fine from there.

[jimimaseye]

Well done chaps.

Can you log this in github please and link to this thread and specifically these recent postings.

[superman20]

Done.

https://github.com/hmailserver/hmailserver/issues/157

Thanks!