Hi Paul, This is a design choice by PowerDNS, which is defendable: the domain is misconfigured and the RFCs don't clearly which option to take in such a case. Unfortunately, Google and Unbound toke a different option, so when the customer verifies against 8.8.8.8, it will just work. Also unfortunately, PowerDNS took the option of having the return depend on the state of cache, meaning that depending on the order you execute the queries in, you'll get a different result.
I've had long discussions with the core maintainers and discussion makers at PowerDNS, but – for now – they won't change this behaviour. Kind Regards, Frank > On 28 Aug 2021, at 9:43 AM, Paul Fletcher via Pdns-users > <pdns-users@mailman.powerdns.com <mailto:pdns-users@mailman.powerdns.com>> > wrote: > > Hello, > > We are having problems with pdns-recursor when resolving an MX record for a > domain whose delegation is partially mis-configured. Whilst that > mis-configuration is clearly the trigger for the problem, the behaviour of > pdns is tunring a small problem into a big one, when other recursors do not > appear to do so. > > Version: 4.5.5 (also seen in earlier versions) > OS: CentOS7 > > Description of the problem: > Initial discovery of NS for the domain gets an answer from gtld-servers. The > answer includes: > 4 NS names; two are in the domain itself, and two are in an unrelated zone. > TTL=172800 > A records / IP addresses for those 4 names (one per name). TTL=172800 > > Two of the IP addresses are incorrect. The four name servers are cached, as > are the four A records. > > Recursor then goes on to one of the name servers, for which it has a valid > IP. (In fact the IP in the A record is for a different one of the name > servers to the one which the initial answer said it was for, but it is > nevertheless the IP of a valid name server for the domain). It queries the > MX record, and gets back a response. The response includes > The MX record, with TTL=300 > 2 NS servers (two of the four which were in the parent response). TTL=1800 > A records for those 2 servers. TTL=1800 > > This time the A records are correct. However, whilst recursor replaces the > previous NS records in the cache, it does NOT replace the A records. In > older versions it says > “Accept answer? NO!” > In newer versions it says > “Removing record in the 3 section” > > So now if we look up the MX record again after its TTL has expired, recursor > correctly identifies the names of the two name servers to use from cache. It > then tries to resolve those to IPs, which it does by using the incorrect A > records that were cached from the first response. And since they are not > accessible, the query times out. Nothing works until the 1800 TTL on the > name servers expires, at which point we go back to the start, getting 4 name > servers and 4 IPs, two of which work and allow us to resolve the query this > one time only. > > I don’t understand why the recursor accepted and cached the A records which > it got in the response from the gtld-servers – even though the two important > ones are in a different zone, with nothing to indicate that gtld-servers are > authoritative for that zone; but it doesn’t accept the A records from the > delegated name server’s response. Is there something we can do to alter this > behaviour? If it either accepted them in both cases or rejected them in both > cases, everything would work despite the slightly broken initial response. > As I say, we don’t see this problem with other recursive resolvers. > > The domain is solera.com <http://solera.com/>. > > Thanks for any pointers. > > Paul > > This electronic communication and the information and any files transmitted > with it, or attached to it, are confidential and are intended solely for the > use of the individual or entity to whom it is addressed and may contain > information that is confidential, legally privileged, protected by privacy > laws, or otherwise restricted from disclosure to anyone else. If you are not > the intended recipient or the person responsible for delivering the e-mail to > the intended recipient, you are hereby notified that any use, copying, > distributing, dissemination, forwarding, printing, or copying of this e-mail > is strictly prohibited. If you received this e-mail in error, please return > the e-mail to the sender, delete it from your computer, and destroy any > printed copy of it._______________________________________________ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com <mailto:Pdns-users@mailman.powerdns.com> > https://mailman.powerdns.com/mailman/listinfo/pdns-users > <https://mailman.powerdns.com/mailman/listinfo/pdns-users> Frank Louwers PowerDNS Certified Consultant @ Kiwazo.be
_______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
