[dns-operations] Questions on DNS Flag day 2020 proposal

Mark Andrews marka at isc.org
Thu Jul 4 23:16:59 UTC 2019

> On 5 Jul 2019, at 4:44 am, Dave Lawrence <tale at dd.org> wrote:
> Tony Finch writes:
>> You cannot apply RFC 2119 pedantry when reading older RFCs. Especially
>> when reading RFC 1035 you will be more correct if you treat "should"
>> as having the force of MUST unless you have clear evidence otherwise.
> Definitely agree with the first bit, insofar as it has to be
> intrinsically true that you can't use 2119 to interpret RFCs that
> predated it. I wonder how it is that you have come to the conclusion
> that a pre-2119 "should" has the force of "MUST".  Is this supported
> by other documentation to that effect, or only a personally held
> opinion?  Either way it must also be noted that ...
>> Also you can't ignore updates to RFCs; in particular the part of RFC 1035
>> you are quoting is amended by RFC 1123 (STD3) and RFC 7766.
> 1123 section made it quite explicit that DNS/TCP was a SHOULD,
> which seems to provide "clear evidence otherwise" that 1035 didn't
> mean it as a MUST either.  7766 was in necessary in very large part to
> address that very issue.

Well RFC 1123 really fails to enumerate all the cases where TCP is necessary.

While it mentions RR too big it fails to mention referrals that are too big
but they are just as important. Glue records are not optional.  Referrals should
be setting TC=1 if glue does not fit.  The same applies to priming query responses.

If you analysis RFC 1123 you will see that TCP is mandatory for recursive servers
because they have control over RRset sizes (both client and server sides).

RFC 1123 also says that you must accept UDP answers from servers you didn’t send
the query to which is just plain ludicrous.  That was to work around multi-homed server
binding to rather than each interface individually.

Today if you support UPDATE, DNSSEC, or DNS COOKIE then TCP is a MUST.

UPDATE because you have no control over the request size.  Sane client switch to
TCP once the request exceeds 512 bytes.
DNSSEC because many signed answers exceed 512 bytes and before you say EDNS many
DNSSEC answers exceed common EDNS buffer sizes bigger than 512 bytes.
DNS COOKIE because TCP is the fallback for too many BADCOOKIE responses.

If you are a third party DNS operator you have no control over the response sizes
so TCP is MUST there.

SHOULD is also described as:

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

and I’ve yet to see anyone do a proper analysis.  I doubt the operators of servers
sending back TC=1 but not having TCP reachable really intended to have lookups
for that RRset fail.  I know 99.9% of those saying we don’t have to do TCP because
RFC 1123 says that it is a SHOULD haven’t done the analysis.  Everyone that says
TCP is only for AXFR hasn’t.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org

More information about the dns-operations mailing list