resolved: rework CNAME logic a bit more
authorLennart Poettering <lennart@poettering.net>
Wed, 24 Mar 2021 22:29:16 +0000 (23:29 +0100)
committerLennart Poettering <lennart@poettering.net>
Thu, 25 Mar 2021 12:12:19 +0000 (13:12 +0100)
commit915ba31cfd6b87e9f3dd31f2bf5bd0b5c252738e
treec081b86e16ef1fd585a1c5d118d7f45a094b2e09
parent1db8e6d1db0880de240e5598e28d24d708479434
resolved: rework CNAME logic a bit more

When following CNAME/DNAME redirects in the stub we currently first
iterate through the packet and pick up what we can use (in
dns_stub_collect_answer_by_question() and friends), following all
CNAMEs/DNAMEs, and would then issue dns_query_process_cname() to move
the DnsQuery object forward too, where we'd then possibly restart
the query and pick things up again, as above.

There's one thought error in this though: dns_query_process_cname()
tries to be smart and will internally follow not just a single
CNAME/DNAME redirect, but a chain of them if they are contained inside
the same packet until we reach the point where the answer is not
included in the packet anymore, where we'd restart the query. This was
great as long as we only focussed on the D-Bus and Varlink resolver
APIs, since there the CNAME/DNAME chain in the middle doesn't actually
matter, we just return information about the final name of the RR and
its content, and aren't interested in the chain to it. For the DNS stub
this is different however: there we need to place the full CNAME/DNAME
chain (and all the appropriate metadata RRs) in the stub reply.

Hence rework this so that we build on the fact that the previous commit
split dns_query_process_cname() in two:

1. dns_query_process_cname_one() will do exactly one CNAME/DNAME
   redirect step. This will be called by the stub, so that we can pick
   up matching RRs for every single step along the way.

2. dns_query_process_cname_many() will follow a chain as long as that's
   possible within the same packet. It's thus pretty much identical to
   the old dns_query_process_cname() call. This is what we now use in
   the D-Bus and Varlink APIs. dns_query_process_cname_many() is
   basically just a loop around dns_query_process_cname_one().

Any logic to follow and pick up RRs manually in the stub along the
CNAME/DNAME path is now dropped (i.e.
dns_stub_collect_answer_by_question() becomes trivially simple again),
we solely rely on dns_query_process_cname_one() to follow CNAME/DNAME
now: each step followed by a full call of dns_stub_assign_sections() to
copy out the RRs that matter.

Net result: things are a bit simpler again, as the only place we follow
CNAME/DNAME redirects is DnsQuery again, and stub answers are always
complete: they contain all CNAME/DNAME RRs on the way including all
their metadata we might pick up in the other sections.
src/resolve/resolved-dns-stub.c