as mentioned earlier, only -ONE- known, public DNS conformance test suite has existed and it was shut down last year due to lack of use.
since you want the courts involved, you are making some significant presumptions about the liability of adherence to voluntary standards. dead issue … move on. Or persuade Yokogawa Electric Corporation to spin the test suite back up. /bill On 20May2013Monday, at 19:20, Mark Andrews wrote: > > In message <7e5b1b3d-8af1-4ffe-bda2-47efb6d35...@vpnc.org>, Paul Hoffman > writes: >> On May 20, 2013, at 6:23 PM, Mark Andrews <ma...@isc.org> wrote: >> >>> >>> In message <6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu>, manning bill >> writes: >>>> I believe that there are a couple of problems with this plea. >>>> >>>> 1) - The IETF has -never- tested for or assured compliance with their >>>> document series. >>> >>> Which has what to do with requesting that a known problem get fixed? >> >> One has to test for compliance in order to determine if the problem >> exists in a particular implementation. > > It doesn't have to be the IETF that does the testing. In fact the > IETF doesn't have access to the list of servers that need to be > tested however the operators of the parent zones do. Alternatively > it can be done on a piecemeal basis by examine logs and then looking > up whois entries and complaining that the nameservers are causing > operational problems to the operators, the complaining to the > parent zone, then complaining to the courts when the parent zone > operators fail to take action as directed by RFC 1034. > >>> One that is clearly caused by nameservers operating outside the >>> expected behaviour of nameservers. >> >> No offense, but your view of "clearly" and "expected" have sometimes been >> at odds with other folks in the DNS protocol community. Your request that >> the IETF do conformance testing might first be based on assurance that >> the DNS protocol community agrees on those. After that, "someone" can >> probably do testing. And after that, "someone" might be able to get >> people to take action against non-conformant implementations. > > RFC 1034 describes how to answer a query. It clearly states that new > query types are expected. > > "However, the domain system is intentionally extensible. Researchers are > continuously proposing, implementing and experimenting with new data > types, query types, classes, functions, etc. Thus while the components > of the official protocol are expected to stay essentially unchanged and > operate as a production service, experimental behavior should always be > expected in extensions beyond the official protocol. Experimental or > obsolete features are clearly marked in these RFCs, and such information > should be used with caution." > > It also states how to constuct a response and it doesn't state > "only known types". > > 3. Start matching down, label by label, in the zone. The > matching process can terminate several ways: > > a. If the whole of QNAME is matched, we have found the > node. > > If the data at the node is a CNAME, and QTYPE doesn't > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > Otherwise, copy all RRs which match QTYPE into the > answer section and go to step 6. > > The DNS also has response codes to say that a nameserver doesn't > implement a part if the specification, that it don't want to answer > a particular query, that a internal error occured, that you don't > understand or can parse the query. These response codes cover just > about any conceivable error condition. It is a query/response > protocol and a response is expected except under exceptional > circumstances. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
