Actually most Web browsers at one point implemented their own DNS lookup routines back in 1995. This is because the then interface to DNS only returned one IP address for a name lookup. People were implementing silly rotating DNS server hacks to try to spread out the load amongst their HTTP servers on the more extreeme sites (NCSA Mosaic download). So we put a requirement in the spec to do the job properly. This turned out to require bypass of the O/S DNS interface on many platforms because it either failed to return multiple IP addresses for the same name or in some cases because the O/S implementation had taken it upon itself to implement some brain-damaged quasi-DNS scheme. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Loomis, Rip [mailto:GILBERT.R.LOOMIS@saic.com] > Sent: Monday, December 31, 2001 10:23 AM > To: 'Greg Hudson'; bert hubert > Cc: namedroppers@ops.ietf.org > Subject: RE: DS and Opt-in - a proposal > > > The message below is the best expression that I've seen > yet of how the "initial fielding" of DNSSEC signed zones > will actually help things. However, I think that > both of you are correct... > > Both Netscape and IE include some DNS-related internal > capabilities--but I believe (as do others) that it's > just a cache for data received through the normal system > gethostbyname() [or equivalent function]. In other words, > the browser will cache the results of the first "lookup" > of www.aol.com and will initiate subsequent connections > without a DNS lookup. What the browser *won't* do is directly > try to recurse through the hierarchy, or understand any part > of the DNSSEC signing--at least for now. > > The critical piece that's missing is the policy-enforcement > piece. The end-user (browser/client) will likely not know > anything about DNSSEC-- so the recursive server needs to > decide, based on policy, which of the following information > is "safe" or "correct" (or trusted) enough to be passed to > the browser: > - Signed data, signed by a key that is directly trusted > - Signed data, signed by a key that is indirectly trusted > (trust verified all the way back up to a trusted key > like .mil) > - Signed data, signed by a key that is not trusted > (which means that it could be bad, could be an impostor, > or could just be signed because some other "island" > of signed zones exists and we don't have a trust > relationship with that island) > - Unsigned data. > > As of right now, we trust all four. At some point in the > *near* future, we need a configurable capability to trust only > the first two, but to alert to the existence of three and > four. That's great...but at that point, we need a way for > the browser to indicate that there are different degrees of > trust in the provided information--which sounds to me as > though DNSSEC *won't* just be transparent to the client. > (Either that, or we need lwresd or something similar on > every single client system--and don't get me started on > that.) > > If all the zones which anyone *ever* needs to contact are > signed, then the problem becomes easier--which was your > stated situation. However, I think that's an unrealistic > scenario for at least the next several years--and in the > meantime, we either need to have a configurable trust > policy, or we gain minimal benefit from DNSSEC signed > zones. The best example I have of how to do this is the > MS IE 5.x+ configuration options for "trusted sites", > "local intranet", etc. Not everyone will know the > difference between signed and unsigned DNS data--but there > should be a way for users (or sysadmins) to limit which > types of DNS data are acceptable. This should likely > be a system-wide config file, though, rather than a > browser issue--which means it really is an OS-level > issue. (This was the path that led to lwresd, IIRC.) > > Unless we find a way to ease the transition while still providing > a useful security enhancement, IMHO we're going to have trouble > getting signed zones into the "commonly used" category. > > -- > Rip Loomis > Senior Systems Security Engineer > SAIC Center for Information Security Technology > > > -----Original Message----- > > From: Greg Hudson [mailto:ghudson@mit.edu] > > Sent: Sunday, 30 December, 2001 00:58 > > To: bert hubert > > Cc: namedroppers@ops.ietf.org > > Subject: Re: DS and Opt-in - a proposal > > > > > > On Sat, 2001-12-29 at 02:45, bert hubert wrote: > > > > In the Unix world, at least, the applications shouldn't > > have to get > > > > involved, just the recursive resolver (named, > > traditionally) and to some > > > > extent the stub resolver in libc. The application may be > > interested in > > > > > > You must live in a parallel universe from mine. The > > application developer > > > has needs. If DNSSEC is unable to meet, or worse, not > > interested in those > > > needs, s/he will ignore it. It is not a unix question. > > > > What needs? > > > > Your initial message said "DNSSEC is going nowhere if they > [browsers] > > aren't going to use it!" I was arguing that DNSSEC is > useful even if > > browsers stay the same as the are, at least in the Unix world. If: > > > > * DNSSEC is deployed at the root, > > * the recursive resolver is DNSSEC-aware and knows the root's key, > > * com, amazon.com, and www.amazon.com are signed, and > > * the path from the stub resolver to the recursive resolver > > isn't easy > > to attack (because they're on the same machine, the path > > is behind a > > firewall which the attacker can't get behind, or the path is > > protected by TSIG) > > > > then it becomes prohibitively difficult to spoof the address of > > www.amazon.com, even if the browser is completely ignorant > of DNSSEC. > > That's a win over the current situation, where it is > > relatively easy to > > spoof that address (especially if you can watch the query, > but in many > > cases even if you can't). > > > > > There is no difference. Right now DNSSEC is purely academic > > with some > > > laboratory experiments. Some fairy may come along and > > suddenly make all user > > > applications DNSSEC aware, but don't count on it. It's not > > that you write > > > the RFC and suddenly people start implementing it. > > > > The only reason I can think of why most user applications > > would need to > > be DNSSEC-aware is to convey to the user whether a domain > is signed or > > not. Since most users don't understand what that means, I > don't think > > that's the most important part of DNSSEC. > > > > > Just saying 'it is transparent from an applications' point > > of view' does not > > > cut it. > > > > Why not? > > > > > Interesting to note is that I'm told that IE has its own > > resolver, separate > > > from the regular windows one. > > > > Its own stub resolver or its own recursive resolver? If the latter > > (which I somewhat doubt; it wouldn't work so well with > > firewalls), then > > like any other recursive resolver, that would need to > implement DNSSEC > > in order to benefit. > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. >
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data