<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><div>Thanks you so much, Mark.</div><div><br></div><div>Based on your input, I successfully found the culprit.... It's one of the LDNS. It's supposed to config the zone as "xx.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org". But somehow it's been configed as "node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org", which is not delegated to this LDNS.</div><div><br></div><div>What's more, only the newly added root DNS will reply with the "real" incorrect zone "node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org". The old one's reply is "correct", it's "xx.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org" (Maybe the old one doesn't query the LDNS and reply the query with it's own configuration).</div><div><br></div><div>When the servers query the newly added dns and cache the incorrect zone "node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org", the invalid log keeps popping up.</div><div><br></div><div>In summary, the issue happens on two conditions:</div><div>1. the incorrect configuration in LDNS.</div><div>2. the newly added root DNS, whose mechanism is different from the old one.</div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "marka";<marka@isc.org>;</div><div><b>Send time:</b> Thursday, Jan 14, 2021 11:12 AM</div><div><b>To:</b> "同屋"<39223722@qq.com>; <wbr></div><div><b>Cc:</b> "Bind-users"<Bind-users@lists.isc.org>; <wbr></div><div><b>Subject: </b> Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log</div></div><div><br></div><br><br>> On 7 Jan 2021, at 00:57, 同屋 <39223722@qq.com> wrote:<br>> <br>> Actually, the background is a little bit complicated. In short, the topo is as belows. dns1 were swapped by a new one (say dns1*), then the issue happened. After that, we dropped all the AAAA request from dns1*, then the issue was gone.<br><br>Well if you stop making requests that result in negative responses (NXDOMAIN or NOERROR/NODATA) you no longer send responses with the incorrect SOA record in the authority section.<br><br>> There is no config change during the whole process, no idea why the caching server has such log.<br><br>You get such logs because there are servers that are misconfigured.  If you delegate a zone to a server then ALL negative responses for queries in that delegated namespace should be coming back with a SOA record that matches the delegated zone.  Named checks the returned SOA record in the authority section and if it isn’t a expected value then named logs the messages you are seeing.<br><br>You can reproduce this with the following setup where example.com is delegated to server1.example.com and child.example.com is delegated to server2.example.com but it is incorrectly configured for a different version of<br>example.com.<br><br>server1.example.com(192.0.2.1):<br>example.com.           SOA     server1.example.com. . 0 0 0 0 0<br>example.com.          NS      server1.example.com.<br>server1.example.com.      A       192.0.2.1<br>server2.example.com. A       192.0.2.2<br>child.example.com.   NS      server2.example.com.<br><br>server2.example.com(192.0.2.2):<br>example.com.           SOA     server2.example.com. . 0 0 0 0 0<br>example.com.          NS      server2.example.com.<br>server2.example.com.      A       192.0.2.2<br>child.example.com.   A       192.0.2.3<br><br>A proper delegation would have:<br><br>server2.example.com(192.0.2.2):<br>child.example.com.     SOA     server2.example.com. . 0 0 0 0 0<br>child.example.com.    NS      server2.example.com.<br>child.example.com.        A       192.0.2.3<br><br>Load balancers often end up with broken configuration because, it appears, the documentation is not clear enough.  The load balancing software knows about A queries and returns for them but punts all the other queries to a backing server which instead of being configured with the zone child.example.com is configured with the zone example.com which contains just the SOA and NS records.<br><br>example.com.           SOA     server1.example.com. . 0 0 0 0 0<br>example.com.          NS      server1.example.com.<br><br>Client -> load balancer -> backing server.<br><br>If you ask for child.example.com/A you get back a A record with the computed value.<br><br>If you ask for child.example.com/AAAA the load balancer says this not something I deal with and passes the request on to the backing nameserver which, because it has been configured to serve example.com instead of child.example.com, returns a negative response with example.com as the owner name of the SOA record rather than a child.example.com SOA record that is expected.<br><br>Mark<br><br>> --------       ---------<br>> |dns1  |      | dns2 |<br>> --------       ---------<br>>     |                 |<br>>      --------------<br>>              |<br>>    -----------------<br>>   |caching server|  (where the log was observed)<br>>   ------------------<br>> <br>> ------------------ Original ------------------<br>> From:  "同屋";<39223722@qq.com>;<br>> Send time: Wednesday, Jan 6, 2021 8:43 PM<br>> To: "同屋"<39223722@qq.com>; "marka"<marka@isc.org>;<br>> Cc: "Bind-users"<Bind-users@lists.isc.org>;<br>> Subject:  re:Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log<br>> <br>> Thanks mark, but why this issue is related to load balancer?<br>> <br>> <br>> <br>> ------------------ Original Message ------------------<br>> From: "Mark Andrews";<br>> Date: 2021-01-06 19:09<br>> To: "同屋"<39223722@qq.com>;<br>> To:<br>> "bind-users";<br>> <br>> Subject: Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log<br>> <br>> <br>> Complain to the administrators of the zone. They have not properly delegated it.  We see this often with load balancers.<br>> <br>> The zone a.b.example has been delegated but the answer is as if it is from b.example. <br>> <br>> --<br>> Mark Andrews<br>> <br>>> On 6 Jan 2021, at 21:02, 同屋 <39223722@qq.com> wrote:<br>>> <br>>> <br>>> The version of bind is BIND 9.10.5-P3 id:7d5676f <br>>> <br>>> One day, I found that the size of named.run is increasing very quickly. And a lot of "invalid response" entries were spotted in the log. Details is as follows (I replace the sensitive info with  {xxxx},{AAA} etc.)<br>>> <br>>> DNS format error from {IP}#53 resolving {XXXX}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org/AAAA for client 169.254.4.50#51099: Name epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org (SOA) not subdomain of zone node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org -- invalid response<br>>> <br>>> The response related to the above log is as follows:<br>>> <br>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50664 ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;{XXXX}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. IN AAAA<br>>> <br>>> ;; AUTHORITY SECTION: ;epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. 86400 IN SOA  .mnc{AAA}.mcc{BBB}.gprs. dns-admin. ( ;                                         2020122704 ; serial ;   10800 ; refresh (3 hours) ;     3600 ; retry (1 hour) ; 604800 ; expire (1 week) ;      86400 ; minimum (1 day) ;       )<br>>> <br>>> ============================================<br>>> <br>>> Normally, the FQDN should be cached as a NXRRSET record as follows:<br>>> <br>>> {XXXX}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. 8412 -AAAA ;-$NXRRSET<br>>> <br>>> But when the issue happens, it cannot be cached, I guess it's related to the "invalid response" log.<br>>> <br>>> From the error log, it mentions "zone node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org", but I'm wondering where the zone "node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org" comes from? I cannot found the related SOA record in the dump file.<br>>> <br>>> _______________________________________________<br>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br>>> <br>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br>>> <br>>> <br>>> bind-users mailing list<br>>> bind-users@lists.isc.org<br>>> https://lists.isc.org/mailman/listinfo/bind-users<br><br>-- <br>Mark Andrews, ISC<br>1 Seymour St., Dundas Valley, NSW 2117, Australia<br>PHONE: +61 2 9871 4742              INTERNET: marka@isc.org<br><br></div>