Technicolor TG582n FTTC DNS resolution issues?

[#1]

Hi,
I appear to be having some name resolution issues which I spotted with my own mail server I run on a Synology NAS box. The server (based on Postfix) does reverse DNS checks as an anti-spam measure, and checking the mailogs recently when I was suspicious of some expected mail not arriving I'm getting entries with failed DNS lookup like this...

Oct 22 15:24:11 server postfix/smtpd[12267]: warning: hostname lux.smtp-out.eu-west-1.amazonses.com does not resolve to address 176.32.127.137: Name or service not known
Oct 22 15:24:11 server postfix/smtpd[12267]: connect from unknown[176.32.127.137]
Oct 22 15:24:11 server postfix/smtpd[12267]: lost connection after CONNECT from unknown[176.32.127.137]
Oct 22 15:24:11 server postfix/smtpd[12267]: disconnect from unknown[176.32.127.137]

In this particular case I'm missing some expected mail from Amazon.
On my LAN, on any box, if I run nslookup on the hostname, it just sits there and then times out...

nslookup lux.smtp-out.eu-west-1.amazonses.com
Server:  dsldevice.lan
Address:  192.168.1.254
*** dsldevice.lan can't find lux.smtp-out.eu-west-1.amazonses.com: Unspecified error

If however I explicitly specify a plusnet DNS server in nslookup, it resolves fine.
e.g.

nslookup lux.smtp-out.eu-west-1.amazonses.com 212.159.13.49
Server:  cdns01.plus.net
Address:  212.159.13.49
Non-authoritative answer:
Name:    lux.smtp-out.eu-west-1.amazonses.com
Addresses:  176.32.127.200
          176.32.127.203
          176.32.127.201
          176.32.127.137
          176.32.127.202
          176.32.127.139
          176.32.127.205
          176.32.127.138
          176.32.127.140
          176.32.127.204
          176.32.127.136
          176.32.127.141
          176.32.127.143
          176.32.127.206
          176.32.127.142
          176.32.127.207

Looking at the router, the DNS servers are 212.159.6.10 & 212.159.6.9
If I manually nslookup with these, again it resolves fine.
Then more oddly, if I log into the router CLI and nslookup from there, it also works fine...

{admin}=>dns client nslookup
host = lux.smtp-out.eu-west-1.amazonses.com
:dns client nslookup host=lux.smtp-out.eu-west-1.amazonses.com
Name:    lux.smtp-out.eu-west-1.amazonses.com
Address: 176.32.127.139
Type:    IP
         176.32.127.205
Type:    IP
         176.32.127.137
Type:    IP
         176.32.127.202
Type:    IP
         176.32.127.203
Type:    IP
         176.32.127.201
Type:    IP
         176.32.127.200
Type:    IP
         176.32.127.138
Type:    IP
         176.32.127.141
Type:    IP
         176.32.127.136
Type:    IP
         176.32.127.204
Type:    IP
         176.32.127.140
Type:    IP
         176.32.127.207
Type:    IP
         176.32.127.142
Type:    IP
         176.32.127.206
Type:    IP
         176.32.127.143
Type:    IP
Aliases: none

It only affects some addresses though. Vast majority of mail is getting through and reverse DNS is working. I don't really notice issues resolving hosts when browsing. It's just the odd few mail servers.
Any ideas? Maybe it's not the router, but then the router is the only device serving DNS for the LAN and all boxes on my LAN are configured automatically with the router IP address as DNS server (192.168.1.254) and all fail with the above hostname and a few others that should work.

[#2]

Can you provide some more examples of hostnames that don't resolve please?
The DNS answer for lux.smtp-out.eu-west-1.amazonses.com from Plusnet DNS is 575 bytes, so I was wondering if that has exceeded a packet size limit somewhere. Of course, if other hostnames that don't resolve have much shorter answers, then the packet size won't be the problem. The dig command line utility, or wireshark, can be used to see the length of the DNS answer data received.
Google DNS sent a shorter answer, Plusnet DNS sent 16 IP addresses and the details of 10 authoritative nameservers, Google DNS just sent the 16 IP addresses, and didn't send the additional details of the authoritative nameservers.

[#3]

I get a large list of warnings in the mail log but most are spammers / dynamic IPs and don't reverse resolve whatever DNS server I try, or they resolve but the mail server was rejecting because they didn't resolve to the claimed IP address, and that's fine as that's the stuff I expect to be rejected.
Ran a few scripts to test them out and found another example that should resolve though (although still this could be a spammer. Some Polish university it seems).
1lo.vlan327.nemes.lubman.net.pl - resolves to a long list of IP addresses, one of which is the one the mail server claims doesn't resolve, and if I just to nslookup on it, it times out, but nslookup explicitly against a PN DNS server and it does resolve and one of the IP addresses matches the one it claimed to be in the mail server log. The long list would also suggest an issue with large packet?

[#4]

Yes, 1lo.vlan327.nemes.lubman.net.pl is an exceptionally large 1239 byte DNS reply. Since the reply is mostly IP addresses and only 2 nameservers, it's still 1196 bytes from Google DNS.
I only thought of the length issue because I happened to test the DNS server in my really old netgear router (I don't normally use its DNS server). That couldn't properly handle the first example, and truncated the DNS reply data to 512 bytes. But the TG582n is not so old, and should be expected to work, or might eventually get a firmware update to fix this if we can confirm it and Plusnet report it to Technicolor.
Perhaps you could check the 582n system log, to see if there are any firewall or IDS log messages to suggest either of those components are somehow blocking the packets. The fact that the telnet cli on the router does resolve these hostnames, but your computers do not, suggests that parts of the DNS system in the firmware can handle these packets, yet somehow the answers don't get sent to or don't reach your computers.

[#5]

Should note I'm not on the latest firmware for the router. I've been asking elsewhere if it's worth updating, but more from a security point of view and it seemed it was not necessary. I tend to leave router firmware alone if it doesn't need updating (much like BIOS updates, especially having been stung by a bug in a couple of newer BIOS and couldn't roll back - one actually bricked a laptop).

Edit: checked the logs from the router (I've got them sending to my Synology log server) and there's nothing around these times. Syslog is set to 'info' level which is logging all except 'debug' level logs it seems.

[#6]

Probably worth updating, it may be fixed, although I didn't see it specifically listed in the release notes.
Or perhaps anyone else using a 582n with 10.2 firmware, with default DNS configuration, could test looking up either of the hostnames mentioned to check if it works.

[#7]

Don't have a technicolor running now but I've tried this with my own resolver:

Quote

C:\Users\npr>dig lux.smtp-out.eu-west-1.amazonses.com @127.0.0.1 ;; Truncated, retrying in TCP mode. ;; Connection to 127.0.0.1#53(127.0.0.1) for lux.smtp-out.eu-west-1.amazonses.com failed: connection refused.

Increase the buffer size from the default 512 to 1024

Quote

; <<>> DiG 9.8.6-P1 <<>> +bufsize=1024 lux.smtp-out.eu-west-1.amazonses.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3981 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;lux.smtp-out.eu-west-1.amazonses.com. IN A ;; ANSWER SECTION: lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.138 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.140 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.143 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.136 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.139 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.205 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.137 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.202 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.142 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.141 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.207 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.201 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.206 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.203 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.204 lux.smtp-out.eu-west-1.amazonses.com. 765 IN A  176.32.127.200 ;; Query time: 15 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Oct 24 22:27:20 GMT Summer Time 2015 ;; MSG SIZE  rcvd: 321

Strangely querying 8.8.8.8 works without increasing the buffer size yet gives the same answer size.
 
Correction: google dns gives a message size of 310.

[#8]

So what's the conclusion here? Is it that Plusnet's DNS returns a message size much greater.....oh hang on Google returned one of 1237 bytes for a different lookup, so it can't be that.  So is it something in the TG582n hardware or firmware that causes the problem?
Oh hang on again, doing some googling for people having problems with failed DNS lookups on Windows 8/8.1 reveals that there are other non-Technicolor routers with similar problems.  I wonder what the common factors are here, apart from Windows. Do they use similar hardware, do they all have a common firmware bug - does this buffer size theory hold any water? I don't know, I'm just asking questions.
And btw the 582n's with 10.2. firmware still have occasional DNS lookup failures but then it's not the only router I've used that seems to have that occasional problem.

[#9]

I'm going to take a wild guess that a Synology NAS box is not running Windows 8/8.1.

[#10]

Typical sarcastic response from you ejs and again no substantiated answers. Just in case you missed the point, since you chose to mention this thread in another recent post, was to point out the fact that there are other routers besides the 582n that suffer this problem of failed DNS lookups. It has nothing to do with a NAS not running Windows 8/8.1::)  it has everything to do with finding out that the 582n isn't the only one which seems to have a problem. But it seems you would just rather dismiss that idea as you did when you replied here and here to which I'll respond in due course.

[#11]

Have you considered the possibility that different routers each have their own different bugs, that happen to be in the same area of DNS? It might be simpler to concentrate on the 582n, rather than attempt to diagnose and fix every router in existence!

[#12]

Of course I have. But since I hadn't seen any evidence that clearly rules one thing or another in or out, I'm keeping my mind open. And who said one should "diagnose" every router in existence, what a silly remark. As one of the people who is supposedly more knowledgeable about routers, I would have hoped for something more constructive from you. In any case it would be far better to continue this in the other thread where it looks like you may have posted something more constructive about Windows 8.1 doing DNS lookups differently from previous OSes AND a bug in the Technicolor firmware.

[#13]

I actually also posted the same thing almost a year ago! https://community.plus.net/forum/index.php/topic,134916.msg1182288.html#msg1182288
But I guess I shouldn't bother posting any links to anything, because no-one clicks them and reads them? I should've just said that I've searched the Internet, and it turns out there is indeed a bug in the Technicolor firmware.

[#14]

So you did. As I said above, I'll continue to discuss the issue in this thread

[#15]

Deleted