> On 24 Mar 2018, at 22:55, Mukund Sivaraman <m...@isc.org> wrote: > > 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.
I knew somebody would notice my “hyperbole”. > Some things to think about for DNS complexity: These are harder to tackle, and I thought beginning with something simple would be … simple. > * 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. ECS is optional feature and DNS vendors could decide whether the want to implement ECS or not. > * 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. I agree that making this simpler would be a good thing, but we’ll have to "not generate, but accept” first approach here. > * 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. Ack. > * 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. BCP perhaps? E.g. write BCP on how to generate good DNS message? > * 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. A document that would say that DNS Compression might or might not happen aggressively would be useful. But then perhaps it would just add more RFCs to read, when some implementors do just read wireshark... > 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: I think this is required, but it also requires a funding for somebody to lead the effort, because most of us here have a day-to-day job that have higher priorities than creating new WG, rewriting old DNS standard and then arguing for years, which _is_ going to happen :). Ondrej -- Ondřej Surý ond...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
