Re: [ire] Extended verification process of the escrow deposit files

[Christopher Browne <[e-mail]>]

On Thu, Dec 13, 2012 at 7:28 PM, Gustavo Lozano
<[e-mail]> wrote:
> In case of differentials deposits, the escrow agent shall use the last full
> and all the differentials deposits to perform the extended verification
> process.
>
>
> I am interested in your feedback regarding:
>
>  1. Other tests that you consider should be present in the draft.

In keeping with James Mitchell's comments about "the quick brown fox
jumps over the lazy dog", which could be set as a domain name, which
may be "structurally valid," but structurally nonsense, I would
suggest that mere comparison of escrow deposits is nowhere near
sufficient.

We could have a near-infinite number of policies, for each bit of the
escrow format, and someone with a Markov Chain generator could make up
a conforming escrow file out of random, but still policy-conforming,
junk.  Verifying that it's not just junk requires looking to other
sources such as WHOIS or DNS.

I daresay I have seen all the cases he mentions as problems, and more.
 Most typical and painful to resolve is to receive phone numbers not
complying with the ITU E164 standard. My "favourite" was receiving
contact <contact:id> values that did not conform to RFC 5733, so that
I had to remap them to new values in multiple places before
proceeding.

A more legitimate test would be more "end-to-end"; it would compare
escrow with other notionally authoritative sources.

The approach that comes to mind is to select data from 4 sources and
make sure that they match:

The data sources:

1.  Escrow is the one that is obviously at hand;

2.  Zone files tend to be not difficult to obtain, and they indicate
the state of the resolving portions of the 'portfolio' of domains in a
registry;

3.  WHOIS reports information on the state of the registry, albeit on
a one-by-one per-request basis;

4.  Submitting DNS requests to the authoritative DNS resolver for the
registry returns authoritative information on resolution information
for active domains.

#1 and #2 (perhaps just #1) are available "en masse", for the entire registry.

A test that escrow matches against the registry would be to pick a
sample of domain names from sources 1 (escrow) and 2 (zone file), and
agree them against WHOIS (#3) and the DNS resolver (#4).

It would not be reasonable to try to do this with all names in the
registry; a reasonably small statistically random sample should, if
collected regularly, provide confidence that samples taken from escrow
match against the "real data" in the registry.  Using stratification
would be appropriate to make sure that different sorts of cases get
examined (or perhaps avoided - it's desirable not to have many "false
mismatches" as would happen when objects legitimately change between
the time escrow is dumped and when validation tests are done.)

Over time, a validation involving doing a domain data reconciliation
of even as small a sample as a few dozen names per day should provide
useful assurance that the sources are not vastly out of sync,
particularly if discrepancies get escalated into larger targeted
samples.  Note that this is the standard sort of thing you'll find in
literature on auditing procedures.