In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > From an InfoSec standpoint, of course one would prefer to use > cryptographic methods of securing DNS data, but, in the absence of that, > slaving could, arguably, be considered more secure than forwarding, in > the sense that forwarding usually generates more network transactions, > over time, for any given resolution of any given name, and thus more > chances for a bad guy to successfully spoof a response and have that > forged answer be cached. > > One could also eke out a small measure of extra security (again, if > cryptographic methods are for some reason unavailable) by turning off > IXFR and thus causing all zone transfers to occur with AXFR, which is > TCP-based and thus presumably harder to spoof. But, that's a heavy price > to pay for a small increment of extra security. Better to go for crypto, > at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), > by implementing (as many have) an out-of-band method of replicating zone > data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN > tunnels) or by securing *all* communicati on between nameserver instances > (e.g. IPSEC tunnels).
named only accepts IXFR over TCP. While the protocol supports sending deltas with IXFR/UDP named does not use that part of the protocol. -- 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
