Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

On Apr 18, 2007, at 5:09 PM, Daryl C. W. O'Shea wrote: Mark Delany wrote: John L wrote: You are certainly correct that most zones are pretty flat, but this sounds like a DOS attack waiting to happen, send out junk with long bogus addresses I'm just raising this as a discussion point; what

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

Mark Delany wrote: John L wrote: percentages are "normal" vs. "unusual", but my cursory look a long time ago suggested that it met the 80-20 rule. You are certainly correct that most zones are pretty flat, but this sounds like a DOS attack waiting to happen, send out junk with long bogus addre

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

John L wrote: percentages are "normal" vs. "unusual", but my cursory look a long time ago suggested that it met the 80-20 rule. You are certainly correct that most zones are pretty flat, but this sounds like a DOS attack waiting to happen, send out junk with long bogus addresses I'm just rais

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

percentages are "normal" vs. "unusual", but my cursory look a long time ago suggested that it met the 80-20 rule. You are certainly correct that most zones are pretty flat, but this sounds like a DOS attack waiting to happen, send out junk with long bogus addresses and watch the system on the ot

Re: [ietf-dkim] Re: New Issue: Use of XPTR records in SSP

On Apr 18, 2007, at 12:00 PM, Scott Kitterman wrote: On Wednesday 18 April 2007 14:51, Douglas Otis wrote: Rejection at the MTA offers an allusion of protection. Protection through rejection alone remains prone to look-alike and cousin domain exploits, growing ever more problematic with t

Re: [ietf-dkim] Re: New Issue: Use of XPTR records in SSP

On Wednesday 18 April 2007 14:51, Douglas Otis wrote: > Rejection at the MTA offers an allusion of protection. Protection > through rejection alone remains prone to look-alike and cousin domain > exploits, growing ever more problematic with the introduction of > Internationalizations. Dependence

Re: [ietf-dkim] Re: New Issue: Use of XPTR records in SSP

On Apr 18, 2007, at 11:08 AM, Frank Ellermann wrote: Really, I can't judge it. Whatever the folks here decide, please check it with some "namedroppers" before we waste months revisiting ratholes. Aside from a few issues remaining with DNSSEC, such as DLV, little seems to show up on the

[ietf-dkim] Re: New Issue: Use of XPTR records in SSP

Jim Fenton wrote: > Phill should probably be the one to comment directly on the reason for > the new XPTR record type, but I'm under the impression that he's trying > to avoid conflict with existing uses of PTR. I, at least, had not > considered use of NAPTR here; can you outline how it might wor

[ietf-dkim] Re: New issue: Upward query vs. wildcard publication

Eliot Lear wrote: > I prefer Option 3.5: > Publish a record at the zone level. For SPF that option was rejected by Paul Vixie: After that discussion the "zone cut" idea published in some SPF drafts was removed again, a

Re: [ietf-dkim] New Issue: Use of XPTR records in SSP

On Apr 17, 2007, at 8:35 PM, Jim Fenton wrote: Douglas Otis wrote: This assumes a simple authorization scheme is not effective at protecting a principal domain. For example, if the industry creates a list of domains used for the purpose of registries, then this would identify precisely

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

Dave Crocker wrote: Given that zones are administrative constructs for use by operators, and are not intended to be visible to client DNS activities -- and well might not be visible, no matter the intent -- then how does the upward tree-walk know when to stop? In the general case, it doesn't.

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

Given that zones are administrative constructs for use by operators, and are not intended to be visible to client DNS activities -- and well might not be visible, no matter the intent -- then how does the upward tree-walk know when to stop? In the general case, it doesn't. However, it's possib

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

Dave Crocker wrote: Eliot Lear wrote: Publish a record at the zone level. If no other record exists, use that. If that record doesn't exist, stop. This is a cheap form of wildcarding. it requires at most two queries, which while unpleasant for some purists avoids people having to deal wi

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

The resolver would have to construct the query non-recursively. I agree that this is a problem. Dave Crocker wrote: Eliot Lear wrote: Publish a record at the zone level. If no other record exists, use that. If that record doesn't exist, stop. This is a cheap form of wildcarding. it req

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

Eliot Lear wrote: Publish a record at the zone level. If no other record exists, use that. If that record doesn't exist, stop. This is a cheap form of wildcarding. it requires at most two queries, which while unpleasant for some purists avoids people having to deal with wildcards, which

Re: [ietf-dkim] Re: New issue: Upward query vs. wildcard publication

Jim Fenton wrote: I don't remember offhand how CSV did this. From the specification at : If a domain administrator declares an assertion about all names within a domain, the appropriate bit MUST be set in the Port field of the CSV-CSA record at the root of the doma

Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

On Tue, 17 Apr 2007 01:59:23 +0100, Jim Fenton <[EMAIL PROTECTED]> wrote: Option 3: As presented at IETF 68, upward queries would be performed if a NODATA response is required until the verifier gets to a TLD (or something that acts like one). Discussion: Option 3 is simplest for the publisher