[Pdns-users] Recursor 5.2.0 with RD=0 forwarded queries

[Olli Attila]

Hi,

Perfect. Thanks.

OA

la 5.4.2025 klo 8.36 Otto Moerbeek (otto at drijf.net) kirjoitti:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20250405/4a0b788f/attachment.htm>