On Mon, 2004-10-04 at 02:58, Tony Finch wrote:
On Mon, 4 Oct 2004, John Levine wrote:
Hmmn. We can't even get people to deploy a new DNS record type within
an existing well defined spec, and you're proposing a new scheme, ...
Thats because it means upgrading their DNS server, something no one
wants to do.
I look forward to learning why installing a new service which requires
upgrades to firewalls and NAT is easier than upgrading a DNS server.
I agree that people are reluctant to upgrade a DNS server, but they
seem to me far more reluctant to add a new server with unknown loads
and unknown security issues.
DNS-based call-back verification services do not require a DNS server
upgrade. All you need to do is install the stunt DNS server alongside your
existing DNS infrastructure and arrange for the appropriate NS delegation.
DNS comes with a lot of desirable infrastructure, most of which would have
to be duplicated by an alternative UDPCBV service -- especially cacheing,
service advertisement, and (eventually) cryptographic security. Even in
the absence of DNSSEC there is a lot of knowledge about DNS security which
would not necessarily apply to a new service.
DNS is bloated with feature creep especially BIND9. And given BIND's
security record I most certainly hope you aren't referring to it. I'm
not dead set against a callback mechanism used in DNS, however, that
would be my last resort. I have already authored the code to facilitate
the callbacks via UDP and I'll attempt to spend some time to add TCP
this week. This service currently supports caching through the use of
an AVL tree (any record can be obtained within 32 or less branches with
a capacity of 4,294,967,296 records). Adding a hash table or other
storage algorithm is trivial. Adding crypto to the service is also
rather trivial.
Re: security of the code, I've got several friends who work within the
security community and I've already requested an audit which I can
obtain freely from multiple parties upon request when the time is
appropriate. Will people use it? I'm certain there are those who
will. Will everyone use it? I can answer that with another question,
does everyone run the same DNS server? No. However, the code currently
(and I do intend to continue this trend) compiles and operates in both
Linux/BSD and Windows.
Re: the other features you mention, why they are just that, "features",
and not "functions". The service simply has to answer a request,
nothing more nothing less. Even adding the caching is questionable, and
is not compiled in by default. I think its more prudent to leave
caching to where it belongs, by the DNS servers which already do this
caching. Why reinvent the wheel? Hell the only reason I even bothered
with caching code (re: libSPF) is because everyone else was and
unfortunately there is a tasty speed benefit to be had by running a
local cache, but the added code only makes things take longer to reach
stable status and is thus undesirable at least from that point of view.
I'm also very sceptical about the need for a new UDPCBV service, despite
the fact that DNSCBV is rather too clever for comfort.
I think all I can say is that just because you can, doesn't mean you
should. I really enjoyed how the PGP people used their head and wrote
their own service (http://www.mit.edu/~marc/pks/pks-news.html) rather
than trying to shove that crap inside of DNS. You will note that it not
only makes sense but people are making good use of it. I think we are
in a very similar position here. Just because our MX records are
published in DNS doesn't mean anything else associated with e-mail
should be also.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://mipassoc.org/pipermail/ietf-clear/attachments/20041004/e100ade5/attachment.bin