> From: Douglas Otis [mailto:[EMAIL PROTECTED]
> 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
