Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt
On Sun, 19 Nov 2017, JW wrote: Hello, This draft was released a couple weeks ago and includes what we feel are some very noteworthy changes. Please take another look when you have time, as always we look forward to and welcome any questions/ comments. I am disappointed I was unable to join the group in Singapore but am optimistic I'll be able to meet again in London. Hi, I am brought here because of the notification of this in v6ops. I am supportive of the general idea of having these kinds of bulk records standardized. I read the draft, and if I understand correctly it currently proposes to not have DNSSEC support without on-the-fly signing. I am extremely opposed to introducing new features into DNS that doesn't support DNSSEC. Going from not supporting DNSSEC to supporting DNSSEC on your device/server/whatever should never mean you lose features. So if anything new is proposed that doesn't support DNSSEC (at least on the server side), then we need to have a "let's deprecate DNSSEC" discussion at the same time. If the consensus is that we shouldn't deprecate DNSSEC, then whatever feature is proposed that doesn't support DNSSEC needs to go back to the drawing table. With that in mind, I'd rather have this feature be a new RR type that would involve not generating records on the fly at all, but instead sign this RR type using regular DNSSEC, and then the resolver needs to be updated in order to actually use/understand this new RR type. I know this (probably) brings in another world of hurt as now (I guess) the resolver needs to fake PTR entries towards internal APIs that don't support these bulk RRs? Anyhow, suggesting this without support for offline signed zone files is a no-go for me (unless that of course is deprecated and we're saying DNSSEC now is all about on-the-fly signing, then that discussion of course changes). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
On Fri, 1 Dec 2017, Steve Crocker wrote: Let me make a guess that the only lengthening that takes place in practice is a floor of ten seconds. Comments? I might be misinterpreting, but from the data presented in the graph in section 3.2 it looks like some will increase TTL to 7200 seconds at the highest. There seems to be large bumps at the 600, 1200 and 1800 second "minimum TTL" capping (if I guess correctly from looking at that graph). It would be interesting to hear what problems these operators are trying to solve by implementing these minimums. 7200 seconds does seem like a pretty high value to lower bound TTLs at. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] KSK rollover postponed
https://www.icann.org/news/announcement-2017-09-27-en Thought this might be relevant to some. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
On Wed, 16 Aug 2017, Davey Song wrote: Accroding to your description, I feel that IPv6 has better chance to win than its "brother" DNSSEC. LoL Currently they're both winning, and in kind of the same fashion. https://www.google.com/intl/en/ipv6/statistics.html Clients are sitting behind DNSSEC validating resolvers, but there are few zones to validate (apart from in a few markets, like .se and .cz). Clients are more and more getting IPv6 enabled, but the long tail content is not being enabled, and neither is the enterprise. So generally, enterprise is problematic in both spaces. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
On Wed, 16 Aug 2017, Mukund Sivaraman wrote: The validating resolver is half of the system. DNSSEC is brittle. Absolutely. But before we were in a situation where people signed zones, screwed it up, and then the (sometime single) ISP running a validating resolver got the run-around "must be wrong at your end, nobody else is complaining" and the zone signing was never fixed. Now I think we're past that. There are enough users behind validating resolvers nowadays that you can't get away with getting your signing wrong and blaming others. Yes, we need better APIs so applications can tell the user what went wrong, instead of just throwing a DNS failure. If there is need to update the DNS specs for this to be possible, then that should be done. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
24 / 500 top domains (4.8%)
20548 / 1 million top domains (2.05%)
(12 years after introduction of 403{3,4,5})
https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1
20% of European users is behind a validating resolver, in some countries
it's 70% plus.
So this is now happening, albeit at a not high enough pace. But at least
it's going in the right direction, and I do believe that there is enough
people behind validating resolvers that people can't mess up signing their
zone and push away blame on who needs to fix things.
So at least there is benefit in signing your zone now, there wasn't as
much before when nobody was validating.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic refresh and Happy Eyeballs
On Tue, 15 Aug 2017, Ted Lemon wrote: If it's a commonly-used name, isn't this a one-time event, though? The happy eyeballs client asks for A and , gets A because it was in the cache, but also winds up in the cache, and then because it's a commonly used name, neither record ever goes stale again. That was the assumtion by a lot of people who aren't DNS experts (including me). Mark Andrews brought up that this might be a more frequent issue that people think. Also there is the issue that as the TTL becomes 0 and the RR is now no longer in cache, next question will trigger a lookup and if the authoritative nameserver is 400ms RTT away, then during these 400ms a lot of clients might only use IPv4 with current RFC6555bis proposal. So there are two things here I see: 1. Opportunistically refresh RRs before they expire. I've been told some resolvers do this already. 2. Tie together A and so that if one is asked for, make sure there is an up-to-date of the second one as well, at least make sure it doesn't expire even if it's infrequently used. I guess this means take into account A questions when deciding whether to refresh that you might have? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] opportunistic refresh and Happy Eyeballs
Hi, we've had a discussion on V6OPS (https://www.ietf.org/mail-archive/web/v6ops/current/msg27337.html) where Mark Andrews has brought up the topic of caching DNS resolvers not being populated with A and information at the same time, or the TTL might expire at different points in time, thus causing the Happy Eyeballs algorithm to use IPv4 more than IPv6 because of the 50ms total timer of DNS lookup+TCP initation. I had a look into this, and there are some drafts regarding opportunistic refresh of information to try to avoid records expiring, and instead refreshing them before they expire. One I have found is https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 There was another opinion in the discussion (https://www.ietf.org/mail-archive/web/v6ops/current/msg27356.html) that caching resolvers should try to keep and A cached as long as one of them is being asked for. Currently I believe there is no such "coupling" between RR types? What is the opinion of this wg on that topic? I believe the best solution for the problem statement in Happy Eyeballs is a solution that needs to change behaviour both in the client (DNS lookups and TCP session initiation) but also in the resolver. If we can have a reasonable expectation that the caching resolver is always "hot" when it comes to frequently used A and records, that would mean we'd need less DNS lookup delay, waiting for both lookups to complete before deciding what to do regarding IPv6 and IPv4 TCP session initiation. Right now RFC6555bis proposes a 50ms head start for IPv6 (DNS lookup+TCP init), which IPv6 will lose if the DNS resolver is expired and the A is cached, and the authoritative DNS server is far away TTL-wise. However, introducing a really high head start for IPv6 in this setup is not desireable either, let's say 500ms head start to handle that the authoritative DNS server is 400ms RTT away. This would give a bad user experience in some other cases. Thoughts? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Wed, 30 Nov 2016, Matt Larson wrote: Did you see my message earlier in the thread? Is there a reason you don't include a third option: retrieving the trust anchor file published by IANA/PTI (https://data.iana.org/root-anchors/root-anchors.xml) and validating with the detached S/MIME signature published in the same place (https://data.iana.org/root-anchors/root-anchors.p7s)? That signature chains to the ICANN CA cert, which currently expires in 2029. Sure, it's more code, but it can all be done with OpenSSL, for example. This sunds like a workable solution. It would be great if ICANN could write a document outlining how to do this and perhaps even provide FOSS example code. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Thu, 17 Nov 2016, Ondřej Surý wrote: Mikael, the operation of the root zone and signing of the root zone is in the ICANN/IANA bailiwick. Therefore most of the relevant document to the RZ DNSSEC operations can be found at https://www.iana.org/dnssec/ and the document you are most interested in is here: http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html + the files https://www.iana.org/dnssec/files It might be worth letting them know if you feel that the documentation is incomplete or inaccurate. That document lists where I can get stuff. It doesn't list any procedures or recommendations how I would get from my non-DNSSEC working state (or even suggestions how I understand that I am in that state and it's because my key material is too old) , perform some operations, and now I understand that I am in a working state. That's what a BCP could do. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Thu, 17 Nov 2016, Ted Lemon wrote: Embedded systems of this sort need to have a management process so that that can be updated. This is needed for more reasons than DNSSEC. Putting a ten year old device on a network without upgrading the firmware is irresponsible. We have been discussing zerotouch (ie 0 day no-human-intervention plugin of device). This includes the device configuring itself by means of different methods, and also software-updating itself before it starts to provide any services. DNSSEC (possibly DANE) has been proposed to be one way of finding this configuration. This is now obviously out of the question unless the problem I described can be solved. So this all boils down to: Do the people involved in DNSSEC want their protocol to be part of the long term solution of securing boostrapping things? Yes? No? Right now the answer is no. 9 months shelf life and then DNSSEC fails is just not usable for things that don't have active human intervention in its configuration and setup. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Wed, 16 Nov 2016, Bob Harold wrote: This is not well thought out, but what jumps to mind is to keep a chain of signatures in the root DNS that links from the original KSK up through the current KSK (or at least the last 10 years). Perhaps a different record type, so it is only sent if asked for. Does that make any sense? Someone told me that the information needed could be gained in replaying a root zone packet from every 3 months since when DNSSEC was originally developed (or at least from when whatever this proposed solution was done). That seems to be similar to what you're thinking of here. Can we get a solution that does that, that isn't a DDOS amplification vector or something else hugely problematic? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Wed, 16 Nov 2016, George Michaelson wrote: I feel this is a corner case. My experience with 'mom' whitegoods is that they age out much faster than the 10+ year case. Shops do not hold electronic goods for sale that long, if its old but unboxed, you have taken yourself into a dark alley deliberately. If you genuinely were supporting your mum by buying two, and keeping one offline for 10 years you would have done better buying one, and replacing after 5. Ok, so let me ask an operational question: The way current root zone key rollovers are thought to be used, what's the theoretical shortest worst-case shelf life of a device that relies on DNSSEC working for itself to work properly? So if it's manufactured the day before a new key is publically released, when is the key material it has built in no longer viable to have successful DNSSEC validation? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
On Wed, 16 Nov 2016, Ted Lemon wrote: Why would you put a device on the shelf for ten years? Is this a real scenario? This is certainly a known issue that has been talked about at length--the conclusion when it was discussed is that there is nothing we can do about it, and it's relatively unlikely, and manually fixable. How is it manually fixable? By someone to ssh into the device and edit a file with new key material? My mom can't do this. I have personally picked a Cisco AGS out of a unopened box in 2010. By then it was probably 15-20 (?) years old? Anyhow, my takeaway from this message is that DNSSEC can't be used as a mechanism for device autoconfiguration. No device trying to autoconfigure itself can rely on DNSSEC, because there is a fairly short (few years) window for that device to get plugged in, because after that it can't autoconfigure itself. Correct? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSSEC operational issues long term
Hi, today I have discovered something after talking to some people that know more than I do. Example: I go to the store and buy two DNSSEC enabled devices that rely on DNSSEC working for them to work. I put one device on the network immediately and the other one on the shelf. The one I plugged in works just fine for 10 years because it has RFC5011 support. Now after 10 years after plugging the first one in, I take the second one off the shelf and plug it in. It will now not work because there has been a root zone key rollover. I am told this is by design. This makes me a sad panda. We have a bootstrapping problem. My device has no way to know what time it is so it can't verify certificates that might be used to update the key material, and by above design decision, DNSSEC doesn't work. I had some idea that DNSSEC could be used to sign a distribution of roughtime (have someone sign a DATE+TIME TXT record so I at least know approximately what day and time of day it is), so I could verify certificates and then bootstrap myself that way. I believe that this property of DNSSEC (put on shelf, take from shelf in 10 years, device now not working properly) is not well known in the wider IETF community. Is this documented somewhere in plain text that everybody will understand? What's the current thinking of what a user should do with a device that has only old root zone key material? Is there any guidance to vendors on what they should instruct users to do in order to make their device work again? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ECDSA woes
On Sat, 15 Oct 2016, Ólafur Guðmundsson wrote: I have domains signed by all combinations of signing algorithms and DS digests as well as Nsec variants Ds-n.alg-m-nsec.dnssec-test.org Replace n with 1..4 M with 1..14 Nsec is one of Nsec nsec3 none I'd be veryinterested if you could create an algorithm called "99" (or something), and we could test that. Anyone not loading the "99" resource is violating the "SHOULD", even if they understand ECDSA. This would investigate ratio of problems when we want to introduce a new algorithm in the future. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ECDSA woes
On Sun, 16 Oct 2016, Geoff Huston wrote: so I have three tests: A: a validly-signed ECDSA P-256 domain B: an invalidly-signed ECDSA P-256 domain C: an unsigned control now if the resolver does NOT recognise ECDSA we should see a fetch for A, B and C (as they treat both A and B as if they were unsigned) if the resolver recognises ECDSA we will see a fetch of A and C but not B and if the resolver incorrectly returns SERVFAIL when it sees ECDSA (which I presume is what DNSMASQ 2.71 is doing) then we should see only C and not A or B The report generated uses these definitions to determine if a user is passing their queries to ECDSA-aware resolvers So thats the long answer to yes, this error is caught by these tests, and the error is put into the “does not do ECDSA” bucket. Ok, thanks! It seems to me that anyone not loading A or B, but loads C, is of high interest. They're obviously behind a broken resolver. Could you please try to create two buckets out of the "does not do ECDSA", one being "doesn't understand ECDSA, loads invalid resources" and "doesn't load ECDSA resources regardless of valid or not". I'm very interested in the last of these two, because they're hindering rollout of new algorithms. I'd like to understand how big this breakage is. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ECDSA woes
On Sat, 15 Oct 2016, Ralf Weber wrote: Geoff Houston did some research here some years ago and just did an update to his findings. You might want to look at: http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html Do we know how many experiments failed because the resolver erroneously reported error for ECDSA signed domains? From reading Geoffs text, it's not obvious to me that this error case is caught by his tests? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ECDSA woes
On Sat, 15 Oct 2016, Ray Bellis wrote: I hadn't considered algorithm-specific tests, but the app could in theory include tests for whether zones known to be signed with specific algorithms can be correctly resolved with +AD returned. What I would like to see are tests like: set up a domain with a algorithm ID nobody will ever implement (reserve it if need be), and check that this domain returns as unvalidated (as per SHOULD in the RFC). Put in a MUST in relevant standards that implementation must not treat this identifier as anything but "I don't know anything about this" (ie don't implement specific tests for this "algorithm" and treat it differently from any other algorithm ID that is unknown). These kinds of migration scenarios to newer algorithms MUST be hashed out, because otherwise we're never going to be able to deploy new algorithms (and per previous experience, it seems we want to change them every 5-10 years). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
