Re: [dnsext] Draft: RRTYPE B - Web Resource Integrity

[Robert Elz <[e-mail]>]

Beyond what Mark said, which I was going to include here, with less
detail, but now don't have to - Thanks Mark...

The proposal seems to assume that two different objects (this proposed
new DNS resource, and the web page to which it refers) can be updated
synchronously somehow - the DNS doesn't do that, it takes a definitely
measurable period of time for any data in the DNS to be altered, old
copies are still present at secondary servers for some period after
the primary is updated, and caches all over the planet don't even look
for updates until the TTL on the last answer they had received expires.

As described (and other than in local, single server, testing) this
scheme simply cannot work reliably.

I'd expect that you'd want to allow at least 2 (perhaps more) of these
records to exist, and consider a page valid if any of them provides the
correct hash - that way the hash for an updated page can be installed,
then wait for that to have propogated (sum of secondary reload time,
plus TTL expiry) then update the page, then it should be safe to delete
the old entry.   Allowing for more than 2 to co-exist might be needed
if two quick changes were needed to the web page, that is, a new version
while still waiting for the previous one to be ready to be installed,
but after its resource record is already in the DNS (haven't really
thought through all the possible scenarios, but someone needs to).

I don't understand the purpose (that's just me, I don't follow much
security or web related stuff at all, and so anything which is those
two combined is guaranteed outside my area) - but why the insistence
on only covering the root page at a domain name?   As I understand the
way many web servers overate, there is often no such page, and any
valid URL at the server must have some kind of path appended to the
domain name in the URL to receive a meaningful answer (that is, a
non-error reply of one form or other).

kre