From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
On Mon, 2006-07-24 at 22:27 -0700, Patrick Peterson wrote:
http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
I think this is a great idea and am surprised it didn't
generate more
traffic on the list. It's not easy to cram needed new functionality
into a backward-compatible solution.
This concept requires a wildcard PTR record at every label.
You need a record of some sort REGARDLESS of whether you use my mechanism or
define a new RR.
The records can be generated automatically. Nobody is going to be editing their
zone file directly in the DNSSEC era. We might as well get into the habit now.
The semantics are identical for this as for MX. Which again is a good thing.
Consistency is good.
This assumes there are no other PTR record used beyond
reverse lookups, which may not be the case.
As I have said, I would accept definition of a new record for the pointer if it
is clear that this is the case. So far nobody has given me a case where it is
an issue.
Name errors
would not be reported, which might make other searches
difficult and perhaps risk flooding caches with PTR RRs.
Again, there would be no difference here
This will also require special treatments at delegation points.
They work fine. As several people have pointed out you don't want a wildcard to
blow through a delegation.
The intent was to point to a general label where policy
references are found. Philip suggested this should point to
an HTTP server. HTTP is needed to support the size of an all
encompassing policy response.
No I did not make that suggestion.
What I did say is that we should not look to put more that the bare essentials
into the DNS system, that is the data that a client is going to use to make a
choice between services and to configure the security context to connect to a
service. If there is a need to go beyond that we can link out to HTTP but that
is not necessary for DKIM
If the PTR record can not be overlaid, then a new RR type is needed.
Defining a new RR type allows this RR type to be wildcarded
at every label and contain the policy information specific
for a particular protocol. No multi-record lookup or HTTP
would then be required. : )
No you do not understand the problem.
Defining a new RR only solves one half of the problems of wildcards, the poor
interaction with prefixes. You still have the problem that the semantics don't
work the way that you would want and you have to populate the zone with macro
wildcards. The difference with my scheme is that you only need to do it once
for all protocols.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html