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

[Paul Fletcher]

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.

 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210828/dc91e684/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4212 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210828/dc91e684/attachment-0001.bin>