Re: Action behind firewalls

[brisco@rab.ieee.org (Thomas P. Brisco)]

	I've seen a number of circumstances where "fake primaries"
make a lot of sense - and certainly firewalls are one of the more
obvious (in certain highly-distributed high-load environments they
are very nice to have also).
	Randy mentioned that these configurations (speak out, Randy,
if I'm off target here) cause problems with the NOTIFY code.  Obviously
some level of heuristics could be done to determine the actual 
dependency graph -- but such logic doesn't seem appropriate in this
context -- we should have an a-priori knowledge of the relationships
based upon the configuration file.  I.e. we mayn't really want
yet-another-hack.
	At some previous meeting I'd mentioned the idea of peered
primaries.  At some level, I believe (functionally) that this is
similar to Randy's observation of tertiary (and so forth) servers.
If we go with Randy's inclinations (which sound appropriate to me),
then we need to describe the graph of servers anyway.
	Pushing hard on the issue of tertiary servers and NOTIFY
raises some interesting thoughts.  If we can indicate (via the
config file) which hosts to notify upon a zone update -- is this
a communitive operator?  I.e. if we've got a three-deep graph,
does the third tier download from the second tier (which may be
preferred) or from the primary tier?
	Here at the IEEE, we've got a few office sites that I'm 
working to make as network resilient as possible.  The configuration
looks something like:

                                              congested T1
                         firewall                to NY
	engine.ieee.org     |      rab.ieee.org    |   pub.ieee.org
	 "primary" NS       |      "primary" NS    |   "primary" NS
         to the outside     |      to the inside   |   to NY offices

                                  [a few machines]     omega.ieee.org
                                  "secondary" NS       "secondary" NS
                                  to various LANs      to NY offices

for obvious reasons I'd prefer the NY machines to talk amongst
themselves, and the other machines to talk amongst themselves, and
a minimum of (unnecessary) communication across the T1.

	The current approach to strictly primary/secondary doesn't
deal well with these configurations.  Hacks to make it work make
features like NOTIFY harder to deal with.  Whether we call it
peered-primaries, or tertiaries is rather moot -- I think it is
time to address what is apparently a real-world need ...

								Tp.

Don Lewis writes:
 [on "fake primaries" outside of a firewall]
 > There are two reasons that this won't work:
 > 	1) When name server (B) starts up, it will send a query for a list
 > 	   of the root servers to one of the root servers listed in it's
 > 	   root.cache.  Server (A) will respond with a list of the real
 > 	   root servers, which (B) will try to send it's queries to
 > 	   thereafter.
 >         2) If you somehow manage to get around problem (1), server (B)
 > 	   will only send non-recursive queries to server (A).  Server (A)
 > 	   will answer with whatever data is in its zone files and cache.
 > 	   Server (A) will not forward the queries out to the external
 > 	   world.  If server (B) listed server (A) as it's forwarder, then
 > 	   server (B) would send it's queries to server (A) with the
 > 	   recursion desired bit set, which would cause server (A) to
 > 	   forward the queries to the outside world if necessary.
 > 
 > 			---  Truck
 > 


-- 
==                                                              ==
Thomas P. ``Tp'' Brisco                 t.brisco@ieee.org  (email)
Director of Operations                  +1.908.562.6525    (voice)
        and Electronic Communications   +1.908.562.1727    (fax)
IEEE I.S.