DNS - Revision history

70.230.212.110: /* DNS Management and Operations */

2013-01-30T22:21:52Z

DNS Management and Operations

← Older revision		Revision as of 15:21, 30 January 2013
Line 143:		Line 143:
	listmasters		listmasters

	this will list all the zones for which we’re acting as a master~~, and their ttl’s~~		this will list all the zones for which we’re acting as a master

	~~changettl~~ <ttl>		ttlswap <cid> <ttl>

	this will change the ttl’s for all ~~master~~ zones~~. If~~ given ~~an argument it will set the ttl to that argument. In absence, it will use 43200 (12hrs)~~. It will prompt before changing each zone.		this will change the ttl’s for all zones for a given cid. It will prompt before changing each zone.

	ptr <ip>		ptr <ip>

70.230.212.110: /* DNS Management and Operations */

2013-01-22T23:22:52Z

DNS Management and Operations

← Older revision		Revision as of 16:22, 22 January 2013
Line 157:		Line 157:
	this will remove the zonefiles for any domain found for the given cid inside named.conf. This only removes the zonefiles, it does nothing to named.conf. So you still have to edit named.conf to remove the zone definitions manually, then reload bind (<tt>rr</tt>).		this will remove the zonefiles for any domain found for the given cid inside named.conf. This only removes the zonefiles, it does nothing to named.conf. So you still have to edit named.conf to remove the zone definitions manually, then reload bind (<tt>rr</tt>).

	If occasionally there is an issue where, for instance we're not ~~slaving~~ a zone file and the customer's setup is good, we've seen occasions where no amount of <tt>rr [ZONEFILE]</tt> fixes the problem or <tt>rr</tt>, and you just have to:		== troubleshooting slaving issues ==

			If there's an issue where we're not resolving a domain which we are slaving, the likely cause is the domain expired and we never got updated zone info from the master. To confirm this, make sure we're slaving from the right server, then rm the zone file and rr the domain and see if we get a fresh zonefile.

			If occasionally there is an issue where, for instance we're not getting a new zone file and the customer's setup is good, we've seen occasions where no amount of <tt>rr [ZONEFILE]</tt> fixes the problem or <tt>rr</tt>, and you just have to:

	<pre>		<pre>

70.230.212.110: /* DNS Management and Operations */

2013-01-22T23:18:59Z

DNS Management and Operations

← Older revision		Revision as of 16:18, 22 January 2013
Line 156:		Line 156:

	this will remove the zonefiles for any domain found for the given cid inside named.conf. This only removes the zonefiles, it does nothing to named.conf. So you still have to edit named.conf to remove the zone definitions manually, then reload bind (<tt>rr</tt>).		this will remove the zonefiles for any domain found for the given cid inside named.conf. This only removes the zonefiles, it does nothing to named.conf. So you still have to edit named.conf to remove the zone definitions manually, then reload bind (<tt>rr</tt>).

			If occasionally there is an issue where, for instance we're not slaving a zone file and the customer's setup is good, we've seen occasions where no amount of <tt>rr [ZONEFILE]</tt> fixes the problem or <tt>rr</tt>, and you just have to:

			<pre>
			rndc stop
			ps auxw\|grep named (make sure its down)
			named</pre>
			to restart the nameserver, this will clear up that issue.

	= Restore deleted domain =		= Restore deleted domain =

70.230.212.110: /* DNS Management and Operations */

2013-01-18T01:37:59Z

DNS Management and Operations

← Older revision		Revision as of 18:37, 17 January 2013
Line 152:		Line 152:

	this will open up the appropriate zonefile for editing an IP’s PTR record. After saving the file, it will reload the zone.		this will open up the appropriate zonefile for editing an IP’s PTR record. After saving the file, it will reload the zone.

			rmdomains <cid>

			this will remove the zonefiles for any domain found for the given cid inside named.conf. This only removes the zonefiles, it does nothing to named.conf. So you still have to edit named.conf to remove the zone definitions manually, then reload bind (<tt>rr</tt>).

	= Restore deleted domain =		= Restore deleted domain =

70.230.212.110: /* Setup BIND */

2012-12-28T23:01:59Z

Setup BIND

