On Mon, Feb 27, 2017 at 11:14:13AM +0100, Jeremie Courreges-Anglas wrote: > "Peter J. Philipp" <p...@centroid.eu> writes: > > > On Mon, Feb 27, 2017 at 10:26:48AM +0100, Peter J. Philipp wrote: > >> I had a patch somewhere for TSIG as well somewhere, give me some time to > >> find it. TSIG can secure the channel as well, but my implementation wasn't > >> all that pretty. > > > > Here is the patch, it would need fixing up, and it only would work with BIND > > nameservers currently :-(. > > > > http://marc.info/?l=openbsd-tech&m=145656997013119&w=2 > > Interesting. I can't speak for others but I don't think that TSIG is > a good solution. Shared secrets don't buy us much, especially if we > have to store them in /etc/resolv.conf. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
You're right. If I may point you to RFC 4033 section 7 (not a long read) it talks about securing this channel for stub resolvers. It actually talks about SIG(0) or TSIG (like my example, which isn't the best use). And it talks about IPSEC to secure the channel (another good way) but who can say that they have an IPSEC tunnel to their nameserver especially when it's the ISP's? Really all that we're left with (if we want security) is a local recursive nameserver. I think making the stub resolver security aware and validating would be a good thing but it's not a 1 person effort unless you can invest 2-3 years into it and work for a living on the side. I'm open to help (still) and I know I'm talking to the right people here, yet a group should form and a mandate be set in place for this to work best. Cheers, -peter
