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

[Otto Moerbeek]

On Sat, Apr 05, 2025 at 12:08:12PM +0300, Olli Attila wrote:

> Hi,
> 
> Thanks for the tip - I actually tried that but was not able to get any
> working lua on the dnsdist side. Might have to consult the dnsdist mailing
> list about on howto use this "setRD".

There is an assymetry with SetNoRecurseAction(), as SetRecurseAction()
does not exist. But this seems to work here to set the RD flag on
queries not having them. Depending on the details of your setup you
might need a more complex rule to only match the queries where this
should be done.

function setRD(dq)
  dq.dh:setRD(true)
  return DNSAction.None -- process further rules
end

addAction(NotRule(RDRule()), LuaAction(setRD))

	-Otto

> 
> Cheers,
> OA
> 
> la 5. huhtik. 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
> >
> >