[Pdns-users] Authoritative PDNS gives back non-authoritative Answers for records
rob777
rogbru at gmail.com
Sat Nov 2 08:06:46 UTC 2024
Hi Doug
Thanks for shedding some light on this
>If the only things querying these names are clients' stub resolvers, and
those clients are configured to use only these recursors directly or
indirectly for these names, then your configuration is not wrong, and you
won't have any issues
I only have
a) direct: clients/servers querying these internal names having these
recursor ip's configured in their dns resolver config
b) indirect: clients/servers which are querying these names through their
own internal DNS (Microsoft AD DNS) which have these recursors configured
as DNS Forwarders
Is my understanding of what i call "indirect" the same understanding as you
have with regards to your use of the word "indirectly"?
Regards
Am Sa., 2. Nov. 2024 um 08:17 Uhr schrieb Doug Freed via Pdns-users <
pdns-users at mailman.powerdns.com>:
> On Sat, Nov 2, 2024 at 2:04 AM rob777 via Pdns-users
> <pdns-users at mailman.powerdns.com> wrote:
> >
> > Hi
> >
> > >AUTHORITY has nothing to do with wether the answer is authoritative.
> You need to look at the flags
> >
> > Yes I've realized that after more research that the aa flag is the real
> thing to look for.
> >
> > The pdns-recursor runs on port 53 on the server and forward the queries
> for the internal zone through the forward-zone file to the port 53 from the
> pdns authoritiative on the same server - like
> >
> > ...
> > example1.mydomain.com=10.0.11.100:5300
> > ...
> >
> > I found other posts in pdns mailings about the same with no answers:
> https://mailman.powerdns.com/pipermail/pdns-dev/2020-April/001775.html
> > And then another one in a little bit of a different context but with
> someone replying at the end of the thread that this is an expected behavior
> >
> > ->
> https://pdns-users.mailman.powerdns.narkive.com/FjxQ55ou/recursor-pdns-authoritative-and-axfr-problem
> >
> > So from research i found two basic sides:
> >
> > a) some say this is the expected behavior and is correct
> > b) others are worried about it too and are not sure whether if this is
> generates problems for some stuff or not
> >
> > So it leaves me guessing whether i have to care about it for my internal
> dns infrastructure (i'm pretty sure that it would not be a problem but not
> 100% sure)
>
> The behavior you're seeing is expected given your configuration.
> Whether it's correct depends on how your recursor and authoritative
> servers are being used. If the only things querying these names are
> clients' stub resolvers, and those clients are configured to use only
> these recursors directly or indirectly for these names, then your
> configuration is not wrong, and you won't have any issues. However,
> if other recursors need to query these names, then the authoritative
> servers need to be reachable through some mechanism besides through
> your recursors, like with dnsdist or otherwise directly, or you are
> likely to experience issues. This is especially true for
> pdns-recursor, as it does not accept answers from servers that should
> be authoritative for the query that do not have the AA bit set.
>
> >
> >
> >
> > > BTW, obfuscation isn't ever helpful for having people help on a
> mailing list [1]
> >
> > I agree - espeically if the obfuscation is not done in a proper way.
> >
> >
> > Am Fr., 1. Nov. 2024 um 15:10 Uhr schrieb Jan-Piet Mens via Pdns-users <
> pdns-users at mailman.powerdns.com>:
> >>
> >> >$ dig test.example1.mydomain.com @<ip-of-my secondary>
> >> >; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu
> >> >...
> >> >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >>
> >> >As you can see above "AUTHORITY: 0" is a none authoritative answer
> >>
> >> AUTHORITY has nothing to do with wether the answer is authoritative.
> You need
> >> to look at the flags: this query has RD (recursion desired) and RA
> (recursion
> >> available), meaning you are querying a recursive server and hence no AA
> (authoritative
> >> answer) in the flags.
> >>
> >> BTW, obfuscation isn't ever helpful for having people help on a mailing
> list [1]
> >>
> >>
> >> -JP
> >>
> >> [1]
> https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open
> >> _______________________________________________
> >> Pdns-users mailing list
> >> Pdns-users at mailman.powerdns.com
> >> https://mailman.powerdns.com/mailman/listinfo/pdns-users
> >
> > _______________________________________________
> > Pdns-users mailing list
> > Pdns-users at mailman.powerdns.com
> > https://mailman.powerdns.com/mailman/listinfo/pdns-users
>
> -Doug
> _______________________________________________
> 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/20241102/1f62293e/attachment-0001.htm>
More information about the Pdns-users
mailing list