Re: [dnssd] Interaction between a DNS server and Discovery Proxy on the same host - where to describe?

[Ted Lemon <[e-mail]>]

There's some text about this in the Advertising Proxy document. It's not
clear to me that this is the right place for it, but it definitely needs to
be described somewhere.

To your question, I think that the behavior of the combined advertising
proxy/auth server/DNS caching resolver/DNS proxy (!) looks a bit like the
Discovery Broker that Stuart described here:
https://datatracker.ietf.org/doc/html/draft-sctl-discovery-broker

I haven't looked at that document in a long time, so I don't know if it
does the job anymore, but the point is that in order for the behavior
you're asking about to matter, we need for it to be the case that some DNS
query asks a question that the DNS responder answers by synthesizing
answers from a set of zero or more domains. For instance, a query for
_hap._udp.default.service.arpa might be translated into a query for a set
of domains, some of which would be served by regular DNS, some by an
advertising proxy (which is effectively regular DNS) and some by a
discovery proxy (which is not).

It would make sense for the rules from the Discovery Proxy RFC to apply
here: if there is information available to answer with, answer immediately.
If not, issue queries as needed; as soon as some answer is available, send
the response. Since there are multiple query sources, a negative response
can't be taken to mean "answer negatively right away." But when all sources
have answered negatively, then a negative response can be sent.

The way this would likely work is that some data might be present locally
(authoritative data) and this data is available for answering immediately.
The Discovery Proxy has a cache, and data might already be in the cache; if
so, this should be included in the response. I would say that this is true
even if it means that the discovery broker doesn't have direct access to
the Discovery Proxy cache, although that complicates things a bit.
Similarly, we probably ought to do the DNS query and wait a reasonable
amount of time for a response, for non-local data. Otherwise, we are
preferring the authoritative data, and it's not clear that's what we should
do. But we should definitely answer quickly, and not wait for six seconds
for a response as is recommended in the Discovery Proxy document, if some
data is available.

It might be worth thinking about scenarios where this will actually happen.
For example, in a Thread Border Router, a query to
_hap._udp.default.service.arpa will want data from the local infrastructure
link (WiFi) and the Thread network (802.15.4 mesh). The Thread network
service information will have been registered using SRP, and so it will
already be available. Information from the local link will come from the
Discovery Proxy, and might be in cache, or might not. If it's not in cache,
the Discovery Proxy will start a mDNS query. Discovering if it is in cache
may require some RPC mechanism to be used, which might produce an
asynchronous response.

E.g., in the Apple implementation, the Discovery Proxy is going to do an
RPC call to mDNSResponder, which is a local process, and mDNSResponder will
respond immediately if there is any cached data, for some value of
"immediately." If there is no cached data, mDNSResponder does not say
"there is no cached data"—it just doesn't respond. So the implementation
would have to time out quickly enough to respond to the DNS query in a
timely manner, but wait long enough that cached data would be returned.
Perhaps mDNSResponder should be extended to formally indicate that no
cached data is available.

Anyway, that's the implementation problem that I think you are talking
about. I'd be curious to know what people think of this. Is it bad if we
always wind up answering the query with SRP data (if present) because we
have that in an authority database that can be consulted synchronously?

On Mon, Jul 18, 2022 at 4:19 AM Esko Dijk <[e-mail]>
wrote:

> Hello,
>
>
>
> During implementation work a question came up how a DNS server with
> integrated Discovery Proxy (on the same host) should behave.
>
> RFC 8766 describes the situation that every request made by a DNS client
> is handled by the Discovery Proxy. But in practice, if the Discover Proxy
> is collocated with a DNS server, some interaction between both may be
> required: the DNS response may include locally stored records and/or
> records found by the Discovery Proxy.
>
>
>
> The question was specifically to the case of “standard” DNS queries (i.e.
> not using DNS Push Notifications and not using LLQ). Section 5.6 Answer
> Aggregation in RFC 8766 already describes the behavior towards the DNS
> client for this case: the proxy will respond back with the first answer(s)
> it can get hold of and not spend any effort obtaining more answers or
> waiting for more answers.
>
>
>
> But the situation where the same DNS server also hosts locally stored
> records in its database is not described there. This may happen e.g. if
> there’s an SRP server integrated into the same host (as in our case), or
> there may be another reason why there’s a DNS server.
>
>
>
> A first question is: where should this type of interaction be described?
> Do we need a new document for this?
>
>
>
> Second question: what’s the preferred behavior in this case?  My
> assumption was that we want to continue the RFC 8766 defined behavior
> towards the client, which would mean:
>
>    1. If the DNS server locally does not have any matching answer, and
>    also the Discovery Proxy cache has none, then the Discovery Proxy will send
>    an mDNS request. Per Case 1 “Standard DNS query; no answer in cache” of
>    8766.
>    2. If the DNS server locally does not have any matching answer, but
>    the Discovery Proxy cache has at least 1 answer, then the DNS server
>    answers with those cached answers and does not send a new mDNS request.
>    Case 2 “Standard DNS query; at least one answer in cache”.
>    3. If the DNS server locally holds any answer record(s) then the
>    Discovery Proxy does not need to send a new mDNS request; the DNS server
>    will answer with the local matching record(s) including those taken from
>    Discovery Proxy cache if any. Case 2 “Standard DNS query; at least one
>    answer in cache”.
>
>
>
> The assumption in above is that the DNS query is for a domain for which
> the DNS server (including its integrated Discovery Proxy) is authoritative.
>
>
>
> Best regards
>
> Esko
>
>
>
>
>
> IoTconsultancy.nl  |  Email/Teams: [e-mail]
>
>
>
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>