Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 22/09/10 4:14 AM, Doug Barton do...@dougbarton.us wrote: On 9/21/2010 7:46 AM, Kalman Feher wrote: It may well be analogous to that (though I disagree), but the quote does not substantiate why knowing public information is bad. In the example above, you've simply saved your switchboard and the caller some time. If you don't want someone to know it, don't make it public (at the very least). You'll have to accept that no matter what steps you take, your public information will be available to those who wish to find it. Taking steps to prevent that is likely to waste more of your time than it will of those looking. When this topic first came up 12+ years ago I (and others) said that DNSSEC would never see wide deployment unless the ability to walk the zone was eliminated. We were all poo-pooed at the time with lots of security through obscurity, LOL type arguments. Development of DNSSEC specs continued to ignore the need to eliminate zone-walking for almost a decade until finally a consortium of folks more influential than I put their foot down and hammered out the NSEC3 spec (abridging the history here for the sake of a good story). My point being, it really doesn't matter if you agree with the reasoning or not, whether you understand the use case(s) or not, or whether you ever deploy NSEC3 or not. The fact is that there are a non-trivial number of organizations who will not deploy DNSSEC without it, so attempting to convince people not to use it is pointless. Not surprising that you've missed the point given the long thread, but I'll reiterate here. The concern was that a zone could be walked even _with_ NSEC3. Use whichever NSEC floats your (leaky) boat. It isn't going to stop public information from falling into an evil persons hands. I'd recommend being a little more sensible and only making public that which you want to be public. Then protecting all systems addressed within the zone as if bad people knew about them, regardless of the these are not the RRs you're looking for magical powers of NSEC3. Doug (... and it annoys the pig) -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 16:46, Kalman Feher wrote: If you don't want someone to know it, don't make it public (at the very least). I agree totally! You'll have to accept that no matter what steps you take, your public information will be available to those who wish to find it. I agree. But I'd argue that there are different grades of public information. My home phone number is public. You can look it up in the (paper or electronic) phonebook. That doesn't mean I'll put it in the footer of every mail/facebook/twitter I send out. Hell, I even use an alias to post to newsgroups instead of my real name. And sure you can figure out who I am, that info is publicly available somewhere (despite my efforts), but I'm not going to hand it to you on a plate. In that sense, I still believe that using NSEC3 over NSEC adds another barrier to those who want to walk your zone. And while it's possible (you could even argue easy) to overcome, it's yet another speed bump. The whole point of NSEC3 was to make zone walking as difficult as brute-forcing the server, not to make it impossible. Taking steps to prevent that is likely to waste more of your time than it will of those looking. Unless you're calculating the NSEC3 hashes by hand, it took me under 1 minute to add an NSEC3PARAM RRset to my zone. And I'm fairly confident that it will take at least 1 minute longer to walk an NSEC3 zone than an NSEC zone. Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 16:56, Phil Mayers wrote: On 21/09/10 14:43, Niobos wrote: On 2010-09-21 15:32, Kalman Feher wrote: On 21/09/10 8:43 AM, Niobosnio...@dest-unreach.be wrote: I personally find protection against zone enumeration to be a false sense of security. If it's public people will find it. Ask your self what it is that you want publically accessible yet you don't want others to be aware of. I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. That is a poor analogy. Do you have reverse DNS in .in-addr.arpa? Yes Have you timed how long an nmap -sL yoursubnet/mask takes? Because it doesn't take very long for us, and we've got a lot of large subnets. A few seconds Attackers can gain a lot of info from this; Correct certainly not *all* forward lookups, but a lot of them. My zone consists of mostly CNAMEs that map vhosts to physical hosts; you won't find these with .in-addr.arpa. Greetings, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. That is a poor analogy. imho it's perfect. On 2010-09-21 16:56, Phil Mayers wrote: Do you have reverse DNS in .in-addr.arpa? On 22.09.10 11:24, Niobos wrote: Yes Have you timed how long an nmap -sL yoursubnet/mask takes? Because it doesn't take very long for us, and we've got a lot of large subnets. A few seconds and how long will it take for /48 (2^80 = 1208925819614629174706176) in ipv6 environment? :) Attackers can gain a lot of info from this; Correct at present, yes. with ipv6, they will rely much more on DNS or other public informations. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 22/09/10 11:29 AM, Matus UHLAR - fantomas uh...@fantomas.sk wrote: I'll reply with a quote from the BIND DNS book: It¹s the difference between letting random folks call your company¹s switchboard and ask for John Q. Cubicle¹s phone number [versus] sending them a copy of your corporate phone directory. That is a poor analogy. imho it's perfect. Analogies to specific issues are a poor idea. They abstract details that should be considered and by trying to visualise the new example you associate properties that don't exist within the original problem. I could list differences but it would pander to the belief that somewhere out there is the perfect non DNS example to a DNS problem. Zone walking and its perceived risks should only be considered in light of DNS knowledge, not boats, not phone switchboards or any other non DNS item. Its fine to convey simple concepts using an analogy. But by using one for a specific issue (on bind-users), you betray ignorance of the problem at hand by relying on unrelated behaviours and properties to fill in the blanks for you. It is a poor analogy because so many of the properties of the original problem (DNS software, zone walking software, publically available RRs) simply do not behave in ways even vaguely similar to a human answering a phone. If you think zone walking prevention (such as it is) makes you more secure. I say prove it. Show me something measureable. Show me how you can protect a publically available resource by preventing zone walking (which isn't preventable by the way). After that, feel free to tell me how a phone switchboard would implement the same solution. -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
