Date: Fri, 10 Jan 2003 15:18:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Roman Neuhauser <hackers@freebsd.org> Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" ... ]
[ ... ]
> 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.
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.
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.
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.
If we look at providing a packaged solution for use by people who
aren't computer programmers or UNIX system administrators, which
is the case of the original poster, then you have to come up with
a setup that has a minimal number of toggled states (via UI
toggles) to cover all potential allowed configurations; in this
case, we are talking three use cases:
1) Real primary for domain is hosted by ISP, because hosted
services are not permitted to drop offline, simply because
the device is transiently connected.
2) Real primary domain is on the external port, and the
border device is connected full time.
3) Real primary domain is hosted by ISP, because hosted
services are not permitted to drop offline, simply because
the permanent link fails.
There's actually a 4th use case, where initial pages are cached
and forwarded, but it requires additional ISP infrastructure to
implement (e.g. "Encanto Networks").
Basically, you need to be able to GUI-config the device to one
of these roles, and to permit it to change roles, as needed, to
deal with customer "upgrades" and changes in ISP connectivity
(this effectively commoditizes ISP's to nothing more than "IP
dialtone", which is pretty much what they want, since they could
care less if you sell boxes, and all they want is minimized
customer contacts, because those eat into their profit margin).
> 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.
> > > 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. This has several drawbacks
in a predominantly Microsoft client network. The main one of
these is that the client credential is no longer automatically
established with the domain controller (the user gets beat up
for a second login into the network), and the client machines do
not have their forward and reverse IP addresses configured into
the DNS automatically (a feature of the Microsoft DHCP/DNS server
combination, which can be imitated only if you support DNSUPDAT),
which is necessary to avoid things like the 30/90 second DNS
reverse lookup timeouts that stated this mailing list thread.
Note that, even if we choose your solution, we are still required
to make two administrative modifications to DNS servers for each
host that's both internally and externally visible in the domain.
> > 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.
We are talking about systems that are deployed in locations where
there are no UNIX or network administrators employed.
> > The problem is that you don't have a resolv.conf for your Windows
> > box, you only ohave the ability to specify a single DNS server in
> > your DHCP configuration, and if your DHCP server is a Windows box
> > (which it must be, if you expect to use certain Windows networking
> > features), then the DNS server it refers to will be the DHCP server;
> > that means you can't refer to both.
>
> are we talking about DNS or "certain Windows networking features"? :)
We are talking about minimizing support calls, the costs of
which come out of your bottom line.
This is the difference between building a product in the
expectation that it will be used by 10's of people, vs. one
that will be used by 1000's of people.
Support infrastructures are nearly impossible to scale linearly,
even if you wanted to scale them that way (which you *don't*).
> > 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.
> > > > 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.
>
> 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. The primary use of a transient link
in an office environment is, #1, cacheable DNS requests. The
secondary use is for HTTP requests for cacheable content.
The reason HTTP forward proxy-caches work at all is locality of
reference (e.g. "Doug sends an email to Sheila with the URL of a
cartoon depicting a product manager herding cats wearing glasses
and pocket protectors"). Avoiding the additional requests is a
means of link optimization.
> > > 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.
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).
> > > > 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?".
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.
One of the issues here is that it's not possible, without
additional cost, to obtain ISP forwarding servers in all parts of
the world. As an example, in Japan, ISP DNS servers are firewalled,
because in Japan, you are charged for packets sent, and making DNS
requests to an ISP's forwarding server drives up the ISP's costs.
So typically, if you buy ISP service for NTT or Ricoh or any one
of the top 5 ISP's, unless you are on their cable plant for a
broadband system, they will not provide forwarding DNS for you.
If you're on a broadband, they will *force* you to use their DNS
forwarders, because they will firwall direct requests by you
(again: to keep their costs down).
Revenue models make idiots of us all...
> > > > Note that even though your resolver is internally authoritative,
> > >
> > > this is an oxymoron. a resolver (cache) cannot not be authoritative.
> >
> > Interior port DNS server configured into the resolv.conf on the
> > border router, and used by applications there.
>
> ok. IOW, a nonauthoritative cache.
Yes. Sorry, if that wasn't clear.
> > > 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". ;^).
> > > 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...
> > 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 fact that *you* can't do it because of limitations in software
> > > you use has nothing to do with split horizon per se, or the number
> > > of content servers it requires.
> >
> > Yes, yes, we know, it's acceptable to ignore "must implement" RFCs,
> > if you disagree with them, too, isn't it? You, DJB, and Microsoft
> > know better than all the rest of us on the IETF DNSEXT working group,
> > don't you?
>
> heh. take a shower.
8-) 8-).
-- Terry
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?3E1F54D3.64C85686>