Date: Sun, 12 Jan 2003 15:18:39 +0100 From: Roman Neuhauser <neuhauser@bellavista.cz> To: Terry Lambert <tlambert2@mindspring.com> Cc: Roman Neuhauser <hackers@freebsd.org> Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <20030112141839.GY1196@freepuppy.bellavista.cz> In-Reply-To: <3E1F54D3.64C85686@mindspring.com> References: <20030101181330.C8233@disp.oper.dinoex.org> <3E134659.78028611@mindspring.com> <20030106173652.A495@disp.oper.dinoex.org> <20030109132202.GG1196@freepuppy.bellavista.cz> <3E1DE003.73BF3025@mindspring.com> <20030110105903.GL1196@freepuppy.bellavista.cz> <3E1F1FC6.D5D33801@mindspring.com> <20030110214845.GW1196@freepuppy.bellavista.cz> <3E1F54D3.64C85686@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
thanks for not cc'ing me.
# tlambert2@mindspring.com / 2003-01-10 15:18:43 -0800:
> Roman Neuhauser wrote:
> > > So, do you manually put "yahoo.com" SOA records in your DNS?
> >
> > no.
> >
> > > How do you answer requests for "yahoo.com".
> >
> > it's simple:
>
> [ ... "I have a DNS caching server that forwards all requests,
> except those to "bellavista.cz"; for those, it does
> content redirection on the request to another server
> whose sole purpose in life is to answer those requests,
> while refusing all other requests" ... ]
actually, the DNS cache is recursive: it doesn't forward, it
resolves the names itself.
> [ ... ]
> > my real setup is this: 10.0.0.1 is the router, and I have a DNS
> > cache on 10.0.0.25, and a content server authoritative for
> > bellavista.cz on 10.0.0.26. or at least it thinks it's
> > authoritative, and the cache is configured to short-circuit all
> > queries about bellavista.cz to 10.0.0.26.
> >
> > now, this setup might actually look a bit different. suppose the
> > outside IP of my router (62.168.44.50) is listed as an authoritative
> > server for bellavista.cz, and suppose I forward all traffic for
> > 62.168.44.50:53 to 10.0.0.26:53. the content nameserver can then
> > provide different answers based on the client's IP address.
> > nonrecursive queries (RD bit cleared; "gimme an authoritative
> > answer") about lilith.bellavista.cz comming from 10.0.0/24 will be
> > answered with 10.0.0.1, while those coming from anywhere else will
> > get 62.168.44.50. and so on.
>
> In "bind", this is called a "view". I noted previously that this
> can be accomplished with bind version 9.
so I heard.
> The thing that makes this different is that you are consuming
> multiple internal IP addresses for your seperate DNS servers.
> While this is possible, it's generally not recommended, because
> of Windows stupidity.
I still don't understand this claim. The Windows boxen will never
ask the authoritative server, so I don't see any problem. There's
obviously none [that would affect my users], as this is exactly what
I do, and no machines have any trouble with resolving. That means
several FreeBSD boxes, several NT 5, NT 5.1, and a W98 box. No
problems whatsoever.
All these systems delegate name resolution to 10.0.0.25, which is a
*cache*, through /etc/resolv.conf or its windowsland counterpart.
The cache at 10.0.0.25 resolves names by recursing the name server
hierarchy rooted at {a..m}.root-servers.net with the exception of
bellavista.cz, which is short-circuited to 10.0.0.26.
> As far as splitting the responses by source IP address: that only
> works by default if all machines in the domain are interior to
> the local network, and all machines which are externally visible
> are dual-homed. Many DSL lines these days are done via a /2,
> which means they are limited to 2 routable addresses.
No, it only works by default if all the DNS *caches* are interior to
the local network, because the content DNS server is queried by the
cache, not the Windows client.
> As far as whether or not the external interface is a real primary,
> a stealth primary, or a stealth secondary, really depends on the
> configuration of the connection.
...
> Basically, you need to be able to GUI-config the device
you keep trying to divert the point of discussion. the OP has had
Bind ans Sendmail configured without a GUI configurator; nowhere did
he mention a need for one.
> > again, the content server only knows about names within/under
> > bellavista.cz, it doesn't need to know the root servers. the cache
> > is recursive, so it does.
>
> Clearly, you have either written your own cache, or you are using
> DJB's cache, with patches.
I use djbdns without any patches. I might not have expressed myself
clearly:
"the content server only knows about names within/under
bellavista.cz, it doesn't need to know the root servers. the cache
is recursive, so it does need to know them."
> > > > Hmm? Are you talking about having both a cache and a content server
> > > > on a router? The interior Windows clients of course only query the
> > > > cache, so you can have the content server on 127.0.0.1. And, BTW, I
> > > > don't see why I couldn't have more than one address on the inside
> > > > interface, cache on one, content/authoritative server on another.
> > >
> > > Because your Windows clients could contact only one of them.
> >
> > sure. Windows clients ask the cache, which in turn asks the content
> > server.
>
> This works, if you cache maintains a fixed IP address, and if
> you can configure Microsoft's DHCP server to give out the IP
> address of your cache for it's DNS.
the OP has FreeBSD on both the router/NAT and the inside box.
nowhere did he mention using windows or DHCP.
> > > Where was *your* second nameserver again? I see a nameserver on
> > > 10.0.0.{1,2}; where is your nameserver on 1.2.3.4?
> >
> > DNS works just fine with one authoritative server. requiring two is
> > an administrative decision, and nothing in the protocol enforces it.
>
> This presumes a caching DNS server, which is willing to "split the
> view" on your behalf. This is, I admit, a possibility, but it's an
> administrative headache.
I don't see the connection between a domain being on a single
authoritative server, and a cache. The cache will query any name
server of those it got referred to; the number only has a lower
bound defined precisely (your nameserver might only listen on
udp/53, so the count'd be limited by what fits in a udp datagram).
> We are talking about systems that are deployed in locations where
> there are no UNIX or network administrators employed.
No we are taling about systems administered by the OP, which are
various versions of FreeBSD.
<snip>more unrelated problems</snip>
> > > And then, how does an internal client get the external IP "yahoo.com",
> > > if the requests are being dropped?!?
> >
> > I think I answered this.
>
> You did: a specialized proxy cache.
Does the ability to override the content server asked for a domain
base specialization? that depends on what you base your view of
generalness on.
if you ever used Windows 95, the ability to bind more than one IP to
and interface would probably make every other OS look highly
specialized.
> > > > > [This is complicated]
> > > > > both as noted above, for Windows clients (it would require a second IP
> > > > > address on the interior network, minimally, to resolve),
> > > >
> > > > which is:
> > > >
> > > > 1. not true in the sense that you can have the authoritative server
> > > > on 127.0.0.1 which is always there
> > >
> > > Then it's a proxy for the interior and exterior DNS servers running
> > > on your border device. It's also specially written, rather than
> > > using off-the-shelf software, since it can't be a standard bind.
right. it's a standard, off-the-shelf, no-patches, djbdns.
> > I don't think you'd want to provide a promiscuous DNS cache. it
> > should listen on the inside IP only.
>
> I really disagree with this.
so you think having a cache on your outer interface, so that anyone
on the internet can put your IP in their /etc/resolv.conf, and abuse
your resources, is a good idea? interesting. :)
> > > > 2. trivial to add
> > >
> > > I guess, if you have the source code to Windows TCP on hand. Last
> > > time I checked, this was millions of $ to license.
> >
> > err, did the OP have a Windows-based router? I thought it was
> > FreeBSD. even if the router used Windows, the cache nor the content
> > server has to live on it.
>
> Windows clients have certain protocol requirements and deficiencies,
> designed to lock you into using Microsoft-supplied servers (e.g. the
> inability to specify multiple servers for certain types of requests,
> NT Domain registration, etc.).
>
> It may not be an issue if you are an all-Linux or all-BSD office,
> but in most customer deployments, you can not avoid dealing with
> Windows.
again, the OP has specifically requested that others replying to his
question limit the scope of their emails to his environment, which
is a FreeBSD-4.7 box, and a FreeBSD-4.4 box:
"What I am talking about is a limited test environment consisting
_only_ of FreeBSD Systems."
> The issue here is trying to arrive at a general solution to the
> problem space, rather than trying to arrive at a particular way
> of doing things, and then bending your customer to your model (a
> good way to chase away a customer).
Hmmm, I just checked, and adding an IP on an XP box is a matter of
being able to operate the mouse. about 10 clicks; you don't even
need to restart. so, what source, what millions?
and, as I've already shown, Windows are perfectly happy in a setting
you seem to consider next to impossible. the only difference is I
don't use DHCP.
> > > > > and by the fact that the IP address of the external interface is
> > > > > unknown until after link-up,
> > > >
> > > > hm? what does the external IP have to do with this?
> > >
> > > It's where the other side of your horizon lives; it's where the
> > > external DNS server lives.
> >
> > do you say "it's the IP authoritative for the domain"? if so, the
> > OP will IMO have to use a service similar to dyndns.org anyway.
>
> That's a possibility, but the Windows clients I've seen for that
> have been seriously deficient. Technically, you've been able to
> change IP addreses, etc., without rebooting since Windows 98, but
> the damn thing will still prompt you "Reboot Now For Changes To
> Take Effect?".
a nonissue. the router is the dyndns, not the NATted windows
machines behind it.
> The actual implementation, in the dyndns.org case, requires more
> infrastructure than they really have available there. It's a
> partial solution, in that it doesn't support ASMTP and similar
> things, necessary for externally hosted infrastructure.
>
>
> > > > > which will generally occur well after the DHCP lease is granted to
> > > > > interior machines. This is even urther complicated by the fact
> > > > > that the DHCP server is likely to be a Windows Primary Domain
> > > > > Controller, and therefore not the border device, itself.
> > > >
> > > > i don't see how that's related.
> > >
> > > You can't give a DHCP lease pointing to a DNS server on the
> > > exterior interface, when you don't yet know the IP address of
> > > the exterior interface. How can you configure an unknown IP
> > > address?!?
> >
> > how can you publish the exterior interface as authoritative for a
> > domain when you don't yet knwo the IP address of the interface?
>
> The answer is that you modify the configuration of the internal
> DNS server, either via DNSUPDAT, or by modifying it's config files,
> and kicking it in the head, on link-up/link-down events. My own
> preference is to avoid the facial bruises. 8-).
>
> If the interior server then forwards requests to the external
> server, that forwards to the ISP's forwarding servers (if it can),
> then you are OK.
no, forget caches. I asked about something else: how do you publish
*to the outsied world* that your NS RR ns1.domain.tld has the IP
a.b.c.d if you don't know the IP? How do you get a domain registered
if you don't know the name server IP's?
> > > > primary/secondary is:
> > > >
> > > > 1. Bindism
> > >
> > > OK, I now see that you are engaged on a religious crusade against
> > > "bind".
> >
> > no I'm not.
> >
> > > If you want to partcipate in this thread, please refrain from
> > > proselytizing us about DJBDNS. Thanks.
> >
> > hmmm? where did I mention djbdns? stop putting things I didn't (mean
> > to) say in my mouth please.
>
> At this point, it's the only viable competitor to bind, at least
> on my radar; I'd be interested in seeing an alternative, but by
> condemning "primar/secondary" as a "bindism", it kind of shows
> that whatever you're using, it's not "bind". ;^).
more implementations use Bind's configuration data format, and
probably zone transfers. it's just that this is not the only way of
syncing the configuration among one's nameservers, and, IMO, zone
transfers are a prime example of reinventing the wheel, and have
zero relevance to the merit of DNS, which is publishing name<->ip
bindings.
even if it's obvious I don't use bind, I don't see what of my post
made you think I was on any kind of crusade. also, you say you are
interested in seeing a viable alternative, but don't want to hear
about alternative implementations. interesting.
> > > > 2. administrative concept. *I* can modify the data on either of the
> > > > *authoritative* servers and rsyns+ssh the data to the other. It
> > > > doesn't matter which way the data goes at all. (It is actually
> > > > always done from A to B because the data is preprocessed and I only
> > > > want to transfer the compiled form.)
> > >
> > > Your ISP will not permit this;
> >
> > my ISP couldn't care less. I don't know about yours.
>
> My ISP doesn't allow the modification of their databases via
> an rsyc from a remote client. They are annoyed enough at
> having to actually provide Internet connectivity, instead of
> me just sending them money for no service at all...
So your ISP's name servers are authoritative for your domain[s].
That's not my setup.
> > > your ISP will *maybe* permit DNSSEC and DNSUPDAT, however. Speaking
> > > from personal experience as "your ISP" (IBM Web Connection NOC,
> > > Rochester, NY).
> >
> > aha. I'm glad you're not my ISP. I wouldn't be your customer for long.
>
> You can't get shell accounts from most ISPs in the U.S., either.
The only service I need from my ISP is connectivity. The boxes are
my own (as in: my employer's).
Terry, if you want to keep this thread alive any longer (and want
followups from me), keep it focused. No further pulling "dumb
windows DHCP server" rabbits from the hat, please.
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030112141839.GY1196>