Swedish ISP TCD Song Adopts DNSSEC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ** Swedish ISP TDC Song Adopts DNSSEC Swedish Internet Service Provider TDC Song announced in a press release on Friday that it will run DNSSEC on its name servers and thus be able to offer safer broadband services to its customers. TDC Song will be using .SE-DNSSEC, a service offered by .SE (The Internet Infrastructure Foundation) responsible for the Swedish top-level domain .se. For the full press release (in Swedish), see: http://wpy.observer.se/wpyfs/00/00/00/00/00/09/35/D0/release.html ** Anne-Marie Eklund Löwinder Quality & Security Manager .SE (The Internet Infrastructure Foundation) P O Box 7399 103 91 Stockholm Sweden Tel: +46 8 452 35 00, direct: +46 8 452 35 17, mobile: +46 734 315 310 E-mail: anne-marie.eklund-lowinder@iis.se Web: www.iis.se -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRdCLtaXc8AFCsc+UEQIB8QCg4aRoRyiK+TzRgYOSCb8eBMSyUCsAn2v9 8PdylTKBWZcOnYC2sUed8jLy =ABy6 -----END PGP SIGNATURE-----
* Anne-Marie Eklund-Löwinder wrote:
Swedish Internet Service Provider TDC Song announced in a press release on Friday that it will run DNSSEC on its name servers and thus be able to offer safer broadband services to its customers.
What is so great about this message?
On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote:
* Anne-Marie Eklund-Löwinder wrote:
Swedish Internet Service Provider TDC Song announced in a press release on Friday that it will run DNSSEC on its name servers and thus be able to offer safer broadband services to its customers.
What is so great about this message?
That a large ISP turn on verification of DNSSEC signatures in their resolvers with the key of a TLD as anchor. That has not happened before as far as I know. If I am wrong, I would like to know. Patrik
On Tue, Feb 13, 2007 at 04:18:37PM +0100, Patrik Fältström wrote:
On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote:
What is so great about this message?
That a large ISP turn on verification of DNSSEC signatures in their resolvers with the key of a TLD as anchor. That has not happened before as far as I know. If I am wrong, I would like to know.
I thought Cable and Wireless did this in December 2005.
We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, .ru, .net, .com as well as ISC's DLV checking). In general, I don't believe in practical usage of this implementation, because of you can do a DNS attack on the client's resolver directly. But I see significant decrease of spam after DNSSEC implementation. I believe it can happens because of wise spammers can't cheat backresolve and blacklists checks anymore. Lutz Donnerhacke wrote:
On Tue, Feb 13, 2007 at 04:18:37PM +0100, Patrik Fältström wrote:
On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote:
What is so great about this message? That a large ISP turn on verification of DNSSEC signatures in their resolvers with the key of a TLD as anchor. That has not happened before as far as I know. If I am wrong, I would like to know.
I thought Cable and Wireless did this in December 2005.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, .ru, .net, .com as well as ISC's DLV checking).
I think this is a great move. Have you had any feedback from your users?
In general, I don't believe in practical usage of this implementation, because of you can do a DNS attack on the client's resolver directly.
But I see significant decrease of spam after DNSSEC implementation. I believe it can happens because of wise spammers can't cheat backresolve and blacklists checks anymore.
How is the information about whether the RRsets are signed and/or validated, or not, getting back to the clients? IOW, if I'm a piece of anti-spam software, how do I know that the answer I received is signed and validated? I ask because IMO this is actually the more difficult part of DNSSEC deployment. We have the stuff to sign the zones, but figuring out how to use the signature data (or lack thereof) is a whole new kettle of fish. Doug -- If you're never wrong, you're not trying hard enough
Doug Barton wrote:
Max Tulyev wrote:
We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, .ru, .net, .com as well as ISC's DLV checking).
I think this is a great move. Have you had any feedback from your users?
Common users didn't notify any differences. But some of experienced ones notified slightly increased time of resolve. I notified significant decrease of spam.
How is the information about whether the RRsets are signed and/or validated, or not, getting back to the clients? IOW, if I'm a piece of anti-spam software, how do I know that the answer I received is signed and validated?
If you are just resolver client and someone trying to cheat backresolve tests - you'll get this IP is just not resolved. And of course, you can use libraries such as http://www.net-dns.org/ For me, failed DNSSEC validation of DNS resolve (including DNS BL tests) is the enough argument to drop that mail as the spam or fraud. By the way, is there any tools and/or log analyzers to gather and analyze some statistics about DNSSEC working on my servers? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Feb 13, 2007, at 14:45, Lutz Donnerhacke wrote:
* Anne-Marie Eklund-Löwinder wrote:
Swedish Internet Service Provider TDC Song announced in a press release on Friday that it will run DNSSEC on its name servers and thus be able to offer safer broadband services to its customers.
What is so great about this message?
Surely the decision to deploy DNSSEC in anger by any ISP is something this WG would heartily celebrate. Even if TDC Song has just switched on DNSSEC validation for the signed bits of .se, it's a start. DNSSEC deployment has to start somewhere. By that I mean deployment in the context of validation outside the usual "research" environments and for stuff beyond zone signing.
DNSSEC deployment has to start somewhere.
the root or it will not scale and there will be significant breakage of END USERS' access randy
On Feb 13, 2007, at 17:04, Randy Bush wrote:
DNSSEC deployment has to start somewhere.
the root or it will not scale
True. But what should the DNS engineers do while the layer-9 issues about the root key rumble on and on? I very much doubt anyone's going to take responsibility for signing the root unless they know that, yes DNSSEC really does work and won't break the internet. The only way of establishing that IMO is "real world" experience outside the research environment where DNSSEC deployment has been done to date.
DNSSEC deployment has to start somewhere. the root or it will not scale True. But what should the DNS engineers do while the layer-9 issues about the root key rumble on and on?
dunno 'bout everyone else, but i have too much work to do already.
I very much doubt anyone's going to take responsibility for signing the root unless they know that, yes DNSSEC really does work and won't break the internet.
bs. that is not the problem at the root. it's all layer nine. randy
On Feb 13, 2007, at 17:58, Randy Bush wrote:
I very much doubt anyone's going to take responsibility for signing the root unless they know that, yes DNSSEC really does work and won't break the internet.
bs. that is not the problem at the root. it's all layer nine.
Nobody said this was an issue at the root Randy. And whether that's a layer-9 issue or not is irrelevant too: this genuine problem -- you'd presumably call it a non-problem -- has to be resolved somehow. Getting real-world experience of what happens when DNSSEC is switched on is part of that process. So the recent moves in Sweden are to be commended as a step towards getting that experience. I'm disappointed if you don't share that view.
I very much doubt anyone's going to take responsibility for signing the root unless they know that, yes DNSSEC really does work and won't break the internet. bs. that is not the problem at the root. it's all layer nine. Nobody said this was an issue at the root Randy.
false. i did. if the root is not signed, dnssec is an unstabele and unscalable mess, with disasters for the end users waiting to happen.
And whether that's a layer-9 issue or not is irrelevant too
not when you seem to be trying to fix it at layers 3-7.
this genuine problem -- you'd presumably call it a non-problem -- has to be resolved somehow.
i consider it a major problem. and the only solution is getting iana to sign the root zone. whether we like it or not, that is the way dnssec was designed.
Getting real-world experience of what happens when DNSSEC is switched on is part of that process. So the recent moves in Sweden are to be commended as a step towards getting that experience. I'm disappointed if you don't share that view.
you should be used to me dissapointing you. after all, i am the guy publicly blamed for delaying dnssec for years. isolated deployments of dnssec will have interesting results. i eagerly await the results from sweden rolling their key in an emergency. and no, lutz, dlv has an unspecified trust model. and the answers to the trust model promised in san jose nanog many moons ago have yet to be given. randy
On 14 Feb 2007, at 17:08, Randy Bush wrote:
you should be used to me dissapointing you. after all, i am the guy publicly blamed for delaying dnssec for years.
Six months at a time ... ? 8-) /Niall
* Randy Bush wrote:
and no, lutz, dlv has an unspecified trust model. and the answers to the trust model promised in san jose nanog many moons ago have yet to be given.
I do trust my DLV data. I offer it to others.
On Feb 14, 2007, at 9:37 AM, Lutz Donnerhacke wrote:
* Randy Bush wrote:
and no, lutz, dlv has an unspecified trust model. and the answers to the trust model promised in san jose nanog many moons ago have yet to be given. I do trust my DLV data. I offer it to others.
And how do I trust the DLV registry you use? Rgds, -drc
On 14Feb 2007, at 9:11 PM, Lutz Donnerhacke wrote:
* David Conrad wrote:
On Feb 14, 2007, at 9:37 AM, Lutz Donnerhacke wrote:
I do trust my DLV data. I offer it to others.
And how do I trust the DLV registry you use?
You can't without knowing me.
So, there you go.. remember what Randy just said:
if the root is not signed, dnssec is an unstabele and unscalable mess,
I am not a firm believer in DLV but I think it will allow the early deployers to familiarize themselves with the DNSSEC operational space. But, life for the masses, as opposed to early deployers, will only be good once: - The root is signed - Automated trust anchor rollover works (work on that finished in DNSEXT and is now at IESG level) - A fair amount of TLDs is signed Until then we will have to live with kludges like DLV. Now I appreciate Lutz' offer but I think that the more DLV registries will pop up the more confusion and troubleshooting hell will be created simply because users of different DLVs will have a different view on the namespace. Note however that now, for folk who configure their nameservers to use a DLV registry things will not be radically different operationally than in the case of a signed root; they configure one trust anchor, and off they fly. So as long as the root is not signed I hope that people will converge to using[*] one DLV registry and I also hope that the layer 9 stuff surrounding a signed root is being dealt in an appropriate time window. (Neill just suggested one :-) ) . --Olaf [*] where using in this case means: take a leap of faith and put your trust in a particular DLV registry. PS I appreciate the announcement about a validating recursive nameserver being turned on in some big IESP but I hope that will not become a trend ;-) ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/
So as long as the root is not signed I hope that people will converge to using[*] one DLV registry and I also hope that the layer 9 stuff surrounding a signed root is being dealt in an appropriate time window. (Neill just suggested one :-) ) .
show me a dlv with published trust policies as was asked for last (northern) summer. until then, hell no. randy
participants (10)
-
Anne-Marie Eklund-Löwinder -
David Conrad -
Doug Barton -
Jim Reid -
Lutz Donnerhacke -
Max Tulyev -
Niall O'Reilly -
Olaf M. Kolkman -
Patrik Fältström -
Randy Bush