Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, John C Klensin writes:
> 
> 
> --On Sunday, February 22, 2015 07:51 +1100 Mark Andrews
> <[e-mail]> 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: [phone]                 INTERNET: [e-mail]