Re: named memory usage
In message , Teerapatr Kittiratanachai writes: > Dear List, > > How can I approximate the memory usage of named process if I handle > all IPv6/32 rDNZ on a DNS server? All the memory on the planet would not be enough. There are 79,228,162,514,264,337,593,543,950,336 addresses in a /32. Delegate the reverse zone to your customers and they can dynamically populate it for the hosts that exist. > Regards, > --teenigma > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named memory usage
Thank Mark. Another question is how can we determine the memory usage per 1 record? --teenigma On Fri, Jul 25, 2014 at 2:00 PM, Mark Andrews wrote: > > In message > > , Teerapatr Kittiratanachai writes: >> Dear List, >> >> How can I approximate the memory usage of named process if I handle >> all IPv6/32 rDNZ on a DNS server? > > All the memory on the planet would not be enough. There are > 79,228,162,514,264,337,593,543,950,336 addresses in a /32. > > Delegate the reverse zone to your customers and they can dynamically > populate it for the hosts that exist. > >> Regards, >> --teenigma >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >> from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and ZSK-Rollovers: Changing salt automatically?
Hello Mark, Mark Andrews writes: > Actually it is useless to change the salt regularly. Changing the > salt provides no real benefit against discovering the names in a > zone which is the reason people were saying to change the salt. > > The attacker uses cached NSEC3 records. When it gets a cache miss > it asks the servers for the zone, puts the answer in the cache and > continues. When the salt changes it just maintains multiple nsec3 > chains eventually discarding the old nsec3 chain eventually. I > would wait until the new NSEC3 chain has as many cached records as > the old NSEC3 chain. Changing the salt slows things up miniminally > for a very short period of time after the change. Additionally > once you have some names you ask for those names for a non-exisisting > type to quickly pull in part of the new NSEC3 chain you know exists. > > The only reason to change the salt is if you have a collision of > the hashed names. This will be a very very very rare event. > this is new for me (must somehow missed it if this was previously discussed). I do not want to give useless or misguiding advice. I do not understand how the NSEC3 hash can be defeated by an attacker. Could you give a link to additional information or could you explain the issue with NSEC3 salt in other words? Best regards Carsten -- Carsten Strotmann Email: c...@strotmann.de Blog: strotmann.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and ZSK-Rollovers: Changing salt automatically?
Carsten Strotmann wrote: > > I do not understand how the NSEC3 hash can be defeated by an > attacker. Could you give a link to additional information or could you > explain the issue with NSEC3 salt in other words? http://www.vs.uni-due.de/personal/wander/20130512_NSEC3_Hash_Breaking/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, East Wight: Northerly or northeasterly 4 or 5. Slight or moderate. Thundery showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and ZSK-Rollovers: Changing salt automatically?
Hi Tony, Tony Finch writes: > Carsten Strotmann wrote: >> >> I do not understand how the NSEC3 hash can be defeated by an >> attacker. Could you give a link to additional information or could you >> explain the issue with NSEC3 salt in other words? > > http://www.vs.uni-due.de/personal/wander/20130512_NSEC3_Hash_Breaking/ > thanks for the link, the data in this presentation is in-line with my knowledge on NSEC3 hash breaking. Slide 7 -(snip)- Rainbow tables --- no plans (won't work once everybody starts changing the salt regularly) -(snip)- I can imagine an attacker to store the NSEC3 chain (a snapshot) and hash-break the names in the zone based on that snapshot, ignoring the changes that occur in the signed zone by changing the salt. This will allow the attacker to enumerate the zone based on the NSEC3 chain snapshot. The attacker will learn the domain names of the records in the zone at one moment in time. It may not be the current version of the zone. NSEC3 hash-breaking, as I understand, will not allow the attacker to monitor changes in the zone is a timely fashion (records added, records removed). from the slides: -(snip)-- Limited feasiblity 9 characters: ~1 week 10 characters: ~37 weeks -(snip)-- My understanding is, to break NSEC3, the full FQDN needs to be hashed (for each test). For FQDN > 10 chars, the amount of work increases even more. Markov-Chains help with the hash-breaking *if* the domain names are taken from a natural language (and not, for example, random alphanumeric identifiers). NSEC3 cannot prevent zone enumeration, it can only make it harder. How hard, that depend on the NSEC3 parameters. Changing the salt can prevent an attacker from learning changes in an NSEC3 signed zone "early after the change" (again, how early depends on the parameters, but from what I see it should be in the range of weeks, not days). Without changing the salt, the attacker could build a rainbow table, and with the help of a rainbow table, changes to the zone can be tracked much quicker. >From that perspective, I would argue that changing the salt *could* be useful, but the DNS operator needs to know what to protect. For many zones, NSEC3-signing and changing the salt is not worth the effort (e.g. NSEC is sufficient). NSEC3 can certainly not keep the domain names in a zone secret for all times. DNS data on authoritative servers is there to be queries, anyone can query, enumerating a zone is a matter of time with or without NSEC3. It would be interesting to know the difference in effort between hash-breaking NSEC3 vs. intelligently discover a zone by the use of sending queries (using tools like "dnsmap" http://code.google.com/p/dnsmap/). Has anyone seen work in that area? -- Carsten Strotmann Email: c...@strotmann.de Blog: strotmann.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.9.5 high CPU and when will Bind9.8 EOL?
We have been running Bind 9.8 branches for years which has been very stable, upgraded one box to Bind 9.9.5 last week and it has been running 3 times CPU as same bind 9.8 server. All of our Bind servers(10 total) are behind F5 load balancers so the load are spread evenly across the servers. I have disabled dnssec-validation, which doesn't make any difference. RedHat linux 5.10, kernel version 2.6.18-371, compilation flag: ./configure --with-libtool --enable-threads --enable-ipv6 --with-openssl=yes --enable-largefile We want to use the Response Rate Limiting feature comes with 9.9, also, will 9.8 branch reach end of life support soon? Thanks in advance! Lily ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
