In message <19332445E29DABDB188C589E(_at_)JcK-HP8200(_dot_)jck(_dot_)com>, John
C Klensin writes:
--On Sunday, February 22, 2015 07:51 +1100 Mark Andrews
<marka(_at_)isc(_dot_)org> wrote:
...
I'm not going to comment on the rest of this except to observe
that the Protocol Police (and associated judges and jails) have
been notably less available in the DNS area -- where many of the
TLD operator on whom you want to impose requirements not only
have a history of ignoring mandates but of being quite
articulate about their right to do so -- than in a variety of
others.
And as a result we have lookups that fail and lots of hacks being
deployed to try and work around the broken servers out there.
However...
The last reserved bit in the DNS header should also be ignored
if present in a query and not be present in the response.
This is implied by RFC 1034 but not formally stated. There
are nameserver implementions that will drop such queries.
There are nameserver implementions that will return FORMERR to
such queries. There are nameserver implementions that will
return NOTIMP to such queries
Root nameservers should be a future proof as possible in their
handling of queries.
If you want future-proofing, it is unwise to ignore any bit,
including reserved ones, unless you know in advance whatever its
implications are. The requirement stated above changes the
status of that bit from "reserved, can be used for something in
the future if needed" to "reserved, can be used in the future
only for things that are safely ignored". That is actually a
rather significant change.
john
Not having well defined behaviour for reserved bits actually makes
them harder to use in the future. RFC 103[45] doesn't say what to
do when the last reserved bit is used. Today we have queries
dropped, FORMERR'd, REFUSED'd, NOTIMP'd, and ignored. I really
don't care if the response is FORMERR, NOTIMP or ignored but we
should choose one and stomp out the others so that when we decide
to use the bit we don't have the mess [1] we had with the other
bits. REFUSED seems to be a bit of a odd ball choice and dropping
the query is just not on. DNS is after all a query-response protocol.
The last reserved flag bit should never appear in the reply of any
current nameserver as there is no reply construction path that sets
it in any RFC but there are implementations that incorrectly copy
the bit. There isn't any text that says "copy reserved bits to the
reply". The "id" field should be enough to identify the reply.
This includes FORMERR, REFUSED and NOTIMP replies.
Perhaps this should be reduced to "MUST NOT copy the reserved bit
to the reply if presented in a query".
BIND 9.11's dig (source.isc.org master branch) has a +zflag which
can be used to test server behaviour.
For comparison EDNS formally ignores unspecified/reserved EDNS flag
bits and also states do not return them in the reply if they are
set in the request (this was in the initial specification). Similarly
unknown EDNS options are defined as to be ignored (the updated
specification added this).
[1] queries with ad=1 set get dropped by some servers. ad=1 gets
blindly copied to the response without validition occuring and the
result being secure.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org