|
NAMEnsdiff - create "nsupdate" script from DNS zone file differencesSYNOPSISnsdiff [-hV] [-b address] [-k keyfile] [-y [hmac:]name:key] [-0|-1] [-q|-v [q][r]] [-cCdD] [-i regex] [-S mode|num] [-u] [-s server] [-m server] <zone> [old] [new]DESCRIPTIONThe nsdiff program examines the old and new versions of a DNS zone, and outputs the differences as a script for use by BIND's nsupdate program. It ignores DNSSEC-related differences, assuming that the name server has sole control over zone keys and signatures.The input files are typically in standard DNS zone file format. They are passed through BIND's named-compilezone program to convert them to canonical form, so they may also be in BIND's "raw" format and may have .jnl update journals. If the old file is not specified, nsdiff will use dig to transfer the zone from the server given by the -s option, or if the -s option is missing it will get the server from the zone's SOA MNAME field. If both old and new files are not specified, nsdiff will transfer the new version of the zone from the server given by the -m option. The SOA serial number has special handling: any difference between the old and new serial numbers is ignored, because background DNSSEC signing activity can increment the serial number unpredictably. When the zones differ, nsdiff sets the serial number according to the -S option, and it uses the old serial number to protect against conflicting updates. OPTIONS
The following options are passed to dig to modify its SOA and AXFR queries:
EXIT STATUSThe nsdiff utility returns 0 if the zones are the same, 1 if they differ, and 2 if there was an error.DIAGNOSTICS
EXAMPLE - DNSSECIt is easiest to deploy DNSSEC if you allow named to manage zone keys and signatures automatically, and feed in changes to zones using DNS update requests. However this is very different from the traditional way of manually maintaining zones in standard DNS zone file format. The nsdiff program bridges the gap between the two operational styles.To support this workflow you need BIND-9.7 or newer. You will continue maintaining your zone file $sourcefile as before, but it is no longer the same as the $workingfile used by named. After you make a change, instead of using "rndc reload $zone", run "nsdiff $zone $sourcefile | nsupdate -l". Configure your zone as follows, to support DNSSEC and local dynamic updates: zone $zone { type primary; file "$workingfile"; auto-dnssec maintain; update-policy local; }; To create DNSSEC keys for your zone, change to named's working directory and run these commands: dnssec-keygen -f KSK $zone dnssec-keygen $zone EXAMPLE - bump-in-the-wire signingA common arrangement for DNSSEC is to have a primary server that is oblivious to DNSSEC, a signing server which transfers the zone from the primary and adds the DNSSEC records, and a number of secondary servers which transfer the zone from the signer and which are the public authoritative servers.You can implement this with nsdiff, which handles the transfer of the zone from the primary to the signer. No modifications to the primary are necessary. You set up the signer as in the previous section. To transfer changes from the primary to the signer, run the following on the signer: nsdiff -m $primary -s $signer $zone | nsupdate -l EXAMPLE - dynamic reverse DNSYou have a reverse zone such as "2.0.192.in-addr.arpa" which is mostly managed dynamically by a DHCP server, but which also has some static records (for network equipment, say). You can maintain the static part in a DNS zone file and feed any changes into the live dynamic zone by telling nsdiff to ignore the dynamic entries. Say all the static equipment has IP addresses between 192.0.2.250 and 192.0.2.255, then you can run the command pipeline:nsdiff -i '^(?!25\d\.)' 2.0.192.in-addr.arpa 2.0.192.static | nsupdate -l CAVEATSBy default nsdiff does not maintain the transactional semantics of native DNS update requests when the diff is big: it applies large changes in multiple update requests. To minimise the problems this may cause, nsdiff ensures each domain name's changes are all in the same update request. There is still a small risk of clients not seeing a change applied atomically when that matters (e.g. altering an MX and creating the new target in the same transaction). You can avoid the risk by using the -1 option to prevent multi-packet updates, or by being careful about changes that depend on multiple domain names.The update requests emitted by nsdiff include SOA serial number prerequisite checks to ensure that the zone has not changed while it is running. This can happen even in simple setups if named happens to be re-signing the zone at the time you make an update. Unfortunately the DNS update protocol does not allow for good error reporting when a prerequisite check fails. You can use nspatch to cope with this problem. BUGSWhen updating a name's DNS records, nsdiff first deletes the old ones then adds the new ones. This ensures that CNAME replacements and TTL changes work correctly. However, this update strategy prevents you from replacing every record in a zone's apex NS RRset in one update, because it isn't possible to delete all a zone's name servers.VERSIONThis is nsdiff-1.82 <https://dotat.at/prog/nsdiff/> Written by Tony Finch <fanf2@cam.ac.uk> <dot@dotat.at> at Cambridge University Information Services. You may do anything with this. It has no warranty. <https://creativecommons.org/publicdomain/zero/1.0/> ACKNOWLEDGMENTSThanks to Mike Bristow, Piete Brooks (University of Cambridge Computer Laboratory), Terry Burton (University of Leicester), Owen Dunn (University of Cambridge Faculty of Mathematics), JP Mens, Mohamad Shidiq Purnama (PANDI), and Jordan Rieger (webnames.ca) for providing useful feedback.SEE ALSOnspatch(1), nsupdate(1), nsvi(1), dig(1), named(8), named-compilezone(8), perlre(1)
Visit the GSP FreeBSD Man Page Interface. |