[RSSAC Caucus] Metrics: Correctness of data

[Fred Baker]

On Jul 22, 2019, at 1:46 AM, Fred Baker <fred at isc.org> wrote:
> I think there may also be value in proving that the RSO in question delivers *all* of the resource records that IANA includes in a zone transfer, and that it delivers *only* the resource records that the IANA would include in a zone transfer.

Let me follow up on this. I'm looking at two reports:

https://dl.acm.org/authorize.cfm?key=N687421 from https://irtf.org/anrw/2019/program.html

Reports in the DoH space about downloading the IANA zone and distributing it in that fashion, and the service also being used to store TXT records used by botnets (https://www.bleepingcomputer.com/news/security/new-spam-campaign-controlled-by-attackers-via-dns-txt-records/). 

The first is not quite an assertion that it is known that DNS requests and/or responses are being changed in flight, but it states that the researchers in question had a "large" service to test against that was doing that. DNSSEC is probably the proper test for that - data changes in flight would no longer have a valid DNSSEC signature.

The second reports that the Google DOH server is being used as a repository and server for TXT records controlling botnets. I'm certain that Google would immediately respond that it is not their intention to support that. That said, there is evidence that it is in fact the case.

A relatively simple solution to that might be to take a note out of the OSPF MIB, which reports a checksum the LSA Database. I imagine that a DNS server might hold more than one zone, and *a* zone that it holds might be the TXT records in question. But when a DNS Server is queried, the request doesn't specify a zone; it merely asks whether the server has a resource record for the indicated name. So I find myself thinking of something a little more complicated than a statement regarding the root zone. Imagine:

   A response listing the zones stored at the server (presumably attained by an XFR), 
   and for each such zone, 
        The relevant sequence number,
        the number of RRs held, and 
        an MD5 checksum of those RRs. 
   For the purposes of the checksum, the TTL in each record needs to be zeroed.

The probe can now ask for that table and compare it to what it believes to be correct. It could also contain the sequence number of the dataset transferred in the XFR.

Like the OSPF LSA Database, this should at least in theory be a quick and almost null check - "do you have the right answer? OK, yup". However, in the unusual case that the answer is incorrect we can know quickly and without a lot of doubt.

If there is support for that, I'd be happy to sketch text into the Google Doc.