← Older revision		Revision as of 16:01, 28 December 2012
Line 152:		Line 152:

	this will open up the appropriate zonefile for editing an IP’s PTR record. After saving the file, it will reload the zone.		this will open up the appropriate zonefile for editing an IP’s PTR record. After saving the file, it will reload the zone.

			= Restore deleted domain =

			In the event a domain (zone file or done definition inside named.conf) is deleted, restoring is easy.
			We make backups of the mail server daily, included in that are bind config files and domains. These backups may be found on backup1:

			/data/www/daily

			and are organized by date. So diggind in, we will find all the files we're looking for here (for example):

			<pre>ls /data/www/daily/12-12-28/mnt/data1/ns1c-dir/etc/namedb/
			bind.keys named.orig
			copys.sh named.prev
			createzones.pl named.root
			k named.root.orig
			make-localhost named.stats
			named.conf named.tar
			named.conf.back-200908140748 ns2c.tar
			named.conf.bak_pre_remove_allow-query_and_allow-transfer PROTO.localhost.rev
			named.conf.before.mass.import.2003-10-23 PROTO.localhost-v6.rev
			named.conf.orig rndc.conf
			named.conf.ORIGINAL s
			named.core sendzones.pl
			named_head</pre>

			and all the zonefiles are inside the 's' directory as they are on ns1c. So to restore a zonefile you'd simply copy it from the 's' directory on backup1 back to <tt>/etc/namedb/s</tt> on ns1c:

			scp 69.55.230.11:/data/www/daily/12-12-28/mnt/data1/ns1c-dir/etc/namedb/s/zonefile /etc/namedb/s

			For good measure, increment the serial and restart bind.

			Similarly, if you need to restore zones deleted from named.conf you can edit named.conf on backup1 and copy the domain blocks over to the live named.conf on ns1c, or you could copy over named.conf itself back to ns1c. This can be dangerous especially if you're potentially overwriting any changes which occurred after the backup was run.


	= Setup BIND =		= Setup BIND =

70.230.212.110: /* DNS Management and Operations */

2012-11-08T23:47:29Z

DNS Management and Operations

← Older revision		Revision as of 16:47, 8 November 2012
Line 14:		Line 14:
	server is its own purpose-built dedicated physical machine.		server is its own purpose-built dedicated physical machine.

	ns1c is a FreeBSD jail that lives on mail.johncompanies.com		ns1c is a FreeBSD jail that lives on mail.johncompanies.com<br />
	ns2c is a FreeBSD jail that lives on jail18
	ns3c is a FreeBSD jail that lives on nat2 at i2b		ns2c is a FreeBSD jail that lives on jail18<br />

			ns3c is a FreeBSD jail that lives on nat2 at i2b<br />


	All nameservers were built exactly according to the sections below. A notable reference:		All nameservers were built exactly according to the sections below. A notable reference:

70.230.212.110 at 23:42, 8 November 2012

2012-11-08T23:42:11Z

← Older revision		Revision as of 16:42, 8 November 2012
Line 1:		Line 1:
	~~_TOC_~~		__TOC__

	= DNS Management and Operations =		= DNS Management and Operations =

70.230.212.110 at 23:42, 8 November 2012

2012-11-08T23:42:02Z

← Older revision		Revision as of 16:42, 8 November 2012
Line 1:		Line 1:
			_TOC_

	= DNS Management and Operations =		= DNS Management and Operations =
	Dns requests make up about 1/3 - 1/2 of all support requests. On the one hand, they are very easy requests to fulfill - but on the other hand, it		Dns requests make up about 1/3 - 1/2 of all support requests. On the one hand, they are very easy requests to fulfill - but on the other hand, it

70.230.212.110 at 23:41, 8 November 2012

2012-11-08T23:41:49Z

← Older revision		Revision as of 16:41, 8 November 2012
Line 1:		Line 1:
	= DNS Operations =		= DNS Management and Operations =
	Dns requests make up about 1/3 - 1/2 of all support requests. On the one hand, they are very easy requests to fulfill - but on the other hand, it		Dns requests make up about 1/3 - 1/2 of all support requests. On the one hand, they are very easy requests to fulfill - but on the other hand, it
	is important to understand exactly how dns works at johncompanies, and how to repair or rebuild it. Dns is one of two things (the firewall being the other) that could destroy the business forever if it fails and is not solved very quickly.		is important to understand exactly how dns works at johncompanies, and how to repair or rebuild it. Dns is one of two things (the firewall being the other) that could destroy the business forever if it fails and is not solved very quickly.

70.230.212.110: /* DNS Operations */

2012-11-08T23:41:25Z

DNS Operations

Show changes