Re: [DNSOP] Big reduction in the number of DNS KillSwitches
> On 9 Aug 2015, at 01:11, manning > there are other DNS Kill Switches still out there. Yeah? Which ones? Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2
We'd end up adding stuff to a response in order to make it shorter. Is there a clear benefit (shorter responses)? Can you show me a few real world examples? Thanks Roy > On 8 Dec 2015, at 20:37, Mark Andrews wrote: > > > In message , Paul Wouters > wr > ites: >> >>> Subject: Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2 >> >> Thanks everyone for the useful comments. It's all clear to me now. >> >> Paul > > Additionally if we ever wanted to enable compression for new types > we could use EDNS to signal that the client understands a expand > set of types and one could use case sensitive compression to preserve > the original case of the name in the rdata which would allow DNSSEC > to work to work on the expanded names without having to update every > client in the world first. > > e.g. >EDNS(1) could indicate the client understands the rdata >for all the types allocated as of 12:00 Dec 8, 2016. > >EDNS(2) could indicate the client understands the rdata >for all the types allocated as of 12:00 Dec 8, 2020. > > We all should be doing case sensitive compression already as that > really is part and parcel of preserving the original case as required > by RFC 103[45]. > > I'm actually tempted to say we should do this just to get rid of > the stupid firewalls that think that it is a good idea to drop EDNS > != EDNS(0) requests. > >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On 02 Apr 2014, at 15:19, Jim Reid wrote: > There's been a lot of noise and very little signal in the recent discussion. > > It would be helpful if there was real data on this topic. Is an RSA key of N > bits too "weak" or too "strong"? I don't know. Is N bits "good enough"? > Probably. Change the algorithm and/or value of N to taste. > > My gut feel is large ZSKs are overkill because the signatures should be > short-lived and the keys rotated frequently. Though the trade-offs here are > unclear: is a 512-bit key that changes daily (say) better than a 2048-bit key > that gets rotated once a week/month/whatever? Remember too we're not talking > about keys to launch ICBMs or authenticate billion dollar transactions. I > doubt it matters if a previous key can be cracked provided it gets retired > before the bad guys can throw enough CPU-years to break it. > > However I'm just going on my own gut feel and common sense which could be > wrong. Large keys might well be advisable at the root and/or for TLD KSKs. > But so far there does not appear to have been much science or engineering on > just how large those keys should be or how frequently they change. So in the > absence of other firm foundations the established wisdom becomes "do what > gets done for the root". > > If there is a threat or risk here, please present solid evidence. Or, better > still, an actual example of how any DNSSEC key has been compromised and then > used for a real-world (or proof of concept) spoofing attack. > > > BTW, the apparent profanity on an earlier thread was annoying because it > didn't spell "whisky" correctly. As every drinker of fine single malt knows. > :-) :-) Jim, Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. As an example (dns-op perspective). Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at least 768 bytes (and then some). Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at least 1280 bytes (and then some). Then there is this section in SAC63: "Interaction of Response Size and IPv6 Fragmentation” Which relates to response sizes larger than 1280 and IPv6 and blackhole effects. https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf Hope this helps Roy signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how. I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign. Personally, I’m interested in what operators of large recursives have to say about this. Hope this helps. Roy > On 04 Jul 2014, at 21:50, Paul Hoffman wrote: > > Greetings. Warren and I have done a major revision on this draft, narrowing > the design goals, and presenting more concrete proposals for how the > mechanism would work. We welcome more feedback, and hope to discuss it in the > WG in Toronto. > > --Paul Hoffman > > Begin forwarded message: > >> From: internet-dra...@ietf.org >> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt >> Date: July 3, 2014 at 2:17:46 PM PDT >> To: i-d-annou...@ietf.org >> Reply-To: internet-dra...@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Securely Distributing the DNS Root >> Authors : Warren Kumari >> Paul Hoffman >> Filename: draft-wkumari-dnsop-dist-root-01.txt >> Pages : 9 >> Date: 2014-07-03 >> >> Abstract: >> This document recommends that recursive DNS resolvers get copies of >> the root zone, validate it using DNSSEC, populate their caches with >> the information, and also give negative responses from the validated >> zone. >> >> [[ Note: This document is largely a discussion starting point. ]] >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] cool, Cloudflare implemented DNSSEC
https://blog.cloudflare.com/help-us-test-our-dnssec-implementation/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology
> On 23 Feb 2015, at 13:00, Hosnieh Rafiee wrote: > > Hello, > > Is there any single document for all DNS terms to be used as a reference in > order to avoid defining them in a document. The terms I am looking for is all > general DNS terms -- authoritative name server, resolver, client, host, etc.? https://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Roy signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
