Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Mukund Sivaraman <[e-mail]>]

Hi Ondrej

On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote:
> > It might be a different story if one of those zombie RRtypes required additional processing. None spring to mind though.
> 
> But (most of) those I picked actually *DO*:

In the case of RR types, "additional processing" means type specific
behaviors that do not usually apply to other types. For example, CNAME
has additional processing. The following processing is common to 1035
types.

> a) compression is allowed, so compliant and non-compliant servers can’t speak together, because non-compliant will just store junk in the RDATA when received from compliant server;
> b) the RDATA needs to be understood and lowercased for canonical form when DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it would cause validation failures if you don't
> 
> And all this extra work must be done for RR Types that are unused in current protocols. The implementation for these M* types isn’t just wire<->human readable translation.

These types can go in any future 1035 bis draft, in support of what
you're asking because they are obsolete.

But as it stands, RR types (except additional processing) are typically
implemented in software as an RDATA interface with type specific
implementations. Removing these types will mean rm -f'ing some
implementation files/classes, which certainly reduces the quantity of
code but does not affect complexity of the nameserver as other types
require similar common RDATA processing anyway. In this regard, other
commenters are right in observing that it doesn't affect complexity
significantly.

Any proposal that has a draft written can get an RRTYPE assignment
approved and these appear from time to time - it doesn't affect
complexity unless there's additional processing.

Some things to think about for DNS complexity:

* Obsoleting CLIENT-SUBNET.. as mentioned on a BIND ticket,
  CLIENT-SUBNET flies in the face of where DNS is headed (towards more
  privacy). If every user used the resolver on their own network,
  there'd be no need for this facility. It's only when forwarders and
  caches (that are arguably anti-privacy) from outside the network come
  into play, that CLIENT-SUBNET becomes necessary. We as DNS community
  should push towards validating resolvers closer to devices.

  This is even without discussing CLIENT-SUBNET's design issues, for
  which alone it can go. There is a LOT unwritten in CLIENT-SUBNET RFC.

* TSIG extras: In TCP continuation (multiple DNS messages such as
  during AXFR), TSIG allows some intermediate messages to be sent
  unsigned without TSIG RR, and a following TSIG RR to cover all such
  intermediate messages. There is no need for such a thing in today's
  world. BIND and Knot do not generate such TSIG signed continuations
  with gaps (though BIND can parse them), whereas NSD does generate
  them. It is just an extra variant to save little space that adds
  implementation complexity.

* TSIG extra extra: TSIG allows truncated MACs which just is ugly.  Some
  DNS messages may overflow the PMTU or the client-specified EDNS UDP
  buffer size if the full MAC is specified vs. the truncated MAC but
  this is such a corner case with little benefit compared to complexity
  of handling this facility, checking truncated limits, etc. And extra
  BADTRUNC rcode, etc.

* Revising the DNS message format would be a no-no, but there're
  redundancies there (repeating owner names [even if they can be
  compressed], class, type, TTL, possibility of TTL mismatch among RRs
  of a set, etc.). RR class is extra complexity for the most case on the
  internet. RRs can be out of order of sets.. it is ugly to parse. DNS
  message processing/rendering is inefficient due to the redundancies.

* Name compression (aggressively done) is inefficient and takes up a
  significant portion of runtime, and there has been a lot of to and fro
  on type-specific rules. RFC 1123 requires name compression, but one
  might as well abandon it and put out names in full, esp. over
  TCP. It'll eat more bytes, but not much compared to Youtube and
  software updates.

* All these new additional answer / additional section multi-RR
  proposals.. if you ask me, I don't want it in our DNS implementation.

-----

Language in RFCs of the time of 1034/1035 is underspecified. We're
counting pages, but one way to reduce confusion about the protocol is to
_add_ more details and write a bis using 1034/1035 + ncache + edns +
clarifications, etc. with modern language and extra detail.

As an example, I was asked by a colleage a couple of days ago if any
RFCs required that, if the answer section of a reply had:

(1) a valid answer RRset matching the RR type that was queried, and
(2) _other_ RRs that are unrelated,

then should the reply message be discarded?

While this may be classified to be "common sense", this case does not
appear to be specified, and it was a valid enough question for someone
to ask about it. RFC 1034 has ambiguous language which can be
misconstrued to mean anything:

> Step 4 involves analyzing responses.  The resolver should be highly
> paranoid in its parsing of responses.

However, back in its day, the synthesized CNAME for DNAME replies would
be totally meaningless if there was a type mismatch and a resolver
implementation of that day threw away a response if an unrelated (and
back in the day unknown) DNAME type was found in the response.

There are details in DNS implementation code on how to handle cases that
are not specified in RFCs. A modern document should specify more
behaviors clearly, which would increase its page count, but also
increase understanding.

		Mukund