Date: Fri, 10 Jan 2003 22:48:46 +0100 From: Roman Neuhauser <neuhauser@bellavista.cz> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <20030110214845.GW1196@freepuppy.bellavista.cz> In-Reply-To: <3E1F1FC6.D5D33801@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>
next in thread | previous in thread | raw e-mail | index | archive | help
# tlambert2@mindspring.com / 2003-01-10 11:32:22 -0800:
> To: Roman Neuhauser <neuhauser@bellavista.cz>
> Cc: hackers@FreeBSD.ORG
you sent me a copy again, please, don't do it.
1. I don't want one, I'll read your message on the list.
2. it's futile: your provider's MTA breaks RFC 2821:
2.3.5:
...
The domain name, as described in this document and in [22], is the
entire, fully-qualified name (often referred to as an "FQDN"). A
domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
compare:
Date: Fri, 10 Jan 2003 20:34:09 +0100 (CET)
From: MAILER-DAEMON@mail.bellavista.cz (Mail Delivery System)
To: postmaster@mail.bellavista.cz (Postmaster)
Subject: Postfix SMTP server: errors from
+stork.mail.pas.earthlink.net[207.217.120.188]
Transcript of session follows.
Out: 220 mail.bellavista.cz ESMTP Postfix
In: EHLO stork
Out: 504 <stork>: Helo command rejected: need fully-qualified hostname
In: HELO stork
Out: 504 <stork>: Helo command rejected: need fully-qualified hostname
In: QUIT
Out: 221 Bye
your messages to freebsd.org go through one more hop that's
configured properly, so they get through.
now...
> Roman Neuhauser wrote:
> > You talked about nameservers and split horizon,
> > I talked about nameservers and split horizon.
> > Now you talk about Bind. Don't change the playground, please.
>
> You weren't really talking about split horizon, I think; a
> "horizon" in this case is any place you can't see over without
> a referral happening.
>
>
> > I don't know how the Bind library works, but I know that the
> > authoritative server I use has now idea of roots.
>
> So, do you manually put "yahoo.com" SOA records in your DNS?
no.
> How do you answer requests for "yahoo.com".
it's simple:
say you want to go to www.freebsd.org. your resolver sends a DNS
query to 10.0.0.1:53 where 10.0.0.1 is configured in your
/etc/resolv.conf. this query has the RD bit set.
the DNS cache at 10.0.0.1:53 (let's say it's just been flushed)
does need to know the roots, but were talking about authoritative
servers. read on.
your resolver sent out a recursive lookup (RD [Recursion Desired]
bit set). let's say the DNS cache at 10.0.0.1 doesn't forward, it
recurses itself instead. this is an example of such a lookup
(198.41.0.4 is a.root-servers.net):
roman@freepuppy ~ 1015:0 > dnsq a www.freebsd.org 198.41.0.4
1 www.freebsd.org:
339 bytes, 1+0+9+9 records, response, noerror
query: 1 www.freebsd.org
authority: org 172800 NS a7.nstld.com
authority: org 172800 NS l7.nstld.com
authority: org 172800 NS g7.nstld.com
authority: org 172800 NS f7.nstld.com
authority: org 172800 NS m5.nstld.com
authority: org 172800 NS j5.nstld.com
authority: org 172800 NS i5.nstld.com
authority: org 172800 NS c5.nstld.com
authority: org 172800 NS e5.nstld.com
additional: a7.nstld.com 172800 A 192.5.6.36
additional: l7.nstld.com 172800 A 192.41.162.36
additional: g7.nstld.com 172800 A 192.42.93.36
additional: f7.nstld.com 172800 A 192.35.51.36
additional: m5.nstld.com 172800 A 192.55.83.34
additional: j5.nstld.com 172800 A 192.48.79.34
additional: i5.nstld.com 172800 A 192.43.172.34
additional: c5.nstld.com 172800 A 192.26.92.34
additional: e5.nstld.com 172800 A 192.12.94.34
this says: "I don't know the IP of www.freebsd.org (IOW, I'm not
authoritative for it), but these are the authoritative servers for
.org., go ask there."
so the cache picks one those, and continues:
roman@freepuppy ~ 1016:0 > dnsq a www.freebsd.org 192.5.6.36
1 www.freebsd.org:
145 bytes, 1+0+4+1 records, response, noerror
query: 1 www.freebsd.org
authority: freebsd.org 172800 NS ns0.freebsd.org
authority: freebsd.org 172800 NS ns1.downloadtech.com
authority: freebsd.org 172800 NS ns1.iafrica.com
authority: freebsd.org 172800 NS ns2.downloadtech.com
additional: ns0.freebsd.org 172800 A 216.136.204.126
this says: "I'm not authoritative for www.freebsd.org, but I know
these servers are authoritative for freebsd.org. go ask there.
oh, and one of them is within my bailiwick, so I know its IP."
the cache just saved another lookup provided it picks this one up.
(if freebsd.org had all it's nameservers within the freebsd.org
domain, it would speed up lookups for names under freebsd.org
somewhat, because it the cache picks up one of the .com servers
authoritative for freebsd.org it has to return to the root servers,
ask for say ns1.iafrica.com, get referred to the servers
authoritative for .com, and so on)
the cache incidentally picks up the ns0.freebsd.org server (I'm
lazy).
roman@freepuppy ~ 1017:0 > dnsq a www.freebsd.org 216.136.204.126
1 www.freebsd.org:
243 bytes, 1+1+5+5 records, response, authoritative, noerror
query: 1 www.freebsd.org
answer: www.freebsd.org 3600 A 216.136.204.117
authority: freebsd.org 3600 NS ns0.freebsd.org
authority: freebsd.org 3600 NS ns1.iafrica.com
authority: freebsd.org 3600 NS ns1.downloadtech.com
authority: freebsd.org 3600 NS ns2.downloadtech.com
authority: freebsd.org 3600 NS ns2.iafrica.com
additional: ns0.freebsd.org 3600 A 216.136.204.126
additional: ns1.iafrica.com 18789 A 196.7.0.139
additional: ns1.downloadtech.com 76254 A 66.28.250.19
additional: ns2.downloadtech.com 76254 A 66.250.75.2
additional: ns2.iafrica.com 48169 A 196.7.142.133
voila, www.freebsd.org is 216.136.204.117, and we got an
*authoritative* answer.
the cache can now reply to the client with a *nonauthoritative*
answer.
compare this to a content nameserver. while a cache is thus
meant to provide *nonauthoritative* answers, a content nameserver
publishes hard data. where a cache replies with "I was told
that...", a content name server says "I can tell you ... because I'm
the final authority for it". this is its sole purpose. it should not
provide answers to queries about names it's not authoritative for.
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.
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.
> > > (single preference), and the fact that on a border router, you
> > > have only a single IP address on which to bind a DNS service,
> > > and therefore can offer only a single DNS service to interior
> > > machines.
> >
> > 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.
> > > While technically, some UNIX clients permit multiple
> > > definitaions in this case, practically, you can't take advantage
> > > of this, because you must deal with interior Windows clients
> > > machines, where this is not permitted.
> >
> > I don't know what you're talking about. Could you rephrase it?
>
> See above.
>
>
> > > > A non-recursive (forwarding-only) resolver doesn't need to know
> > > > root servers, just the upstream resolver it forwards all requests
> > > > to.
> > >
> > > Realize that this is not possible, with the current resolver
> > > library, since all programs will reference the single /etc/resolv.conf.
> >
> > Now it seems *you* don't know what your talking about.
> >
> > 1.2.3.5 <-- ISP's "name server" (in fact, recursive cache)
> > ^
> > |
> > v
> > 1.2.3.4
> > 10.0.0.{1,2} <-- my router, with a forwarding cache on 10.0.0.1
> > ^ and a content server (for, say, domain.local)
> > | on 10.0.0.2
> > v
> > 10.0.0.{3..10} <-- fbsd/windows boxes
> >
> > all my boxes, including the router, have 10.0.0.1 in
> > /etc/resolv.conf, and the cache on the router is configured to
> > forward all recursive queries to 1.2.3.5
> >
> > what's the problem?
>
> 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.
> 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"? :)
> The second problem is that 1.2.3.4 is a dialup address assigned by
> the ISP; this makes it impossible to run the DNS server there,
> unless the link is up, since it's the other end of a PPP conection.
>
> > > If you reference a completely authoritative interior server, with
> > > no forwarding, and the resolver stops there, then the exterior
> > > server is not referenced.
> >
> > A properly configured authoritative server will:
> >
> > 1. drop recursive queries
> > 2. drop queries for data it's not authoritative for
> >
> > anything else is asking for trouble
>
> And then, how does an internal client get the external IP "yahoo.com",
> if the requests are being dropped?!?
I think I answered this.
> The idea here is to not bring up the link for local traffic,
> including DNS traffic, but to bring the link up for non-local
> traffic. The point of the local DNS server being caching is
> *only* to avoid the 30 second timeout from the first lookup,
> which happens when it's the DNS traffic that causes the link
> to come up.
ok.
> > > This is complicated,
> >
> > I don't think so.
>
> That's because you haven't studied the problem for 4 years, like
> me, Archie Cobbs, and Julian Eisher, and then deployed a FreeBSD
> based commercial product to thousands of customers, like we did.
>
> > > 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.
> > 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.
> > > 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.
> I thought you read the document I posted? This is described in
> detail in the first diagram in that document.
>
> > > 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?
> > > 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.
> > > The only way for this to actually work is to split the authority
> > > for the example.com domain between two nameservers -- one interior,
> > > and one exterior. Partial delegation is simply not supported by
> > > the current DNS model.
> >
> > I don't know what partial delegation is, but I *do* know that I have
> > a split horizon here with one nameserver.
> >
> > > Unfortuanately, a transiently connected DNS server will not receive
> > > notifications from a primary DNS server, particularly when it is
> > > offline, but also for any state changes occurring while it is
> > > offline, unless it attempts a zone transfer (e.g. on link up).
> > > Zone transfers are not desirable in this case, since the authority
> > > is split; the closes you can get is a "blind secondary".
> > >
> > > To implement a blind secondary requires modification of the DNS
> > > server secondary declaration mechanism, to result in a serach
> > > from root by the secondary server, in order to locate the primary
> > > for the domain being served. For this to work, the syntax of
> > > the declaration of a secondary must be changes, and a zone transfer
> > > attempted on linkup.
> > >
> > > The syntax of a blind secondary is defined at:
> > >
> > > Blind Secondary DNS Extension
> > > <draft-lambert-dns-bsec-00.txt>
> > > ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt
> >
> > why do you keep talking about Bind?
>
> Because it's the industry standard DNS server?
>
> > this was about split horizon?!
>
> Actually, this was only about a Best Current Practices document
> for a split horizon on a dial-on-demand transiently connected
> border router.
>
> > 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.
> > 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.
> 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.
> > 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.
--
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?20030110214845.GW1196>