[Pdns-users] recursor: Possible bug in accepting / rejecting additional answers?

[frank+pdns at tembo.be]

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 at mailman.powerdns.com <mailto:pdns-users at 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 at mailman.powerdns.com <mailto:Pdns-users at 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210830/84a9b6d9/attachment.htm>