Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Apr 2002 13:55:57 -0500
From:      Mate Wierdl <mw@thales.memphis.edu>
To:        freebsd-chat@freebsd.org
Subject:   Re: qmail (Was: Maintaining Access Control Lists )
Message-ID:  <20020415135557.A16400@thales.memphis.edu>
In-Reply-To: <3CB4D277.51F744B8@mindspring.com>; from tlambert2@mindspring.com on Wed, Apr 10, 2002 at 05:01:59PM -0700
References:  <20020403144539.A11798@thales.memphis.edu> <3CAB7860.EB8DF505@mindspring.com> <20020410163728.A25502@thales.memphis.edu> <3CB4D277.51F744B8@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 10, 2002 at 05:01:59PM -0700, Terry Lambert wrote:
> Mate Wierdl wrote:
> > It certainly can happen that the advice given in an rfc turns out to
> > be ill in the wild after a time.  DNS over TCP, for example, turns out
> > to be prone to DOS attacks, and is much slower.
> 
> UDP and TCP themselves are prone to DOS attacks, so you aren't saying
> anything here.

I meant "DNS over TCP is more prone".

> > In case of tinydns, there is no data to be reloaded: data is stored in
> > a file.  Is "reloading data" defined to be the same as "looking up a
> > record from a file"?  And pushing the new data to the slave happens
> > immediately after the update on the master.
> 
> What about *during* the push?  You add latency to the time it
> takes for a change to take effect.  For practical application,
> e.g. an "ETRN" from a dial-on-demand transiently connected mail
> server, this implies an intentional latency between the "demand"
> (the contacting of the remote mail server for the purposes of
> "ETRN", which is what causes the link to be brought up) and the
> execution of the remainder of the act that initiated the "demand".
> In other words, you have to put an arbitrary delay that is 2*N + 1,
> where N is the latency in making the transient DNS record for the
> dial-on-demand mail server's dynamically assigned IP address
> visible to the DNS serving the remote mail server.

You are right, dynamic assignments you describe are not supported by
djbdns.  

The above is a real problem for big ISPs only.  The existing tools
provide a fast enough update of the tinydns data file, without
requiring any further configuration of tinydns.

As for larger ISPs, being able to incrementally update a cdb file
would probably solve the problem.  The beauty (for me) of this
solution would be that it would not require implementing new
standards, and would not require any additional configuration items
for the sysadmin.


> > > Here's my argument:
> > >
> > >       "All DNS data transfers should take place over the
> > >        DNS protocol."
> > 
> > Well, this requirement results in complexity, and lots of reinventing
> > the wheel.
> 
> Oh well.  Here's my favorite reformulation of Occam's Razor:
> 
> 	"Anything that works is better than anything that doesn't"
> 
> > In case of tinydns, transferring data is equivalent with transferring
> > a file.  Perhaps you suggest that the transfer should take place over
> > the DNS protocol because of firewall considerations.
> 
> Yes.
> 
> > But exactly the
> > added complexity will necessarily result in security problems.
> 
> I have yet to see a proof of this assumption that complexity is
> a sufficient (or even necessary) condition for insecurity.

You certainly can make a convincing case; for example, see section 2.1
in

http://www.counterpane.com/ipsec.pdf

I wonder which of the general comments in that paper do not apply to
DNSSEC.

> > And then there is DNSSEC.  It seems to be so complex that it may
> > defeat its own purpose: improve security.  For example, at
> > 
> > http://www.oreilly.com/catalog/dns4/chapter/ch11.html
> > 
> > I read:
> > 
> >   We realize that DNSSEC is a bit, er, daunting. (We nearly fainted
> >   the first time we saw it.)
> > 
> > Indeed, even without DNSSEC, apparently 24% of .com servers have
> > misconfigured delegations.
> 
> That's mostly because servers with misconfigured delegations
> aren't automatically considered non-authoritative (effectively
> diking them out of the internet).  Having your servers diked off
> the internet is a wonderous incentive toward correctness.  It
> even works for SPAM.

I am not sure I follow: designing complex systems is OK, but let us
get tough on those who fail to understand these systems?

> > 
> > It is not irrelevant because it does hint at the problems with IQUERY,
> > and at the fact that clients do not send IQUERY anymore.  Hence it is
> > unlikely that users will suffer from this lack of compliance.
> 
> It is better to comply with a bad standard, than to be in limbo
> between standards.
> 
> FreeBSD pthreads were incredibly screwed up for a while, when they
> were being moved from Draft 4 compliance to final standard compliance;
> as Draft 4, they were usable; as standard, they would also be usable.
> But in between... it was nearly impossible to make them work.
> 
> In the realm of the internet, the moral equivalent is compliance
> with standards documents: without compliance, you lose all features
> which derive from interoperability, and if that interoperability
> failure is between clients and servers, rather than servers, you
> lose everything.

I could accept your argument, but I still do not see how not following
the standards to the letter for IQUERY, which is

---a threat to security 
---not implemented in clients anymore,

can cause DNS interoperability problems.  

Mate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020415135557.A16400>