On 2023/02/09 22:54, Ted Lemon wrote:
> We've been talking elsewhere (Thread) about a small issue that comes
up in
> constrained networks that if we want to do service discovery, and we
get a
> PTR record for a service, then the next thing we need is the SRV and TXT
> records for the service instance, and that's two queries.
Then, proper thing to do is to have a new unified RR type,
which was not the case with AAAA.
See below why MX was introduced.
Now, in general although there is no RFC that expressly forbids QDCOUNT > 1
(or if there is, I couldn't find it, please clue me in), we don't generally
support it (my code returns REFUSED, and so does BIND9).
1035 is clear about meaninglessness of the idea:
For example, the original form of mail exchange binding used two RR
types one to represent a "closer" exchange (MD) and one to represent a
"less close" exchange (MF). The difficulty is that the presence of one
RR type in a cache doesn't convey any information about the other
because the query which acquired the cached information might have used
a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
service used a single type (MX) with a "preference" value in the RDATA
section which can order different RRs. However, if any MX RRs are found
in the cache, then all should be there.
Masataka Ohta
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
