On 29/11/12 10:17, Martin D Kealey wrote:
AFAIK this is because the "primary nameserver" field in the SOA record doesn't one of the NS records in the delegation from the parent zone.
Absolutely not. The SOA primary name server not being one of the delegated name servers is not an error, in fact it's a common configuration. Case in point, nz and its 2LDs are configured: @ SOA loopback.dns.net.nz. soa.nzrs.net.nz. 2012112944 900 300 604800 3600 NS ns1.dns.net.nz. NS ns2.dns.net.nz. NS ns3.dns.net.nz. NS ns4.dns.net.nz. NS ns5.dns.net.nz. NS ns6.dns.net.nz. NS ns7.dns.net.nz. "loopback.dns.net.nz" points to 127.0.0.1, and you'll notice that it's not in the or parent delegation. This was originally done to deal with broken/misconfigured Microsoft Windows hosts sending DNS updates to the NZ nameservers as part of their network initialisation; the update process would look up the primary name server in the SOA, and send the update there. The updates were ignored, of course, but produced a steady stream of unnecessary traffic. Setting the primary nameserver to "loopback.dns.net.nz", address 127.0.0.1, meant that the update would get sent up the broken host's own backside. In reality, none of the listed name servers are primary. The actual primaries (two) are not reachable from the Internet at large, so the "primary nameserver" is not useful information to anyone. (Such "hidden primaries" are pretty much standard equipment on significant DNS infrastructures.) No part of normal DNS name resolution uses the SOA primary nameserver field. (You do get a copy of the SOA record in negative responses, but in that case the primary name server field is not used.)
Mark Andrews at ISC: https://lists.isc.org/pipermail/bind-users/2010-April/079804.html
... talks about bogus SOA records being returned for domains the device isn't authoritative for by broken DNS code, mostly on nasty load balancers. Which is actually what is happening here. "ns-os1.qq.com" is delegated to: $ dig ns-os1.qq.com. NS @ns1.qq.com. ns-os1.qq.com. 86400 IN NS ns-os1.qq.com. ns-os1.qq.com. 86400 IN NS ns-cmn1.qq.com. ns-os1.qq.com. 86400 IN NS ns-cnc1.qq.com. If you do an A query to these you get sense: $ dig ns-os1.qq.com. A @ns-os1.qq.com. ns-os1.qq.com. 600 IN A 202.55.2.230 ns-os1.qq.com. 600 IN A 114.134.85.106 but if you do a AAAA query ... not so much: $ dig ns-os1.qq.com. AAAA @ns-os1.qq.com. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49063 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ... ;; AUTHORITY SECTION: qq.com. 300 IN SOA ns1.qq.com. webmaster.qq.com. 1350444472 300 600 86400 300 Since ns-os1.qq.com is supposed to be authoritative for the domain ns-os1.qq.com. it should be returning the SOA for ns-os1.qq.com, not qq.com (that's the left hand field in the response). I suspect, as per Mark Andrews post, it's a dodgy DNS load balancer. In fact any query other an a A query (including SOA and NS queries) to it gets exactly that response. It's just plain broken. So to answer Richard's question: it's their fault, you don't need to care, just filter the message out of logcheck if it's bothering you. -- don