[Pdns-users] recursor: Possible bug in accepting / rejecting additional answers?
Remi Gacogne
remi.gacogne at powerdns.com
Mon Aug 30 08:54:38 UTC 2021
Hi,
I think I have to clarify a bit here. The first question was why the
recursor doesn't accept the A records from the delegated name server’s
response. For the record I believe we are talking about this response,
received from one of the servers returned in the delegation from one of
the com name server:
;; QUESTION SECTION:
;solera.com. IN MX
;; ANSWER SECTION:
solera.com. 300 IN MX 10
solera-com.mail.protection.outlook.com.
;; AUTHORITY SECTION:
solera.com. 1800 IN NS dns2.adpclaims.com.
solera.com. 1800 IN NS dns1.adpclaims.com.
;; ADDITIONAL SECTION:
dns1.adpclaims.com. 1800 IN A 170.76.174.203
dns2.adpclaims.com. 1800 IN A 170.76.174.204
The recursor can accept the records in the answer and authority sections
because they are at or below solera.com, which we know this name server
to be authoritative for. The A records in the additional section are in
the adpclaims.com zone, and at this point we have no way of knowing
whether this server is authoritative for that zone so we _have_ to
reject them, otherwise we would open ourselves to a cache pollution
security issue.
The A records in the response from the com name server were accepted
because adpclaims.com is below com, which we knew the name server to be
authoritative for.
Then the second part, the one Frank has been answering below, is about
the recursor replacing the non-authoritative NS set with the
authoritative one. There is a long discussion about that on our issue
tracker [1]. Basically we follow rfc2181 section-5.4.1 and we believe
it's the right call, but we do agree with Frank that it would be nice to
be able to fall back to the non-authoritative NS set when that one is
clearly broken. We are trying to find a way to implement that without
opening ourselves to a security flaw, or making well-configured zones
bear the burden of broken ones. As always, suggestions and pull requests
are very welcome.
[1]: https://github.com/PowerDNS/pdns/issues/10594
Hope that helps,
Remi
On 8/30/21 9:55 AM, frank+pdns--- via Pdns-users wrote:
> 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 issolera.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 <http://Kiwazo.be>
>
>
>
>
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210830/3ef1f540/attachment-0001.sig>
More information about the Pdns-users
mailing list