Tony Finch wrote: > If the response would be NOERROR / NODATA and the zone is not signed, > synthesize a NULL RR and use that as the answer.
It seems a little bit off to re-use the NULL RRtype, which has been reserved for experimental use, for this. There are at least some (marginal) uses of the type, e.g., the popular DNS tunneling tool "iodine" [0] will make use of NULL RRs. Which is perfectly OK, it's marked "experimental", after all. This fact might be used by security monitors as a detection signature (e.g., [1] explicitly notes the use of NULL RRs by iodine), just like qtype=*. (Just noting this possibility, not passing judgment on whether such signatures are a good or bad idea.) "NULL" is hard to grep for in the commit messages, source code, and documentation of C/C++ based DNS software implementations, due to the obvious overlap with the C preprocessor macro of the same name, and the use of the word "null" in other DNS terminology (e.g., "the null label of the root"). I also note BIND appears to accept NULL RRs in zone files, even though RFC 1035 says "NULL RRs are not allowed in master files." Knot 1.4 rejects NULL RRs in zones. (I tried searching for a later RFC that might mention NULL RRs but ran into the aforementioned terminology conflict.) Anyway, I recommend that the NULL RRtype be completely preserved for experimental uses and that a new RRtype be specifically allocated for the exclusive purpose of these synthetic responses, and that its definition require that it MUST NOT appear in zone files. Perhaps "GNDN" would be a good mnemonic, for the obvious [2] reference. [0] http://code.kryo.se/iodine/ [1] http://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152 [2] http://en.wikipedia.org/wiki/Jefferies_tube -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
