> On 1 Oct 2024, at 18:51, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >> Yes, you send multiple queries. For QTYPE I would do this after >> I have got the response so one can set the correct expectation for >> the rcode, (NOERROR vs NXDOMAIN). >> >> For opcode one is looking for NOTIMP. > > The draft says 'Servers that do not tolerate unknown values will fail to > interoperate'. But for extra queries that is not true. Certainly not if > the extra query comes after the real query. It may not even be clear > in what context the extra query should execute. After all the real query > has finished already.
If it doesn’t answer it does not interoperate. If it returns REFUSED it does not interoperate. It it returns NXDOMAIN and the initial response was NOERROR it does not interoperate or vice versa. Remember DNS clients can ask queries with any QTYPE and the server is supposed to give back consistent answers. Servers CACHE NXDOMAIN consistency is important. > Going back a long time when bind would report 'lame delegations'. By and > large nobody knew what do with that. So 'These failures could be logged and > be used to identify broken implementations'. It is not at all clear > if something positive will happen if production servers start logging issues > with remote servers. It provides information from multiple collections points about servers for named that people actually query. DNS traffic patterns are not static. What is not a problem now may well become a problem in the future. We have seen this many times. The introduction of AAAA records. The introduction of DNSSEC. The introduction of DNS COOKIE. The introduction of HTTPS records. The introduction of prefix names. The introduction of DO and AD. These have all caused problems in the past primarily because of mis-implementations all of which would have benefited from the protocol having been greased. >> You have time limited testing built into the code and controls to >> turn the tests off. > > That is fine. But where do those get published? > >> We have been doing this sort of testing for nearly a decade now >> see: https://ednscomp.isc.org > > It seems that a lot of this draft is more for a measuring tool like the > above. The above site also has on demand testing of servers. It also has the source code for the testing tool. There are many ways to use the results but you can’t fix something if you don’t know it is broken. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
