Date: Wed, 10 Apr 2002 16:37:28 -0500 From: Mate Wierdl <mw@thales.memphis.edu> To: freebsd-chat@freebsd.org Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020410163728.A25502@thales.memphis.edu> In-Reply-To: <3CAB7860.EB8DF505@mindspring.com>; from tlambert2@mindspring.com on Wed, Apr 03, 2002 at 01:47:12PM -0800 References: <20020403144539.A11798@thales.memphis.edu> <3CAB7860.EB8DF505@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 03, 2002 at 01:47:12PM -0800, Terry Lambert wrote:
> Mate Wierdl wrote:
> A violation of a "SHOULD" is almost worse than a violation of
> a "MUST". A violation of a "MUST" has recourse: it's a bug.
> A violation of a "SHOULD" has no recourse.
>
> The problem with this is that it violates the Principle Of
> Least Astonisment (POLA); specifically, it violates the
> dictum that one should be generous in what one accepts, but
> strict about what one generates, with regard to protocols.
> Not accepting a "SHOULD" mandated request is hardly generous.
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.
In rfc1123, I read
Responsible practices can make UDP suffice in the vast
majority of cases.
and
However, it is also clear that some new DNS record
types defined in the future will contain information
exceeding the 512 byte limit that applies to UDP, and
hence will require TCP. Thus, resolvers and name
servers should implement TCP services as a backup to
UDP today, with the knowledge that they will require
the TCP service in the future.
Now djbdns certainly implement DNS over TCP---it just leaves it up to
the admin to, in fact, enable it as the need arises. The argument
boils down to what is enabled by default. Security, performance,
requirements registry, and knowing the size of my records dictates no
or limited TCP service availability.
> > > 3. The suggested method for copying contents of DNS zones is rsync,
> > > scp, or other remote copy tools. The DNS standard method of
> > > zone transfers (query type "axfr") is only supported as an
> > > additional, disrecommended method.
> >
> > Realizing the disadvantages of "axfr", the djbdns package allows the
> > sysadmin to use other, more secure, reliable and readily available
> > tools _in addition to_ "axfr". What is wrong with this flexibility?
>
> Firewalls.
I do not follow: so just keep axfr, and get rid off the additional
possibilities?
>
>
> > > 5. Without a patch from a third party, tinydns does not support the
> > > standard "NOTIFY" protocol of informing secondary nameservers
> > > that the zone has been updated, and that they need to check the
> > > SOA serial number and download a new copy (if they don't already
> > > have it).
> >
> > Which rfc describing the DNS standards requires NOTIFY?
>
> RFC 1996.
I am not clear on this (probably I did not ask the question clearly):
does rfc 1996 mandate the implementation of NOTIFY for servers?
> > Consider, for example, the fact that presently NOTIFY can alert
> > clients only about SOA record changes, and hence even if only a single
> > A record was added to the master's data, the client will have to
> > download the whole zone. At least this is my reading of rfc1996.
> >
> > Using rsync, of course, makes it possible to do only incremental
> > updates.
>
> The issue isn't about the amount of data that has to be
> transferred, it's about the stall barrier, when any data
> has to be reloaded.
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.
>
> > I am not saying that, in case of a non-trusting slave, there might not
> > be a need for a safe, reliable, etc way for a master server to
> > initiate a data file update (instead of a polling by the slave), but
> > this looks more like a problem that has nothing to do with the DNS
> > protocol.
>
> 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.
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. But exactly the
added complexity will necessarily result in security problems.
Your requirement seems to be potentially an enormous burden. I suppose
you agree that the security tools associated with DNS data transfer
should also be implemented inside the DNS protocol. But how about
requirements that are needed for these security tools to work? For
example, for TSIG to work, you need to synchronize time between the
master and slave. Should this time synchronization be done over the
DNS protocol? Afterall, the slave can be behind a firewall...
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.
Interestingly, R. Bush(!) was compelled to quote de Saint-Exupery
You know you have achieved perfection in design, not when you
have nothing more to add, but when you have nothing more to
take away.
at
http://psg.com/~randy/001213.ietf-dns/
>
>
> > In case of a trusting slave, though, rsync will push the changes over
> > to the slave as soon as they happen on the master.
>
> Plus the notice latency on the master, as the changes are polled,
> rather than event-triggered, plus the notice latency on the slave,
> for the same reasons.
>
Does not happen between two tinydns servers, though. The problem I
see is that of authentication: the recommended scheme for pushing new
data from a tinydns master to a tinydns slave assumes that the slave
trusts the master. What if the master is taken over by an attacker?
> This is actually hidden in djbdns, because of the reopening
> of the file each time. This reopening is another synchornization
> barrier, due to POSIX time update requirements.
>
> > > 7. You cannot set an alternative SOA contact address (other than
> > > what is hard-coded within tinydns), if you do not have a patch
> > > from a third party.
> >
> > Those who read the docs can see
>
> I believe he's referring to additional data, rather than replacement
> data, here...
I see, you may be right. Not all is lost, though: one can then use RP records.
> > We are looking at two only, so they must be the major ones.
> >
> > > A. When an IQUERY is sent to a djbdns server, it will
> > > respond with opcode set to QUERY. (it should simply
> > > copy the opcode, not make something up).
> >
> > Which currently in use client sends IQUERY? What does the 01/2002 draft
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt
> >
> > say about IQUERY?
>
> Whatever it says is irrelevent, until it is Standards Track.
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.
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?20020410163728.A25502>