In message <7E5B1B3D-8AF1-4FFE-BDA2-47EFB6D35188(_at_)vpnc(_dot_)org>, Paul
Hoffman writes:
On May 20, 2013, at 6:23 PM, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
In message <6A13CEB4-8906-4EC5-9210-571D5474E7FC(_at_)isi(_dot_)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: marka(_at_)isc(_dot_)org