This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] What about the last mile, was: getting DNSSEC deployed
- Previous message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
- Next message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lutz Donnerhacke
lutz at iks-jena.de
Fri Feb 16 17:03:19 CET 2007
* Roy Arends wrote: > So folks with domains under '.se' are signing their zone en-masse ? No, because it was free. Now you can _buy_ security from SE-DNSSEC and the run starts. :-/ > Stub resolvers can be spoofed trivially. resolver code in dsl > routers/cable modems can be spoofed trivially. It's hard to spoof in our own infrastructure, but YMMV. > security theater. Nothing really changes for the end user. Those who tried > to spoof resolvers will now change their focus towards the end-users stub. > Arms race. End user stubs arn't reachable from outside, due to firewalls etc. pp.. But YMMV. >> Taking this road means: Redo from start. > > It _is_ done from the start. We've put in the current standards. > Applications can already use. My jabber server uses it. Validation on a > stub. Fine! I'm happy with it. But I'm not happy with urging such installation on every end user host by prohibiting verifying recursive resolvers. >> Never get a reasonable deployment. Root will not be signed, because >> there are not enough installations. More installations will not come >> up, because the root is not signed and key maintainence is a mess. >> Catch-22. > > That is the _current_ status quo. not enough installations have 'switched > on' dnssec, so why bother signing. why bother switching on dnssec if not > enough domains are signed. Therefore every validating recursive resolver is a big win. Urging to shut validation down on those resolvers ist the wrong road. But YMMV. >>> acl's, firewalls, etc, that decide on source ip address if it can >>> query your resolver. I can circumvent that. >> >> How do you want to do this? > > I scan a range, a few boxes will do a reverse lookup. I control the > specific reverse address space, hence your resolver is talking to me: > window of opportunity. Another way is spraying spam around, antispam code > resolve whatever I tell it to resolve. So you do not query my resolver, but my resolver queries you. Let keep such discussions off the list. >> They are free to do so. They are free to use any nameserver they want. >> But if they use the ISP's recursive resolver, this will be a validating >> one. > > What is the use of seeing a bit set in the response that claims that the > response is validated, when I can't trust the link !!!!!!! Oh my godness. Paranoia is offtopic either. You have much more problems than DNS if the link between your system and your ISPs resolver is not trustworthy. >> The ISP can validate the integrity of DNSSEC-signed zones, and it is >> good to do so. > > The ISP can validate the integrity, sure. To me that would be another > middlebox fondling with the data. Paranoia again. So do not use the resolver of your ISP! > So, basically, if the https protocol would allow it, ISP's like to > validate the integrity of certificates as well.... so end users don't > have to? Of course. There are proxies which break the end-to-end-security of https in order to achive this. But I consider this as a hack. BTW: ISPs do validate a lot more of internet data while flying through. You do not see a lot of crap out there. And you are happy with it.
- Previous message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
- Next message (by thread): [dns-wg] What about the last mile, was: getting DNSSEC deployed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]