Hi, Perfect. Thanks.
OA la 5.4.2025 klo 8.36 Otto Moerbeek (o...@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@mailman.powerdns.com > > https://mailman.powerdns.com/mailman/listinfo/pdns-users > >
_______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
