Post IETF - determining 5011 support - part 1
Paul asked me to drop a note to the list describing a few techniques that I think might be used to determine whether a querying entity supports 5011. This email describes detection through the use of the REVOKE bit. (Note that I haven't tested any of these - but they should work 1) Assume that non-5011 entities silently ignore the revoke bit 2) Per 5011, the revoke bit applies to ALL DNSKEY records, not just the root KSKs and you're not allowed to trace a chain of trust through a revoked key. 3) In a non-root zone, set up a delegations to two zones - "valid" and "invalid". 4) Set the valid zone up with the normal KSK/ZSK pair in the DNSKEY RRSet. Set the invalid zone up but with the ZSK having the revoke bit set. Create the RRSigs as appropriate and remember to have the ZSK in the invalid zone also sign the DNSKey RRSet (to cause the key to be revoked). 5) Seed both zones with various A/AAAA and CNAME records. 6) Place web servers at the location pointed to by each of the A/AAAA RRSets and at a place pointed to by the CNAME record. 7) Seed a popular web page (get Google or some other high traffic name to help) with URLs that point to items (say a JPG) served by each of the web servers - avoid having anything else at those servers but these items. 8) Collect logs on the DNS server and on the web servers over a period of a month or so. 9) Do the analysis. Items retrieved from the server pointed to by the A/AAAA RRSet signed by the revoked ZSK are probably being pulled by clients served by resolvers that don't do 5011. Correlate the times of DNS query with times of web queries - you'll mostly pull up the first query from a given resolver before it caches the answer. Pairing an invalid URL (in the sense that DNSSEC should prevent its retrieval) with a valid URL allows for a check against false negatives. If the correlation by log analysis doesn't work - have the dns server return dynamic addresses for the web server that encode the resolver's identity in some manner. (For example, by twiddling the CNAME so that a browser generates an SNI with the resolver identity encoded for a TLS connection). So: Client that sees web pages pointed to by both valid and invalid zones is probably being served by a non-5011 resolver. Client that sees only web pages pointed to by the valid zone is probably being served by a 5011 resolver. Client that sees either neither of the web pages or only the invalid web page is probably being served by a broken resolver. Mike
Michael StJohns <msj@nthpermutation.com> wrote: > 7) Seed a popular web page (get Google or some other high traffic name > to help) with URLs that point to items (say a JPG) served by each of > the web servers - avoid having anything else at those servers but these > items. Essentially what Geoff Houston did, right? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
7) Seed a popular web page (get Google or some other high traffic name to help) with URLs that point to items (say a JPG) served by each of the web servers - avoid having anything else at those servers but these items.
That is indeed a challenge. In my experience high traffic web sites are exceptionally wary of embedded items that direct clients to other sites. The reason why we turned to ads in the APNIC measurement work was that try as we might we just couldn’t find a way that would allow popular web sites to work with us in this manner. Geoff
On 18-11-12 12:55, Michael StJohns wrote:
1) Assume that non-5011 entities silently ignore the revoke bit
I suppose that modern resolvers do honor 5011 (e.g. revoke bits) even if there are static anchors in their configuration. So you may want also assume that those resolvers have (in Unbound lingo) 'auto-trust-anchor-files' configured and *not* 'trust-anchor-files'. Miklós --
participants (4)
-
Geoff Huston -
Michael Richardson -
Michael StJohns -
PASZTOR Miklos