Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've recently switched out a failed router... and, a while later, I discovered a lot (at least an order or magnitude more than the number of queries) of errors reported in /var/log/syslog - of the form:

Mar 18 19:53:20 kenneth named[4022]: DNS format error from 192.112.36.4#53 resolving ./NS: non-improving referral
Mar 18 19:53:20 kenneth named[4022]: error (FORMERR) resolving './NS/IN': 192.112.36.4#53

It might be relevant that I've got the following in bind.conf:

dnssec-enable no;
dnssec-validation no;

Is this likely an issue with the new router corrupting UDP datagrams, or something else? The new router is an (inexpensive) Netgear WNR854T - it has the latest firmware applied.

Can anyone suggest how best to diagnose this fault if it's not obvious from the above?

-- Additional details -- This is a typical response from dig for an address I'm sure should resolve.

$ dig A barclays.co.uk                                         ~

; <<>> DiG 9.8.1-P1 <<>> A barclays.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22161
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;barclays.co.uk.                        IN      A

;; Query time: 84 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 20 23:08:40 2013
;; MSG SIZE  rcvd: 32
$
share|improve this question
    
This always happen. It's just noise. To elaborate, unless your own server is misconfigured you're probably just hitting misconfigured servers of other people. –  gparent Mar 18 '13 at 20:12
    
To clarify further, are you saying that the root dns servers always generate DNS format errors in the log? They didn't do this for me when I last checked (several months and a few configuration changes ago, I admit.) –  aSteve Mar 18 '13 at 20:27
    
No, I'm saying that every single BIND server I've ever ran had these sorts of errors in the log, whether it used stock or customized configs. Other things you can see are "Unexpected RR code", "lame-servers" and other background noise. Of course if it's happening nearly every single time you query out, there's probably an issue on your end. –  gparent Mar 18 '13 at 20:39
    
I'm seeing, roughly, a dozen errors per DNS lookup. This isn't one-shot or a specific lookup. –  aSteve Mar 18 '13 at 23:26
    
Okay, that's not normal. Apologies if I misled you, I would update the question to make it very clear that you're getting multiple errors per query and not just "a lot of errors" over time. –  gparent Mar 18 '13 at 23:37
show 1 more comment

1 Answer

If you suspect a network element (such as your router) is truncating or corrupting UDP DNS traffic you can try the following:

  1. Perform the same query, again, with dig and see if you are also getting FORMERR as the response code. Dig (with the right options) will perform similarly to your recursing server but give you more visibility into the process.
  2. If you are getting FORMERRs with dig, try dig +tcp and see if the error persists (to rule out UDP issues)
  3. Use Wireshark or another sniffer to capture what is actually being received by your server when it recurses to satisfy a query.

Are all of the FORMERR errors in your log complaining about non-improving referrals? What does dig say is in the "additional" section of the queries that generate these error messages?

Finally, do you have stub zones or forward-first or forward-only zones set up that you haven't mentioned?

share|improve this answer
    
Many thanks for the reply... though, now, I'm even more confused. Dig behaves very weirdly. I tried 'dig A amazon.com –  aSteve Mar 20 '13 at 22:35
    
Unfortunately your comment appears to have been truncated. –  Michael McNally Mar 20 '13 at 22:40
    
-Continued...user-error (sorry)- three times... every time, I got a slew of FORMERRs in the syslog... and for the first two queries, I got no answers, and on the third, I got four answers. With "+tcp" 75% of dig requests for reuters.com are "connection refused" and about 25% of the time I get a sensible reply. –  aSteve Mar 20 '13 at 22:47
    
I've not played with Wireshark yet - as I'm not sure what I'm looking for. I don't think I have any 'forward only zones' - and I'm not sure what a 'stub zone' is. (Perhaps the problem is that I need to do more manual reading? It used to 'just work' - honest, Guv. :) –  aSteve Mar 20 '13 at 22:47
    
Without the dnssec lines above, I got other errors - with the lines, I get lots and lots of "non improving referral" errors. I've added a response from dig for the address of a major company. My Windows PC, over the same WAN connection, resolves barclays.co.uk correctly to two IP addresses when I use nslookup. –  aSteve Mar 20 '13 at 23:14
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.