Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2002-12-31 Thread Gregory Neil Shapiro
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 
queries.  Nothing needs to be fixed in FreeBSD's nameserver.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2002-12-31 Thread Terry Lambert
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 
> 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  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
/A6 requests that fail that way, instead, if the delay
bthered me (which it doesn't).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2002-12-31 Thread Claus Assmann
On Wed, Jan 01, 2003, Peter Much wrote:

> 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 andLAN 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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-01 Thread 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 
! > 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 "" 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 "" 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 [EMAIL PROTECTED], 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  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  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 Broken
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, 

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-01 Thread Terry Lambert
Peter Much wrote:
> 6. Then it asks the nameserver for the "" 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 "" 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
> ! /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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-06 Thread Peter Much
! > 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.
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  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 Broken hack.
3. Configure IPv6 in the LAN.

regards,
Peter

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-06 Thread Terry Lambert
Peter Much wrote:
> ! 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 Broken 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-07 Thread Peter Much
On Mon, Jan 06, 2003 at 03:37:26PM -0800, Terry Lambert wrote:

! > 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-08 Thread Terry Lambert
Peter Much wrote:
> ! 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-09 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-06 17:36:52 +0100:
> ! > 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-09 Thread 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  = 360 (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 underst

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-09 Thread Terry Lambert
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
(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

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 si

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-09 Thread Terry Lambert
Peter Much wrote:
> ! 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-10 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-09 12:48:03 -0800:
> To: Roman Neuhauser <[EMAIL PROTECTED]>

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
>

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-10 Thread Terry Lambert
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?

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?

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-10 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> To: Roman Neuhauser <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (Mail Delivery System)   
To: [EMAIL PROTECTED] (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 : Helo command rejected: need fully-qualified hostname 
 In:  HELO stork
 Out: 504 : 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.

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-10 Thread Terry Lambert
Roman Neuhauser wrote:
> > So, do you manually put "yahoo.com" SOA records in your DNS?
> 
> no.
> 
> > How do you answer requests for "yahoo.com".
> 
> it's simple:

[ ... "I have a DNS caching server that forwards all requests,
   except those to "bellavista.cz"; for those, it does
   content redirection on the request to another server
   whose sole purpose in life is to answer those requests,
   while refusing all other requests" ... ]

[ ... ]
> my real setup is this: 10.0.0.1 is the router, and I have a DNS
> cache on 10.0.0.25, and a content server authoritative for
> bellavista.cz on 10.0.0.26. or at least it thinks it's
> authoritative, and the cache is configured to short-circuit all
> queries about bellavista.cz to 10.0.0.26.
> 
> now, this setup might actually look a bit different. suppose the
> outside IP of my router (62.168.44.50) is listed as an authoritative
> server for bellavista.cz, and suppose I forward all traffic for
> 62.168.44.50:53 to 10.0.0.26:53. the content nameserver can then
> provide different answers based on the client's IP address.
> nonrecursive queries (RD bit cleared; "gimme an authoritative
> answer") about lilith.bellavista.cz comming from 10.0.0/24 will be
> answered with 10.0.0.1, while those coming from anywhere else will
> get 62.168.44.50. and so on.

In "bind", this is called a "view".  I noted previously that this
can be accomplished with bind version 9.

The thing that makes this different is that you are consuming
multiple internal IP addresses for your seperate DNS servers.
While this is possible, it's generally not recommended, because
of Windows stupidity.

As far as splitting the responses by source IP address: that only
works by default if all machines in the domain are interior to
the local network, and all machines which are externally visible
are dual-homed.  Many DSL lines these days are done via a /2,
which means they are limited to 2 routable addresses.

As far as whether or not the external interface is a real primary,
a stealth primary, or a stealth secondary, really depends on the
configuration of the connection.

If we look at providing a packaged solution for use by people who
aren't computer programmers or UNIX system administrators, which
is the case of the original poster, then you have to come up with
a setup that has a minimal number of toggled states (via UI
toggles) to cover all potential allowed configurations; in this
case, we are talking three use cases:

1)  Real primary for domain is hosted by ISP, because hosted
services are not permitted to drop offline, simply because
the device is transiently connected.

2)  Real primary domain is on the external port, and the
border device is connected full time.

3)  Real primary domain is hosted by ISP, because hosted
services are not permitted to drop offline, simply because
the permanent link fails.

There's actually a 4th use case, where initial pages are cached
and forwarded, but it requires additional ISP infrastructure to
implement (e.g. "Encanto Networks").

Basically, you need to be able to GUI-config the device to one
of these roles, and to permit it to change roles, as needed, to
deal with customer "upgrades" and changes in ISP connectivity
(this effectively commoditizes ISP's to nothing more than "IP
dialtone", which is pretty much what they want, since they could
care less if you sell boxes, and all they want is minimized
customer contacts, because those eat into their profit margin).

> again, the content server only knows about names within/under
> bellavista.cz, it doesn't need to know the root servers. the cache
> is recursive, so it does.

Clearly, you have either written your own cache, or you are using
DJB's cache, with patches.


> > > Hmm? Are you talking about having both a cache and a content server
> > > on a router? The interior Windows clients of course only query the
> > > cache, so you can have the content server on 127.0.0.1. And, BTW, I
> > > don't see why I couldn't have more than one address on the inside
> > > interface, cache on one, content/authoritative server on another.
> >
> > Because your Windows clients could contact only one of them.
> 
> sure. Windows clients ask the cache, which in turn asks the content
> server.

This works, if you cache maintains a fixed IP address, and if
you can configure Microsoft's DHCP server to give out the IP
address of your cache for it's DNS.  This has several drawbacks
in a predominantly Microsoft client network.  The main one of
these is that the client credential is no longer automatically
established with the domain controller (the user gets beat up
for a second login into the network), and the client machines do
not have their forward and reverse IP addresses configured into
the DNS automatically (a feature of the Microsoft DHCP/DNS server
combin

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-09 Thread Peter Much
On Thu, Jan 09, 2003 at 12:07:19PM -0800, Terry Lambert wrote:

! 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-12 Thread Roman Neuhauser
thanks for not cc'ing me.

# [EMAIL PROTECTED] / 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 menti

Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-12 Thread David O'Brien
On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> 
> 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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-12 Thread Terry Lambert
David O'Brien wrote:
> On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > > Cc: [EMAIL PROTECTED]
> >
> > 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-13 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800:
> On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > > Cc: [EMAIL PROTECTED]
> > 
> > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-13 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-12 21:57:25 -0800:
> David O'Brien wrote:
> > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > > > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > > > Cc: [EMAIL PROTECTED]
> > >
> > > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-13 Thread Dan Nelson
In the last episode (Jan 13), Roman Neuhauser said:
> # [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800:
> > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > > > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > > > Cc: [EMAIL PROTECTED]
> > > 
> > > 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
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?

2003-01-13 Thread Roman Neuhauser
# [EMAIL PROTECTED] / 2003-01-13 11:49:15 -0600:
> In the last episode (Jan 13), Roman Neuhauser said:
> > # [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800:
> > > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote:
> > > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800:
> > > > > To: Roman Neuhauser <[EMAIL PROTECTED]>
> > > > > Cc: [EMAIL PROTECTED]
> > > > 
> > > > 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
[EMAIL PROTECTED]

-- 
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant ?

2003-01-13 Thread Rahul Siddharthan
Roman Neuhauser wrote:
> 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: sendmail: how to get the named of FreeBSD4.7 standards compliant ?

2003-01-13 Thread Mark Murray
> Roman Neuhauser wrote:
> > 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message