Hello Phil,
I moved this discussion to namedroppers and BCC-ed the IETF list,
please continue this part of the thread on namedroppers.
For namedroppers, the context is:
A discussion on draft-iab-dnsext-choices (the document) and the
pointer mechanism as described in [1].
I also do
--On 23. november 2006 08:18 -0800 Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
The draft is incomplete. It does not review all the technical options.
These were raised on the DNSEXT list months ago.
Where's the draft?
If you want there to be consensus on a draft then it has to put
are the drafts proposing the other options in choices?
-Original Message-
From: Harald Alvestrand [mailto:[EMAIL PROTECTED]
Sent: Friday, November 24, 2006 3:27 AM
To: Hallam-Baker, Phillip; Olaf M. Kolkman
Cc: ietf@ietf.org
Subject: RE: SRV records considered dubious
--On 23. november
Hallam-Baker, Phillip wrote:
The draft is in the repository, it was posted to the DNSEXT list in June.
http://www.ietf.org/internet-drafts/draft-hallambaker-dkimpolicy-00.txt
Oops, I still had that as I-D.hallambaker-pcon-00.txt in my repository,
the drafts are otherwise identical:
Hello Philip,
You wrote:
1) DKIM does not have a requirement for specifying default key
records. The need to solve the wildcarding problem does not
therefore arise and there is no TECHNICAL reason to prefer RR over
a prefixed record and significant DEPLOYMENT reasons to choose
prefixed
From: Olaf M. Kolkman [mailto:[EMAIL PROTECTED]
In general I think that we should make the 'being held
hostage' part into account when doing the tradeoff. Supose
'Bob' has vested interest in deploying protocol FOO and there
is an installed base of application X that does not work well
p.s. rather than adding more and more burdens to DNS, what we really
need to be doing is figuring out how to replace it with something more
robust and more flexible. (Yes, you'd have to arrange that DNS queries
and queries to the new database would return consistent results; you'd
also
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
No. It just means that the people spreading FUD have succeeded.
RFC 3597 (2003) formalised the handling of unknown RR types
and classes. The first draft was written in 2000 and it
described treating unknown RR's
From: John C Klensin [mailto:[EMAIL PROTECTED]
And, to add one more observation to Keith's list, unless one
is extremely careful, especially when considering using SRV
to add support for protocols that were defined without it,
one also risks recreating all of the problems that caused
We are currently seeing an explosion of new protocol development
using Web Services. It is long past time to declare UDDI a failure
and recognize that it isn't going to happen. But Web Services are
predicated on the existence of a signaling infrastructure.
if SRV works well for Web Services,
On Wed, 22 Nov 2006, Hallam-Baker, Phillip wrote:
Microsoft showed the source code to the MARID group. It simply does not
support saving unknown RR blobs.
Someone in the DNSEXT working group did a test that showed that if you
violate the administration model of Windows it is possible to
Hallam-Baker, Phillip [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
No. It just means that the people spreading FUD have succeeded.
[ ... ]
I really don't know why we are arguing about this anymore.
Adding new RR's has not been a real issue
On Tue, 2006-11-21 at 21:28 -0800, Dave Crocker wrote:
The MX record was, in fact, a great leap forward (after a number of
false starts.) I can tout its success vigorously because I had
nothing to do with it but have always marveled at how profound its
benefit has been. Indeed I'd be happy
From: Keith Moore [mailto:[EMAIL PROTECTED]
We are currently seeing an explosion of new protocol
development using
Web Services. It is long past time to declare UDDI a failure and
recognize that it isn't going to happen. But Web Services are
predicated on the existence of a
I don't expect there to be very many standards based protocols in the
future that are not Web Services.
I've seen lots of fads come and go, and so far I've seen nothing to
convince me that Web Services is not yet another fad. Time will tell.
Angle brackets are now as inescapable as ASCII was
Keith Moore wrote:
I don't expect there to be very many standards based protocols in the
future that are not Web Services.
I've seen lots of fads come and go, and so far I've seen nothing to
convince me that Web Services is not yet another fad. Time will tell.
Angle brackets are now as
The point is that the distributed information store that we
currently know as DNS is separable from the protocol that we call
DNS, and we can (if we are careful) design a new protocol that will
let us access that information store more flexibly while still
keeping the views consistent between
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sure, but is the trust anchor that DNS more importantly
provides? On
today's internet with all of the vested interests could the
devil we
don't know possibly be any better than the one we do?
so we shouldn't try to improve the Internet
I have noticed that whenever someone does propose to do just that you
come out and argue against it on vague, unsubstantiated grounds and
when asked to clarify promise to provide a more detailed refutation
at a later date.
it depends on whether my intuition and/or experience see a potential
--On Tuesday, 21 November, 2006 21:28 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
John C Klensin wrote:
And, to add one more observation to Keith's list, unless one
is extremely careful, especially when considering using SRV
to add
...
there are cases where SRV is useful, but it's a
From: Keith Moore [mailto:[EMAIL PROTECTED]
I have noticed that whenever someone does propose to do
just that you
come out and argue against it on vague, unsubstantiated grounds and
when asked to clarify promise to provide a more detailed
refutation at
a later date.
of course
From: John C Klensin [mailto:[EMAIL PROTECTED]
Whatever you mean by service model (I can think of several
definitions in this context), there are some important
differences. First, MX is based on an RR type that is very
protocol-specific. Nothing but email sending uses it.
Discussions
On Wed, 22 Nov 2006, Hallam-Baker, Phillip wrote:
For example every ISP has to spend time and money helping their
customers to configure their email clients to locate their POP3, IMAP
and SUBMIT servers.
Those costs could be eliminated if email clients looked at the relevant
SRV records
there is also a
tendency of people who have vague and/or poorly-thought-out
proposals to demand that other people invest more work
determining the nature of the problems with their proposals,
than they have themselves invested in analyzing either the
problem they purport to be
From: Keith Moore [mailto:[EMAIL PROTECTED]
okay, fine. while I'm sure they're useful, wildcard prefixed
DNS records is not a problem that I've seen a pressing need to solve.
Neither do I as a matter of fact. In the case of DKIM base it is utterly
unnecessary. We don't want that feature.
From: Tony Finch [mailto:[EMAIL PROTECTED] On Behalf Of
A matter that is close to my heart :-)
Why did this draft not get any further?
http://www.watersprings.org/pub/id/draft-hall-email-srv-02.txt
Looking back at something I wrote a year ago, I said that SRV
records don't provide
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
No. It just means that the people spreading FUD have succeeded.
RFC 3597 (2003) formalised the handling of unknown RR types
and classes. The first draft was written in 2000 and it
described treating unknown RR's
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Note it is possible to upgrade the DNS servers and *still*
have active directory support.
You lose the coupling of AD and DNS.
That seriously impair the DKIM/MARID value proposition. It is a major
infrastructure change.
On Nov 22, 2006, at 5:42 PM, Hallam-Baker, Phillip wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Note it is possible to upgrade the DNS servers and *still*
have active directory support.
You lose the coupling of AD and DNS.
Why do you say this? There are at least
The lack of protocol meta-data is a major reason for the difficulty of changing
IETF protocols. The SRV record is a great leap forward, it would be even better
if people actually used it to advertise their POP3, SUBMIT and IMAP services.
actually the SRV record can easily be a step sideways
DNS is getting very long in the tooth, and is entirely too inflexible
and too fragile. The very fact that we're having a discussion about
whether it makes more sense to add a new RR type or use TXT records with
DKIM is a clear indicator that something seriously is wrong with DNS.
Adding
--On Tuesday, 21 November, 2006 22:07 -0500 Keith Moore
moore@cs.utk.edu wrote:
actually the SRV record can easily be a step sideways or
backward if not carefully used. let's see...it slows down
session establishment; increases the load on DNS; increases
the potential for failures due to
No. It just means that the people spreading FUD have succeeded.
RFC 3597 (2003) formalised the handling of unknown RR types
and classes. The first draft was written in 2000 and it
described treating unknown RR's as opaque data blobs.
RFC 2535 (1999)
John C Klensin wrote:
And, to add one more observation to Keith's list, unless one is
extremely careful, especially when considering using SRV to add
...
there are cases where SRV is useful, but it's a big stretch to
call it a great leap forward.
As usual, I am confused.
The MX record
maybe I've missed it, but is there a standard way of extending the
text format of zone files to recognize new RRs without recompiling
the server? and is there a standard way to distribute machine-
readable definitions of new RR types?
rfc3597
No. It just means that the people spreading FUD have succeeded.
RFC 3597 (2003) formalised the handling of unknown RR types
and classes. The first draft was written in 2000 and it
described treating unknown RR's as opaque data blobs.
RFC 2535 (1999) (DNSSEC)
36 matches
Mail list logo
