sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much
Under certain circumstances, when sending mail, the mail will
appear in the local spool directory as
Deferred: Operation timed out with otherhost.domain
while observably there has no timeout happened: the sendmail
has returned just immediately from the failing delivery
action.
It is said in the documentation and on the net, that this problem
comes from a broken or bad configured nameserver, and the sendmail
resolver option "WorkAroundBrokenAAAA" is just a workaround and
the correct solution would be to fix the broken nameservers.
While it is true that the said sendmail-option solves the problem
(if sendmail is new enough to understand it), I could nowhere find
information on how to fix the bug in the nameserver - that is,
in the nameserver that is packaged with FreeBSD 4.4 or 4.7.
Input is utterly appreciated; while the sendmail workaround is
available on FreeBSD 4.7, it was not yet implemented on 4.4,
and I do not like to upgrade all of the machines (at least
not for a mere Workaround).
The nameservers are vanilla as in the distribution:
disp# named -v
named 8.2.4-REL Sun Dec 2 00:47:20 GMT 2001
ro...@tow.oper.dinoex.org:/usr/obj/usr/src/usr.sbin/named
gate# named -v
named 8.3.3-REL Wed Dec 25 07:53:05 CET 2002
ro...@dyn.oper.dinoex.org:/u/4-STABLE/obj/u/4-STABLE/src/usr.sbin/named
Please, if anybody knows how to fix this nameserver; please
tell me!
Attached is a log of what is happening actually, there
are two systems "disp" and "gate" involved. "gate" is the
mailhub, and "disp" wants to send a mail to it:
Hostname: disp (127.0.0.1) gate (127.0.0.1)
OS: FreeBSD 4.4 FreeBSD 4.7
Interface: disp-e (192.168.98.5) gate-e (192.168.98.2)
dynIP outbound
Nameserver: LAN Primary and LAN Slave
forwarder to "gate" named.root file is here
The hostnames are associated to the lo0 Interfaces (and
mentioned in /etc/hosts), they have MX pointing to their
respective LAN interfaces.
"disp" has these nameservice-relevant sendmail.mc options:
FEATURE(relay_based_on_MX)
FEATURE(`nocanonify', `canonify_hosts')
FEATURE(`accept_unresolvable_domains')
define(`SMART_HOST', `gate')
BTW: As soon as the outbound internet connection is available
and we have root nameservers accessible, the problem goes away.
# mail pmc@dyn
Subject: test
test
^D
# sendmail -d1-10.9 -q
getla: 0
getauthinfo: root@localhost
;; res_query(5.98.168.192.in-addr.arpa, 1, 12)
;; res_mkquery(0, 5.98.168.192.in-addr.arpa, 1, 12)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59759
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; 5.98.168.192.in-addr.arpa, type = PTR, class = IN
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Gregory Neil Shapiro
pmc> (if sendmail is new enough to understand it), I could nowhere find
pmc> information on how to fix the bug in the nameserver - that is,
pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7.
FreeBSD's nameserver is fine. The problem is the remote nameserver
authorative for the domain in question. That nameserver is incorrectly
returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for AAAA
queries. Nothing needs to be fixed in FreeBSD's nameserver.
Terry Lambert
> pmc> While it is true that the said sendmail-option solves the problem
> pmc> (if sendmail is new enough to understand it), I could nowhere find
> pmc> information on how to fix the bug in the nameserver - that is,
> pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7.
>
> FreeBSD's nameserver is fine. The problem is the remote nameserver
> authorative for the domain in question. That nameserver is incorrectly
> returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for AAAA
> queries. Nothing needs to be fixed in FreeBSD's nameserver.
However, it's possible to address the problem by placing a
caching-only nameserver between you and the nameserver with
the problem, and hitting the local nameserver, and letting it
recurse only if the data isn't in cache. This will address
the second and subsequent requests, but the first one will
still take however long it takes the proxy request to time
out, before the cache is loaded (and converts the SERVFAIL
into a NODATA, but only for AAAA or A6 requests that receive
no response or a SERVFAIL response).
It's also possible to rip out IPv6 support entirely, which is
what the people who won't fix their nameserver software are
tacitly recommending.
It's also possible to achieve the same effect by creating a
proxy that rejects all IPv6 address requests immediately with
NODATA (or NXDOMAIN), which has the benefit of still screwing
up IPv6 deployment, but without mutilating all the applications.
I would be real tempted to automatically generate complaint
email to the technical contact in the whois database for all
AAAA/A6 requests that fail that way, instead, if the delay
bthered me (which it doesn't).
-- Terry
Claus Assmann
> Attached is a log of what is happening actually, there
> are two systems "disp" and "gate" involved. "gate" is the
> mailhub, and "disp" wants to send a mail to it:
>
> Hostname: disp (127.0.0.1) gate (127.0.0.1)
> OS: FreeBSD 4.4 FreeBSD 4.7
> Interface: disp-e (192.168.98.5) gate-e (192.168.98.2)
> dynIP outbound
> Nameserver: LAN Primary and LAN Slave
> forwarder to "gate" named.root file is here
>
> The hostnames are associated to the lo0 Interfaces (and
> mentioned in /etc/hosts), they have MX pointing to their
> respective LAN interfaces.
>
> "disp" has these nameservice-relevant sendmail.mc options:
> FEATURE(relay_based_on_MX)
> FEATURE(`nocanonify', `canonify_hosts')
> FEATURE(`accept_unresolvable_domains')
> define(`SMART_HOST', `gate')
> BTW: As soon as the outbound internet connection is available
> and we have root nameservers accessible, the problem goes away.
>
> # mail pmc@dyn
What is "dyn"?
> Subject: test
> test
> ^D
> # sendmail -d1-10.9 -q
> getla: 0
> getauthinfo: root@localhost
> ;; res_query(5.98.168.192.in-addr.arpa, 1, 12)
> ;; res_mkquery(0, 5.98.168.192.in-addr.arpa, 1, 12)
> ;; res_send()
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59759
> ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; 5.98.168.192.in-addr.arpa, type = PTR, class = IN
What's in the logfile?
What's the output of:
date | sendmail -d0.13 -d8.8 -v pmc@dyn
PS: news:comp.mail.sendmail might be more appropriate.
Peter Much
! Gregory Neil Shapiro wrote:
! > pmc> While it is true that the said sendmail-option solves the problem
! > pmc> (if sendmail is new enough to understand it), I could nowhere find
! > pmc> information on how to fix the bug in the nameserver - that is,
! > pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7.
! >
! > FreeBSD's nameserver is fine. The problem is the remote nameserver
! > authorative for the domain in question. That nameserver is incorrectly
! > returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for AAAA
! > queries. Nothing needs to be fixed in FreeBSD's nameserver.
Sorry, Gregory, but You missed me entirely.
What I am talking about is a limited test environment consisting
_only_ of FreeBSD Systems. So what You name "the remote nameserver"
is very well (or not well, in this case) a FreeBSD 4.4 or 4.7
nameserver!
What is actually happening (I investigated further with tcpdump)
is the following:
(When I say "local" i mean the local machine, when i say "remote"
i mean another machine in the limited test environment, when i
say "outbound" i mean a linkup from the environment to the internet.)
1. a mail for remote delivery is locally created.
2. the local sendmail has the directive smarthost "gate".
3. the local nameserver is master/primary for the test environment
domain, which is "oper.dinoex.org" (this does not exist in the
real world). This nameserver has an MX for "gate" pointing to
"gate-e", which is the LAN network interface name of "gate".
It also has an A record for "gate-e".
4. sendmail asks the nameserver for various things during its
startup and while parsing the mail (local interfaces, final
destination hostname) - all of these work as to be expected.
5. sendmail enters delivery mode and asks for the MX record for
"gate", and gets "gate-e.oper.dinoex.org".
6. Then it asks the nameserver for the "AAAA" record of
"gate-e.oper.dinoex.org" (which does not exist - the
nameserver answers by sending the zonefile header (seems
ok?). Then sendmail asks again for the "AAAA" record of
"gate-e" (without domain). Now the local nameserver does
not answer, but tries to propagate the query up!
If there is an outbound connection active, this query will
go out to some internet forwarder (or possibly the root
nameservers), and from there likely return as not existing -
then the mail will be delivered. But if there is currently
no outbound connection available, then this query will
return with SERVFAIL, and then sendmail does put the mail
into "deferred" state.
Background: This environment should be configured to use
an internet connection for internet-relevant things, but to
work flawlessly without such a connection as long as matters
do concern only systems within the LAN. That means, if
I write a mail to hac...@freebsd.org, then it is obvious
that there will be outbound traffic to lookup and verify this
hostname (and likely the mail will be deferred if the outbound
linkup is inactive).
But if I write a mail to another system within the LAN,
this has to work without an outbound connection. And usually
it does, except for this AAAA lookup of the unqualified
mail hub interface adress.
! However, it's possible to address the problem by placing a
! caching-only nameserver between you and the nameserver with
! the problem, and hitting the local nameserver, and letting it
Difficult, as this nameserver runs on the local host.
! recurse only if the data isn't in cache. This will address
! the second and subsequent requests, but the first one will
! still take however long it takes the proxy request to time
! out, before the cache is loaded (and converts the SERVFAIL
! into a NODATA, but only for AAAA or A6 requests that receive
! no response or a SERVFAIL response).
!
! It's also possible to rip out IPv6 support entirely, which is
! what the people who won't fix their nameserver software are
! tacitly recommending.
Yes, Ted, I understand well. And I see a lot of workarounds
to get rid of the problem - the most simple would be to just
upgrade all sendmail binaries so they understand the BrokenAAAA
option. (Or even simpler in this case, to keep the internet
connection up all time.)
But this is, now that I have tracked and understood the problem,
not my primary intention. Now I want to understand what is
actually going wrong here and why. I do not think that my
approach -to have an environment that is able to access the
internet and is also able to run on its own- is essentially
wrong. But in this case I am not even sure who is to blame:
named or sendmail, or my named configuration (rather cookbook)
- and while I am quite good in understanding mail matters,
I am not all too experienced concerning nameservers or even
IPv6. So I feel the need for a bit of competence gathering.
Another matter is: this stuff is obviously creating network
traffic and load on the root nameservers. What good for?
And anyway, I would not have posted to "hackers" if I thought
this a trivial matter.;-)
! I would be real tempted to automatically generate complaint
! email to the technical contact in the whois database for all
! AAAA/A6 requests that fail that way, instead, if the delay
! bthered me (which it doesn't).
Well, in this case that technical contact would be me, and
that's why I'm asking. ;-))
rgds,
PMc
Terry Lambert
> 6. Then it asks the nameserver for the "AAAA" record of
> "gate-e.oper.dinoex.org" (which does not exist - the
> nameserver answers by sending the zonefile header (seems
> ok?). Then sendmail asks again for the "AAAA" record of
> "gate-e" (without domain). Now the local nameserver does
> not answer, but tries to propagate the query up!
> If there is an outbound connection active, this query will
> go out to some internet forwarder (or possibly the root
> nameservers), and from there likely return as not existing -
> then the mail will be delivered. But if there is currently
> no outbound connection available, then this query will
> return with SERVFAIL, and then sendmail does put the mail
> into "deferred" state.
>
> Background: This environment should be configured to use
> an internet connection for internet-relevant things, but to
> work flawlessly without such a connection as long as matters
> do concern only systems within the LAN.
This is called a "split horizon DNS", and you need to run two
DNS servers, one interior, and one exterior, both authoritative
for your domain, in order for this to work. The problem is that
you are forwarding a request that should be local, and you are
doing it because your local server does not pass the authority
test for your local domain.
I have been told that BIND 9 can solve this problem with two
different "views"; however, I do not believe it. I wrote a
BCP RFC for this, which ended up not getting published, as I
did not push it on the promise that the views would solve the
problem, and arrive much sooner than they did. I believe it
is still available from:
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt
> Yes, Ted, I understand well. And I see a lot of workarounds
"Terry", not "Ted". 8-).
> Another matter is: this stuff is obviously creating network
> traffic and load on the root nameservers. What good for?
To replace the IPv4 traffic entirely, eventually.
> ! I would be real tempted to automatically generate complaint
> ! email to the technical contact in the whois database for all
> ! AAAA/A6 requests that fail that way, instead, if the delay
> ! bthered me (which it doesn't).
>
> Well, in this case that technical contact would be me, and
> that's why I'm asking. ;-))
The easist answer to that is to find DNS software that responds
correctly, and tell them to change software.
-- Terry
Peter Much
! > an internet connection for internet-relevant things, but to
! > work flawlessly without such a connection as long as matters
! > do concern only systems within the LAN.
!
! This is called a "split horizon DNS", and you need to run two
! DNS servers, one interior, and one exterior, both authoritative
! for your domain, in order for this to work. The problem is that
! you are forwarding a request that should be local, and you are
! doing it because your local server does not pass the authority
! test for your local domain.
Well, I think I got it now. What I did not know was that any
nameserver installation is expected to always have some kind
of root nameserver accessible (either the real ones from the
internet, or elseways a local shortcut) in order to function
properly.
Failing this seems not to hurt as long as only hostnames and
domains are resolved which actually do exist in the zone files.
But when sendmail (or the resolver) doesn't find an AAAA record
for some FQDN, it next tries to resolve the short hostname - and
the local nameserver seems not to consider itself authoritative
for an unqualified hostname (which would be indistinguishable from
a TLD, anyway).
! I have been told that BIND 9 can solve this problem with two
! different "views"; however, I do not believe it. I wrote a
! BCP RFC for this, which ended up not getting published, as I
! did not push it on the promise that the views would solve the
! problem, and arrive much sooner than they did. I believe it
! is still available from:
!
! ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt
Yes, this paints my configuration.
And now I do not think that a "split horizon" configuration could
solve my problem at all. Because if it could tell me that my
unqualified hostname does not exist (without querying the outside),
then it would also tell me that FreeBSD.org does not exist...
So I see only three strategies:
1. Keep the internet connection available at anytime.
2. Use the BrokenAAAA hack.
3. Configure IPv6 in the LAN.
regards,
Peter
Terry Lambert
> ! I have been told that BIND 9 can solve this problem with two
> ! different "views"; however, I do not believe it. I wrote a
> ! BCP RFC for this, which ended up not getting published, as I
> ! did not push it on the promise that the views would solve the
> ! problem, and arrive much sooner than they did. I believe it
> ! is still available from:
> !
> ! ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt
>
> Yes, this paints my configuration.
> And now I do not think that a "split horizon" configuration could
> solve my problem at all. Because if it could tell me that my
> unqualified hostname does not exist (without querying the outside),
> then it would also tell me that FreeBSD.org does not exist...
That's not entirely true.
The normal way to handle this is to define a domain for your
internal machines, and then make the DNS server authoritative
for it. The domain most people use for this is "link.local"
or ".local", or "example.com".
It's actually pretty easy to spend the $10/year and register a
real domain for you, and then use that, instead, as the local
domain.
With your local DNS server being authoritative for that domain
(having an SOA record for the domain name), then it can tell
when hosts do or don't exist there.
So if I look up an unqualified "froboz", it's assumed to be in
the local domain because of the DNS suffix every machine is using,
and every machine is using it, either because you told it to, or
because that's what the DHCP server told it to use, when it handed
each machine it's IP address.
> So I see only three strategies:
> 1. Keep the internet connection available at anytime.
> 2. Use the BrokenAAAA hack.
> 3. Configure IPv6 in the LAN.
4. Claim "link.local" as your domain name, stuff it into your
DHCP server as the domain name it hands out to machines when it
hands out IP addresses, and then stuff an SOA record for it into
your local DNS server (and an SOA record for 168.192.in-addr.arpa.,
or whatever your local non-routed network addresses are, on the
interior side of your NAT).
This is more a "How Do I Set Up A LAN Inside A NAT?" question,
than it is anything else...
-- Terry
Peter Much
! > And now I do not think that a "split horizon" configuration could
! > solve my problem at all. Because if it could tell me that my
! > unqualified hostname does not exist (without querying the outside),
! > then it would also tell me that FreeBSD.org does not exist...
!
! That's not entirely true.
!
! The normal way to handle this is to define a domain for your
! internal machines, and then make the DNS server authoritative
! for it. The domain most people use for this is "link.local"
! or ".local", or "example.com".
Done this. It is ".oper.dinoex.org" - I think this should do.
! With your local DNS server being authoritative for that domain
! (having an SOA record for the domain name), then it can tell
! when hosts do or don't exist there.
Done this. So, if I lookup "schnarz.oper.dinoex.org", then I get
"Non-existent host/domain".
! So if I look up an unqualified "froboz", it's assumed to be in
! the local domain because of the DNS suffix every machine is using,
! and every machine is using it, either because you told it to, or
! because that's what the DHCP server told it to use, when it handed
! each machine it's IP address.
Exactly. And when this is not found, then the resolver will
inplicitly issue another query for the unqualified name.
And it is even worse with sendmail, because sendmail does quite
interesting things there - like switching off RES_DEFNAMES -
so this one will definitely not add the local domain.
regards,
Peter
Terry Lambert
> ! So if I look up an unqualified "froboz", it's assumed to be in
> ! the local domain because of the DNS suffix every machine is using,
> ! and every machine is using it, either because you told it to, or
> ! because that's what the DHCP server told it to use, when it handed
> ! each machine it's IP address.
>
> Exactly. And when this is not found, then the resolver will
> inplicitly issue another query for the unqualified name.
>
> And it is even worse with sendmail, because sendmail does quite
> interesting things there - like switching off RES_DEFNAMES -
> so this one will definitely not add the local domain.
This is broken in 2 ways:
1) The default names option in the standard resolver will prevent
another query for the unqualified name, since unqualified names
are supposed to get the local domain name, unconditionally.
2) It's possible to change the resolver flags in sendmail by
adding lines to the M4 file source code. You need to look
at the source tree and read cf/README.
-- Terry
Roman Neuhauser
> ! > Background: This environment should be configured to use
> ! > an internet connection for internet-relevant things, but to
> ! > work flawlessly without such a connection as long as matters
> ! > do concern only systems within the LAN.
> !
> ! This is called a "split horizon DNS", and you need to run two
> ! DNS servers, one interior, and one exterior, both authoritative
> ! for your domain, in order for this to work. The problem is that
> ! you are forwarding a request that should be local, and you are
> ! doing it because your local server does not pass the authority
> ! test for your local domain.
>
> Well, I think I got it now. What I did not know was that any
> nameserver installation is expected to always have some kind
> of root nameserver accessible (either the real ones from the
> internet, or elseways a local shortcut) in order to function
> properly.
This is wrong in at least two ways.
An authoritative content server doesn't need to know root servers,
because they're out of it's business.
A non-recursive (forwarding-only) resolver doesn't need to know
root servers, just the upstream resolver it forwards all requests
to.
--
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
Peter Much
! > Exactly. And when this is not found, then the resolver will
! > inplicitly issue another query for the unqualified name.
! >
! > And it is even worse with sendmail, because sendmail does quite
! > interesting things there - like switching off RES_DEFNAMES -
! > so this one will definitely not add the local domain.
!
! This is broken in 2 ways:
Hmm... possibly.
! 1) The default names option in the standard resolver will prevent
! another query for the unqualified name, since unqualified names
! are supposed to get the local domain name, unconditionally.
I'm sorry, my named.log shows it the other way round - as does
the debug mode of nslookup:
--------------------------------------------------------------------
$ nslookup
Default Server: localhost.oper.dinoex.org
Address: 127.0.0.1
> set debug
> wurz [defnames is set by default]
Server: localhost.oper.dinoex.org
Address: 127.0.0.1
;; res_nmkquery(QUERY, wurz.oper.dinoex.org, IN, A)
------------
Got answer:
HEADER:
opcode = QUERY, id = 56443, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz.oper.dinoex.org, type = A, class = IN
AUTHORITY RECORDS:
-> oper.dinoex.org
ttl = 3600 (1H)
origin = disp-e.oper.dinoex.org [this is localhost]
mail addr = admin.disp.oper.dinoex.org [this is me]
serial = 20011217
refresh = 3600 (1H)
retry = 900 (15M)
expire = 3600000 (5w6d16h)
minimum ttl = 3600 (1H)
------------
;; res_nmkquery(QUERY, wurz, IN, A)
timeout [here it starts dialing out!]
------------
Got answer:
HEADER:
opcode = QUERY, id = 56444, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz, type = A, class = IN
AUTHORITY RECORDS:
-> (root)
ttl = 10800 (3H)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2003010801
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
------------
*** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain
> set nodefnames
> wurz
Server: localhost.oper.dinoex.org
Address: 127.0.0.1
;; res_nmkquery(QUERY, wurz, IN, A)
------------
Got answer:
HEADER:
opcode = QUERY, id = 56445, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz, type = A, class = IN
AUTHORITY RECORDS:
-> (root)
ttl = 10701 (2h58m21s)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2003010801
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
------------
*** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain
----------------------------------------------------------
! 2) It's possible to change the resolver flags in sendmail by
! adding lines to the M4 file source code. You need to look
! at the source tree and read cf/README.
Been there, done it, got the t-shirt. I walked thru the whole
code there, only to find lots of niceies like the following
- from daemon.c:
-----------------------------------------------------
if (host[0] == '[')
{
[some stuff deleted]
}
else
{
/* contortion to get around SGI cc complaints */
{
p = &host[strlen(host) - 1];
hp = sm_gethostbyname(host, family);
if (hp == NULL && *p == '.')
{
# if NAMED_BIND
int oldopts = _res.options;
_res.options &= ~(RES_DEFNAMES|RES_DNSRCH);
# endif /* NAMED_BIND */
*p = '\0';
hp = sm_gethostbyname(host, family);
*p = '.';
# if NAMED_BIND
_res.options = oldopts;
# endif /* NAMED_BIND */
}
}
-----------------------------------------------------
Now this looks correct, because the second call to
sm_gethostbyname hits only on FQDNs with terminating dot
- but then sm_gethostbyname() in conf.c will not care
about the resolver-flags at all and will shorten all
unresolveable hostnames that do not have a terminating
dot to their first component and retry with that.
So even if we have a full qualified hostname with
terminating dot, it will end up with a resolver query
for the first name component - and that gets treated
just like in the debug log above.
Now, as far as I am considered, I think I have had enough of this
stuff. I have understood from the code why it behaves the way it
does, have learned a bit about name resolution, and now either
have to live with it the way it is, or change the code in a way
I like.
rgds,
PMc
Terry Lambert
> > ! This is called a "split horizon DNS", and you need to run two
> > ! DNS servers, one interior, and one exterior, both authoritative
> > ! for your domain, in order for this to work. The problem is that
> > ! you are forwarding a request that should be local, and you are
> > ! doing it because your local server does not pass the authority
> > ! test for your local domain.
> >
> > Well, I think I got it now. What I did not know was that any
> > nameserver installation is expected to always have some kind
> > of root nameserver accessible (either the real ones from the
> > internet, or elseways a local shortcut) in order to function
> > properly.
>
> This is wrong in at least two ways.
>
> An authoritative content server doesn't need to know root servers,
> because they're out of it's business.
The authoritative server must also be a forwarding server. This
is because of both the way the resolver library itself works
(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. 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.
> 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.
If you reference a completely authoritative interior server, with
no forwarding, and the resolver stops there, then the exterior
server is not referenced.
This is complicated, both as noted above, for Windows clients
(it would require a second IP address on the interior network,
minimally, to resolve), and by the fact that the IP address of
the external interface is unknown until after link-up, 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.
Note that even though your resolver is internally authoritative,
for the Internet's view of the world, an external resolver for
the domain is likly authoritative, instead. Specifically, you
will be running hosted primary for www.example.com and for the
MX records for example.com.
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.
The problem comes down to round-tripping local changes to the DNS,
e.g. DHCP leases, etc.. If you can solve the round-tripping
problem, you can, in fact, deal with this via the DNSNOT mechanism.
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
It is a trivial change, but can increase the root load. The way
to avoid this is to mandate caching, and only transit to the root
if the name server is not where it was previously (e.g. as a result
of an ISP reconfiguration while the secondary was offline). An
expiration time for the cache is not relvent, in that this has to
do with claim of authority; if the SOA is stale, then it serves as
the timeout.
In addition to this, to resolve authority issues, we have to
recognize the seperation of control between transiently and
non-transiently connected servers.
I did not mention this before, since the problem under discussion
was how to *avoid* lookups, requiring a link-up operation, for
fully qualified DNS names which were not defined locally; making
this modification requires careful reconfiguration.
Specifically, the external primary is considered to be in a
delegated subdomain of the locally authoritative domain; for
lookups direct to the name server, the subdomain is implied in
the operation.
This, too, requires a modification of the DNS server implementation.
The simplest way is to replace the proposed DNAME extension with
another. Specifically, Example #4 in the following document will
cover this case:
Proxy Subdomain Delegation
<draft-lambert-dns-pns-00.txt>
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-pns-00.txt
In this example, we rename requests in one domain to be requests
in another domain, and proxy them; as an example, we can proxy
requests for www.ext.example.com (the "external web server for the
company example.com") to an external primary that appears to the
Internet as "example.com". The proxy operation causes the lookup
to occur in the "delegated subdomain ext.example.com", which in
fact is a delegated proxy lookup in the authoritative server for
ext.example.com to the externally authoritative server example.com.
This "www.ext.example.com" interior to the proxy becomes "www.example.com"
exterior to the proxy, in the external primary DNS that *also* thinks
it is authoritative for "example.com". The issue is that if your
border server is not truly primary, and not truly authoritative,
then referencing the server that is is arbitrarily difficult without
this.
-- Terry
Terry Lambert
> ! 1) The default names option in the standard resolver will prevent
> ! another query for the unqualified name, since unqualified names
> ! are supposed to get the local domain name, unconditionally.
>
> I'm sorry, my named.log shows it the other way round - as does
> the debug mode of nslookup:
What are the precise contents of your /etc/resolv.conf?
> ! 2) It's possible to change the resolver flags in sendmail by
> ! adding lines to the M4 file source code. You need to look
> ! at the source tree and read cf/README.
>
> Been there, done it, got the t-shirt. I walked thru the whole
> code there, only to find lots of niceies like the following
> - from daemon.c:
[ ... ]
> Now, as far as I am considered, I think I have had enough of this
> stuff. I have understood from the code why it behaves the way it
> does, have learned a bit about name resolution, and now either
> have to live with it the way it is, or change the code in a way
> I like.
Naturally, I personally believe all problems are solvable, and
Greg can answer on the resolution of names in sendmail for this
second case, but I understand your losing interest.
-- Terry
Peter Much
! What are the precise contents of your /etc/resolv.conf?
search oper.dinoex.org
nameserver 127.0.0.1
nameserver 192.168.98.2
rgds,
PMc
Roman Neuhauser
> To: Roman Neuhauser <neuh...@bellavista.cz>
please don't cc me.
> Roman Neuhauser wrote:
> > > ! This is called a "split horizon DNS", and you need to run two
> > > ! DNS servers, one interior, and one exterior, both authoritative
> > > ! for your domain, in order for this to work. The problem is that
> > > ! you are forwarding a request that should be local, and you are
> > > ! doing it because your local server does not pass the authority
> > > ! test for your local domain.
> > >
> > > Well, I think I got it now. What I did not know was that any
> > > nameserver installation is expected to always have some kind
> > > of root nameserver accessible (either the real ones from the
> > > internet, or elseways a local shortcut) in order to function
> > > properly.
> >
> > This is wrong in at least two ways.
> >
> > An authoritative content server doesn't need to know root servers,
> > because they're out of it's business.
>
> The authoritative server must also be a forwarding server.
> This is because of both the way the resolver library itself works
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.
I don't know how the Bind library works, but I know that the
authoritative server I use has now idea of roots.
> (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.
> 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?
> > 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?
> 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
> This is complicated,
I don't think so.
> 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
2. trivial to add
> 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?
> 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.
> Note that even though your resolver is internally authoritative,
this is an oxymoron. a resolver (cache) cannot not be authoritative.
> 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? this was about split horizon?!
primary/secondary is:
1. Bindism
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.)
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.
<snip>
--
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 majo...@FreeBSD.org
Terry Lambert
> 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?
How do you answer requests for "yahoo.com".
> > (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.
> > 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?
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.
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?!?
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.
> > 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.
> 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.
> > 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.
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?!?
> > 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.
> > 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".
If you want to partcipate in this thread, please refrain from
proselytizing us about DJBDNS. Thanks.
> 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; your ISP will *maybe* permit DNSSEC
and DNSUPDAT, however. Speaking from personal experience as "your
ISP" (IBM Web Connection NOC, Rochester, NY).
> 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?
-- Terry
Roman Neuhauser
> To: Roman Neuhauser <neuh...@bellavista.cz>
> Cc: hac...@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...@mail.bellavista.cz (Mail Delivery System)
To: postm...@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.
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.
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 majo...@FreeBSD.org
Terry Lambert
> > 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
Roman Neuhauser
# tlam...@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 majo...@FreeBSD.org
David O'Brien
> # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > To: Roman Neuhauser <neuh...@bellavista.cz>
> > Cc: hac...@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.
Then make this clear -- YOU don't provide a Reply-to: or Followup-to:.
So Terry (and myself) aren't to blame.
Terry Lambert
> On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > > To: Roman Neuhauser <neuh...@bellavista.cz>
> > > Cc: hac...@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.
>
> Then make this clear -- YOU don't provide a Reply-to: or Followup-to:.
> So Terry (and myself) aren't to blame.
I guess he doesn't like it showing up in his mail logs, since if
it's via my ISP's mail server, the one to him directly bounces
anyway. Gotta wonder why anyone would care, if they never see the
thing anyway... 8-).
-- Terry
Roman Neuhauser
> On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > > To: Roman Neuhauser <neuh...@bellavista.cz>
> > > Cc: hac...@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.
>
> Then make this clear -- YOU don't provide a Reply-to: or Followup-to:.
> So Terry (and myself) aren't to blame.
I *do* make it clear:
1. I *do* send out the MFT header, but the freebsd.org MTA's strip
it.
2. I make my preference clear in the signature.
--
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 majo...@FreeBSD.org
Roman Neuhauser
> David O'Brien wrote:
> > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > > > To: Roman Neuhauser <neuh...@bellavista.cz>
> > > > Cc: hac...@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.
> >
> > Then make this clear -- YOU don't provide a Reply-to: or Followup-to:.
> > So Terry (and myself) aren't to blame.
>
> I guess he doesn't like it showing up in his mail logs, since if
> it's via my ISP's mail server, the one to him directly bounces
> anyway. Gotta wonder why anyone would care, if they never see the
> thing anyway... 8-).
No, that's not the reason. I just don't like getting cc's.
--
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 majo...@FreeBSD.org
Dan Nelson
> # obr...@FreeBSD.ORG / 2003-01-12 21:33:32 -0800:
> > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > > > To: Roman Neuhauser <neuh...@bellavista.cz>
> > > > Cc: hac...@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.
> >
> > Then make this clear -- YOU don't provide a Reply-to: or
> > Followup-to:. So Terry (and myself) aren't to blame.
>
> I *do* make it clear:
>
> 1. I *do* send out the MFT header, but the freebsd.org MTA's strip it.
Whoa. Who broke that?
--
Dan Nelson
dne...@allantgroup.com
Roman Neuhauser
> In the last episode (Jan 13), Roman Neuhauser said:
> > # obr...@FreeBSD.ORG / 2003-01-12 21:33:32 -0800:
> > > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > > # tlam...@mindspring.com / 2003-01-10 11:32:22 -0800:
> > > > > To: Roman Neuhauser <neuh...@bellavista.cz>
> > > > > Cc: hac...@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.
> > >
> > > Then make this clear -- YOU don't provide a Reply-to: or
> > > Followup-to:. So Terry (and myself) aren't to blame.
> >
> > I *do* make it clear:
> >
> > 1. I *do* send out the MFT header, but the freebsd.org MTA's strip it.
>
> Whoa. Who broke that?
No idea. I'm slowly trying to resolve this with
postm...@freebsd.org.
--
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 majo...@FreeBSD.org
Rahul Siddharthan
> No, that's not the reason. I just don't like getting cc's.
That's easily fixed: I recommend /usr/ports/mail/procmail.
You can't expect people on a mailing list to tailor their MUA
configuration to suit your choices. It's up to you to set up your own
MUA and filters to cater to your own pickiness.
- Rahul
Mark Murray
> > No, that's not the reason. I just don't like getting cc's.
>
> That's easily fixed: I recommend /usr/ports/mail/procmail.
>
> You can't expect people on a mailing list to tailor their MUA
> configuration to suit your choices. It's up to you to set up your own
> MUA and filters to cater to your own pickiness.
Amen!
Can we get back on topic now, please? :-)
M
--
Mark Murray
iumop ap!sdn w,I idlaH