November 2018 - ksk-rollover

Post IETF - determining 5011 support - part 1
by Michael StJohns Nov. 13, 2018

Nov. 13, 2018

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

4 3

Post IETF - Determining 5011 Support Part 2
by Michael StJohns Nov. 12, 2018

Nov. 12, 2018

5011 defines a very specific timing domain for (see section 2.3 of RFC5011) doing refresh of the trust point key RRSET and that active refresh is both mandatory and easily distinguished from normal dns cache timeout/requery intervals. One possible way of identifying 5011 resolvers would be to do timing analysis on the root server logs. Specifically: 0) Time sync all of the roots. 1) Aggregate all the logs from all root servers for a 30 day period. 2) Sort by resolver IP and timestamp. group by resolver IP. 3) For each resolver, calculate the inter-arrival interval times between queries and compare that to the predicted/configured 5011 values. A 5011 compliant resolver that's also caching should be querying the root about 1/2 the TTL of the dnskey RRSet. Again, haven't tested this and implementers may have taken liberty with the refresh protocol, but its a place to start. And yes, I know this is a massive data set to wander through.... Mike

1 0

Informal meeting at IETF 103
by Paul Hoffman Nov. 11, 2018

Nov. 11, 2018

There will be an informal discussion of DNS root KSK futures at IETF 103 on Friday, November 9, at 0900 local (Bangkok) time in room Chitlada 3. The purpose is to allow IETF participants to ask questions and propose ideas for how the DNS root KSK should be maintained in the future. Suggestions from the mic lines at recent meeting include suggestions for fixed rollover schedules, suggestions for data collection before the next rollover, standby KSKs and how they would affect the rollover schedule, and how resolver software vendors' actions can be taken into account. The discussion is expected to last for one hour or less. Unfortunately, there is no remote participation for the Friday sessions, so the meeting will be limited to those in the room. However, I will make a recording to create notes on what is said. --Paul Hoffman

11 21

KSK Roll outreach to enterprise DNS operators
by Kal Feher Nov. 9, 2018

Nov. 9, 2018

I raised this topic at the IETF103 ksk roll meeting (Wednesday edition). I was asked to submit this to the list so here it is. I'd spoken to a lot of non-ISP DNS operators prior to the 2017 roll date and again prior to the actual 2018 roll. These resolver operators would fall into two categories: * Government agencies * Enterprise IT While some had heard of DNSSEC, most were unaware of the key roll (true for 2017 and 2018). There were several cases where the operator was validating but was entirely unaware of that fact. They'd deployed DNS software somewhat recently and accepted the defaults. I'm taking into consideration Geoff's point that it might take 3 or more roll over attempts to achieve truly smooth roll overs. So if we agree that at least the next two rolls (plus or including algo roll) require operator awareness, I have two points related to the lack of awareness amongst this specific kind of non DNS expert operators: 1. I think ICANN's outreach needs to include focus on channels consumed by enterprise IT operators. More mainstream media should be involved. This might cost money if it requires paid for articles. Many enterprise technology companies disseminate updates and industry trend information via their certification and software subscription membership channels. Ideally the next key roll could feature prominently in those materials. 2. A regular key roll schedule might help ease the communication burden for any one key roll. In some ways it will allow us to benefit from previous outreach efforts, if those efforts draw people's attention to a calendar of key rolls. Even a rough calendar would help. Ideally it has a permanent web location. I'm aware that there are challenges faced with getting ICANN's board to commit to a roll over well before the date, much less a rough schedule. However I think most outreach efforts will be more effective if conducted after the board has approved a roll. Of course, the true goal should be for no one to need to know that a roll over will occur. -- Kal Feher Melbourne, Australia

1 0

(no subject)
by Axel BorgDuca3 Nov. 7, 2018

Nov. 7, 2018

Can You Please have new Digital Wifi? Sent from Mail for Windows 10 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

problem report: couple broken Turris Omnia installations
by Petr Špaček Nov. 7, 2018

Nov. 7, 2018

Hello, here is anecdotal information about tiny problem caused by recent KSK rollover: Turris Omnia routers by CZ.NIC are shipped with DNSSEC validation enabled by default. KSK-2017 was distributed to Omnia installations using built-in automatic software updates months before the actual rollover. Yet we saw couple individual users reporting problems after the rollover and at the same time vast majority of users did not have any problem. Further investigation yielded nothing useful so I can only share list of possible explanations we came up with: - system restore close to rollover event using old configuration backup - messed up system upgrade Unfortunatelly there is no wisdom to share. -- Petr Špaček @ CZ.NIC

1 0

resolvers with KSK-2010 only working as forwarders
by Petr Špaček Nov. 7, 2018

Nov. 7, 2018

Hello, here is one more wild guess/attempt to explain KSK-2010 only resolvers: Some of resolvers which RFC8145-report having only KSK-2010 [1] might be used as forwarders in some larger DNS caching topology, e.g. inside a company networks. Recent versions of Knot Resolver and I believe also Unbound set CD (Checking Disabled) bit when forwarding queries to another resolver, so intermediary resolver with KSK-2010 only would not cause resolution failure on these "leaf" resolvers. I seriously doubt this can explain all of KSK-2010 only resolvers but it might be a contributing factor. [1] http://root-trust-anchor-reports.research.icann.org/ -- Petr Špaček @ CZ.NIC

1 0