Martin Rex wrote:
>
> So if the behaviour (how to exactly respond to queries for unknown
> QTYPEs) is neither explicitly specified, nor likely have been part of
> the usual/common interop tests performed by the vendor,
> what you're left with might be "ureflected&untested guessing"
> on part of the implementors to fill those gaps.
What you typically have is a certain amount of code processing a query,
and some 3-4 conditions under which this code fails, and where the
implementor will have to decide which RCODE to return. The choices
available in rfc1035 are:
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
0 No error condition
1 Format error - The name server was
unable to interpret the query.
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
3 Name Error - Meaningful only for
responses from an authoritative name
server, this code signifies that the
domain name referenced in the query does
not exist.
4 Not Implemented - The name server does
not support the requested kind of query.
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
6-15 Reserved for future use.
The choice between RCODEs 1, 2 and 4 for failed AAAA queries
might be fairly random, the description for 3 is slightly confusing
in whether a DNS server might use this RCODE "creatively" by
returning it without AA.
For an implementor that is being told "do not use use RCODE 4 for
unknown QTYPES", not sending any response at all to an unsupported
AAAA query seems like a reasonable choice.
-Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf