Magnus Holmgren wrote:
> On Saturday 07 April 2007 20:37, Jason_Meers wrote:
>> However external-domain-one.example and external-domain-two.example are
>> to be delivered by a dnslookup router. Now that I am using the
>> 192.0.2.0/24 range I can no longer use dnslookup to route messages as
>> the Exim servers in the examples can no longer contact any DNS servers
>> (Yes I understand the irony of creating an isolated network then being
>> surprised that I can no longer query DNS servers).
>>
>> RFC 3330 says:
>> 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
>> documentation and example code. It is often used in conjunction with
>> domain names example.com or example.net in vendor and protocol
>> documentation. Addresses within this block should not appear on the
>> public Internet.
>>
>> I Would like to keep the 192.0.2.0/24 addresses but I would also like to
>> be able to have a dnslookup router for showing how dnslookup deliveries
>> work.
>
> Can't you assume that there is a NAT (*shiver*) router between the example
> network and the public Internet?
I had considered it, I don't think anything in RFC 3330 specifically
says that you shouldn't connect the TEST-NET range to another range.
However if somebody is going to follow the tutorial and expect it to
work I'll have to explain how to setup NAT or a dual-honed host with
forwarding.
Or a DNS and SMTP relay?
I didn't know that a DNS relay existed (unless you mean a forwarder that
needs access to the TEST-NET and another network (that does have DNS
servers).
> What prevents the
> server from querying name servers that are *also* on 192.0.2.0/24?
That is another possibility, however in my initial investigation about
this lead me to believe that providing instructions for building an
authorative name server for Exim to use is going to be harder to
document for all of the platforms that Exim is capable of running on,
and take up more space in the tutorial than the Exim tutorial itself
will be.
This is only a hunch, it is not based on any testing or facts. I may
have to go down this route in the end if the tutorial is to be
demonstrated and repeated by the reader (rather than just a conceptual
example that won't work in real life).
Why does
> your fictional network need to talk to the real world at all?
It doesn't if I can solve the MX record issues and keep the other hosts
on the TEST-NET. This is what I'm actually aiming for.
Can't you place
> all of the domains involved in 192.0.2.0/24?
I intend them to be, unless I have to make a compromise.
Thanks Magnus, I'm genuinely very grateful for your feedback.
It is not so much that I see this being an impossible problem to solve,
if anything it is deciding which of these compromises will produce the
best/most-useful/most-easy-to-understand documentation for the user who
picks it up and tries to follow it.
I'm still hoping that I can use Exim configuration and entries in the
host file to achieve a pseudo-MX-lookup, whilst still having a closed
environment that wont interfere with or break anything else (It would be
great if a complete test environment could be created on one machine
inside vmware)
Again thanks for your feedback Magnus.
Does anyone else have any opinions on this?
Jason_Meers
--
website at:
http://www.exim-new-users.co.uk
hosting by:
http://www.line3.co.uk
