Ohta-san, thanks for pointing out that text about the motivation for MX in RFC1035—I hadn't noticed that. It still doesn't exactly prohibit doing QDCOUNT > 1, but it's a helpful additional note about the history of the problem. FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to the cache—it just suggests that the work involved in doing it successfully is different (more complex) than the simpler problem you have to solve if QDCOUNT == 1. Having just done an implementation of QDCOUNT > 1, I agree that it's more complicated! :)
On Mon, Feb 13, 2023 at 4:27 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
