[Twisted-Python] Re: Twisted.Names question

[Jp Calderone]

On Mon, Oct 06, 2003 at 09:12:47PM +0200, Rudy Schockaert wrote:
> [snip]
>
> I think it may help when I explain the problem.
>
 > There are a number of rather large organisations that each have their 
> own connection to the Internet. Besides this they are also connected to 
> a private WAN.
>
> The WAN provider wants to offer a kind of secure mail, in the sense that 
> email between these organisations is not routed over the Internet but 
> over the WAN. All traffic over the WAN is IPSec, thus secure.
> Reconfiguring all mail relay servers of all those organisations is an 
> impossible task and certainly not maintainable.
> The zone definitions for each of the organisations must remain 
> unchanged, other organisations must recieve the normal Internet address 
> as result on a MX query.
>
> The plan is to have a Twisted.Names server with only two caches and no 
> authorative zones or forwarders. The first cache will be preloaded with 
> MX records and A records that route the mail over the WAN. There will be 
> nothing in CacheResolver.cancel() so these entries are never removed. 
> When the records are served, they will be put in the last cache and stay 
> there for as long as the TTL dictates. This way I can override DNS 
> records without creating an authorative zone.
>
> Each organisation would have such a Twisted. Names server on 'the way 
> out'. The preloaded cache would then be synchronised with a centrally 
> managed Master Twisted.server.
> 
> Now, I proposed to have Twisted.Names forward queries it cannot resolv 
> itself  to the internet, but that seems unacceptable. They want that all 
> other queries are directly resolved by Internet DNS servers. They also 
> want the Master Twisted.Names server to act as a backup in case the 
> slave of the company is down or so. But on the other hand they don't 
> want all queries first sent to both Twisted.Names servers and only then 
> to the Internet. So they proposed to return referrals for each record 
> that is not in Twisted.Names.
> 

  This sounds like a complex problem, and I am by no means an expert,
however, I'll take a stab...

  Returning NS records of the authority for unhandled names is something
t.names doesn't support.  It should not be difficult to add, though.  This
would probably be done by creating a new kind of Resolver, once that just
looked up and return NS records, regardless of query type, and putting it at
the back of the resolver chain.

  Aside from implementing this, everything else for the scenario you
describe is probably already supported, the trick is just configuring all
the pieces properly.

  So, you probably want just two resolvers in a ResolverChain, in a server
running on the internal interface of each of these networks (I'm not sure if
this would be the WAN network, or a private network for each participating
organisation).  The first resolver would be your preloaded CacheResolver,
the second would be the new NS resolver described above.  Arguably the NS
resolver should be present in t.names for it to be a proper nameserver
anyway... but that is a different discussion :)

  I'm not sure I've said anything insightful, but I hope it helps.

  Jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/twisted-python/attachments/20031008/77f3f416/attachment.sig>