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] Analysis of NSD
- Previous message (by thread): [dns-wg] Analysis of NSD
- Next message (by thread): [dns-wg] Analysis of NSD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Johan Ihrén
johani at autonomica.se
Thu Oct 28 10:02:10 CEST 2004
Hi Jørgen, On Oct 28, 2004, at 04:47, Jørgen Hovland wrote: > and different replies depending on the country origin of the source ip > of the querying nameserver/client. Oops. What's the justification for that? And what about maintaining DNS coherency? Any ideas on how to make this work with DNSSEC (I realize you're not doing DNSSEC today, but this would seem to be fundamentally incompatible with any DNSSEC use whatsoever). > When it comes to zone updates we use a tcp/ip connection to the > master server instead of altering the database directly. We don't need > to probe for db changes this way. Well, that makes sense, but no one in their right mind is probing for changes since NOTIFY was defined many years ago. > The user issues a command and the nameserver replies ok or error and > so on. You can only add/del/change data, not list/view it. A change > results in that the master updates the local memory of the change only > and then the sql server, finally it sends the update to any connected > slaves. Slaves are registered with the master through a permanent tcp > connection and receive updates whenever somebody alters data in a non > zone-transfer/axfr compatible way. We actually don't have support for > normal zone transfers at all. The master sends the actual change, not > the entire zone or a zone reload request. So both master and slaves > updates their local copy instantly. > If a slave gets disconnected from the master, it will reload the whole > database from the sql server when reconnected to the master in order > to ensure no loss of data since the master doesn't keep track on the > status of any of the slaves. This reload takes seconds for a > small/medium sized database (10k+). When the data has been loaded and > sorted the nameserver replaces it with the existing local copy and > deletes it from memory. This ensures no downtime. What happens to updates (to the master) that occur *during* the reload? My guess is that they get added to "the tail" of the reload to ensure that no change is left out during the reload. But in that case it seems to me that you already have the zone sorted in "transaction order" and the only thing needed to steer around the complete reloads would be some sort of version stamp that is shared between slave and master. Doesn't really have to be the SOA serial, you can use whatever you want. If you need to serve zones of non-trivial size that would seem to be a good idea. > Serial numbers are simply autocalculated from the current time and its > not possible for a user to do anything about it. I.e. the SOA serial is *changed* by the slave. This too won't fly too well with DNSSEC. > The response latency is the same as with bind but it uses > significantly less memory. I havent really done the research to know > why. Since we use a tcp connection to the nameserver as way of > managing zones, the wrong things you can do is very few. Regards, Johan Ihrén Autonomica
- Previous message (by thread): [dns-wg] Analysis of NSD
- Next message (by thread): [dns-wg] Analysis of NSD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]