Could you please explain why it makes sense to track this explicitly (as q->previous_redirect_non_synthetic) rather than checking that (q->answer_quesry_flags & (SD_RESOLVED_FROM_CACHE | SD_RESOLVED_FROM_NETWORK)) == 0, i.e. that no external sources have been used in constructing the reply?

SD_RESOLVED_FROM_xyz indicates the source where something comes from, but SD_RESOLVED_SYNTHETIC is not considered to be a "source" really, but a special marker for the "special stuff" if you so will...

If this sounds vague, that's because it is a bit. ;-)

Synthetic records for us report universal truth, independently of any protocol or network interfaces, any lookup "scopes", or any transactions. Synthetic records are either generated before we fire up the actual lookup engine, as kind of a shortcut, before we route things to some interface checking the domain info and such — or after we tried the lookup engine and things failed, as kind of a fallback. Synthetic records hence succeed even if you have zero network connectivity, no network interfaces, no DNS servers configured i.e. not a single lookup scope defined, because they are entirely independent of that, and always apply.

The source indication (i.e. the SD_RESOLVED_FROM_xyz flags) otoh tells us how a response was generated by the actual lookup engine, i.e. if we routed a lookup to some interface/scope and issued transactions for it. A "source" indication always reports about interface/scope/protocol/transaction specific stuff, i.e. is determined by a routing decision and reports not a universal truth, but a very specific one, bound to some interface/scope.

Now you might wonder: the trust anchor, why is that a "source", and not just considered "synthetic" too? That's because we define the trust anchor as a per-interface thing, users can configure per-interface what NTAs they define. Thus, an answer from the trust anchor means routing has to take place first.

Now, when reporting to clients where we got the data from we'll merge the source indications, hence we can just check that for this purpose and be happy. but the synthetic flag we reset on each redirect, hence we need to check what it was before the current redirect.

Does that make any sense?

That does make sense 🙂

I don't think I understand why SD_RESOLVED_SYNTHETIC has to be that special (why it can't effectively be SD_RESOLVED_FROM_LOCAL_DATA), even if it's set outside of the DNS scope / links. And why it has to be reset on redirects. But that's not what I'm asking here.

Since, as you're saying, the FROM_* flags are kept on redirects, can't we just check for SD_RESOLVED_FROM_CACHE|SD_RESOLVED_FROM_NETWORK (alternatively, SD_RESOLVED_FROM_MASK & ~(SD_RESOLVED_FROM_ZONE|SD_RESOLVED_FROM_TRUST_ANCHOR)) being not set, in addition to SD_RESOLVED_SYNTHETIC being set? That means, no external sources were used while resolving this query, neither this time, nor during the previous redirects. Because, had they been used, FROM_CACHE or FROM_NETWORK would have been set, and would still be set.

SD_RESOLVED_FROM_xyz indicates the source where something comes from, but SD_RESOLVED_SYNTHETIC is not considered to be a "source" really, but a special marker for the "special stuff" if you so will...

Maybe let's drop this distinction? It sounds pointlessly complicated. After all, it's just "local data", and I'd prefer to mark it as such a source and not require the special code paths for it. From user's POV, how we internally generate this is of no importance.

(To clarify: I think it'd be reasonable to have two flags: one for the real "local data" stuff, and one for the synthetic items generated by code.)