[Pdns-users] Recursor 5.2.0 with RD=0 forwarded queries
Otto Moerbeek
otto at drijf.net
Sat Apr 5 05:36:31 UTC 2025
On Fri, Apr 04, 2025 at 09:25:04PM +0300, Olli Attila via Pdns-users wrote:
Hi,
I think setting the RD flag in dnsdist using
https://www.dnsdist.org/reference/dq.html?highlight=rd#DNSHeader:setRD
on the requests forwarded to the recursor should work and get you the
old behaviour back. I don't see why that would not be acceptable. If
the recursor has a (non-recursive) forward for the name queried, it
will consult the cache and, if needed, query the forwarding target
(that query wil not have the RD flag set). After that postresolve() is
called if present.
That should get you your old behaviour back, unless I'm missing
something.
-Otto
> Hello all,
>
>
>
> After upgrading from dns-recursor 4.8.x -> 5.2.0 I noticed this happened:
>
>
>
> Recursor 4.9.x changelog (4.9.0-alpha1 Improvements):
>
> "Change the way RD=0 forwarded queries are handled.
> References: pull request 12425 <https://github.com/PowerDNS/pdns/pull/12425>
> "
>
> Related PR: https://github.com/PowerDNS/pdns/pull/12594
>
> I am using a setup in a custom environment where dnsdist is taking in
> queries and routing them through a pdns recursor which is forwarding the
> queries to pdns authoritative dns server. The recursor in between is doing
> forwarding to auth server and is responsible of mangling the returned DNS
> record data that the authoritative server returns. This so called
> "mangling" is done because on some cases I need to alter the NAPTR response
> depending the orginal source of the query. A sort of dns view if one would
> like to use that kind of name for this behaviour.
>
> Client side DNS component (which behaviour I can't unfortunately change) is
> always sending the query with RD bit set to "0" towards dnsdist ip and
> therefore after dnsdist has routed the query to the recursor, the 5.2.0
> recursor is now refusing to forward the queries to authoritative servers
> (REFUSED is returned). This was working on the pdns recursor 4.8.x. Now
> that I need that mangling in between dnsdist and auth servers (at least for
> the time being), what would be the options to achieve this after the 5.2.0
> recursor upgrade on this kind of setup?
>
> Observations / thoughts on different options:
>
> - Dnsdist does not seem to support the same kind of postresolve lua like
> the recursor component (=Altering returned NAPTR content with regexp. There
> is an example at the end of my mail). I have not succeeded in making it
> behave the same way. Also the dirty trick of making the dnsdist to force RD
> from 0 to 1 is off the table I think (for allowing the recursor to recurse
> to auth servers after dnsdist). This would be kind of a hack if even
> possible?
> - Im under the impression that Pdns authoritative server (what I use
> here as auth) is not either capable of doing this kind of mangling for the
> returned NAPTR records. Please correct me if I'm wrong with this.
> - On recursor config there is this new parameter "allow-no-rd" which was
> introduced in 5.0.0 but to use this in an effective way I should be having
> all the auth server data in the recursors internal cache and then after the
> response, do the mangling as before with the lua magic? Having to sync the
> data from auth servers to the recursors cache seems quite weird but if
> someone has thoughts on this, Im all ears.
>
>
>
> For the mangling of the NAPTR I'm doing this kind of thing on the recursor
> now (which I would hope to preserve somehow):
>
> function postresolve(dq)
>
> local records = dq:getRecords()
>
> local modified = false
>
> for k, v in pairs(records) do
>
> if v.type == pdns.NAPTR and string.find(v:getContent(), "foo.bar")
> then
>
> local originalContent = v:getContent()
>
> local one, two, three = string.match(v:getContent(),
> "(.*)@(.*)bar(.*)")
>
> if one and two and three then
>
> v:changeContent(one .. "@newfoo.bar" .. three)
>
> modified = true
>
> end
>
> originalContent = v:getContent()
>
> end
>
> end
>
> if modified then
>
> dq:setRecords(records)
>
> end
>
> return true
>
> End
>
>
>
>
> Cheers,
>
> OA
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
More information about the Pdns-users
mailing list