Subject: Re: [domainrep] A sentence that confuses me

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Aug 2011 23:04:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Monday, July 25, 2011 7:46 AM
> To: [email-masked]
> Subject: [domainrep] A sentence that confuses me
> 
> In draft-kucherawy-reputation-query-dns-00, we have this:
> 
>    In line with [DNS-EXPAND], the TXT resource record type is used for
>    this application.
> 
> But RFC 5507 says this:
> 
>    We'll show how such a designer almost inevitably hits upon the idea
>    of just using a TXT Resource Record, why this is a bad thing, and why
>    a new Resource Record Type should be allocated instead.
> 
> How can these statements be reconciled?

My tendency toward using TXT is from the last several years of email authentication work, where variously the SPF, Sender-ID, DomainKeys and DKIM protocols and their various adjuncts all used TXT records to publish either keys or policies.  It's thus primarily there out of habit and not out of the idea that we have it right and the IAB got it wrong; I'd be fine with creating a new RR type if that's the current wisdom, apart from the fact that it will take some period of time for servers and resolvers both to begin supporting it.

This also presupposes that we get some buy-in from the community for putting this data in the DNS rather than creating a new UDP-based protocol.  I've heard arguments from both sides of that fence.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 2 Aug 2011 09:28:30 -0400

On Tuesday, August 02, 2011 02:04:01 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Andrew Sullivan Sent: Monday, July 25, 2011 7:46 AM
> > To: [email-masked]
> My tendency toward using TXT is from the last several years of email
> authentication work, where variously the SPF, Sender-ID, DomainKeys and
> DKIM protocols and their various adjuncts all used TXT records to publish
> either keys or policies.  It's thus primarily there out of habit and not
> out of the idea that we have it right and the IAB got it wrong; I'd be
> fine with creating a new RR type if that's the current wisdom, apart from
> the fact that it will take some period of time for servers and resolvers
> both to begin supporting it.
> 
> This also presupposes that we get some buy-in from the community for
> putting this data in the DNS rather than creating a new UDP-based
> protocol.  I've heard arguments from both sides of that fence.

For SPF we got a new RR type (99) assigned because the DNS gurus of the day 
insisted it was essential.  Despite being widely supported for many years in 
the relevant software and tools it has essentially zero deployment.  This is 
because there is zero incentive to move from TXT to the dedicated RR.

The choices were then (and as far as I know are now) either use TXT or put 
deployment into a several year wait state while DNS is upgraded everywhere.  I 
don't see any technical point in pretending to use a new RR with TXT as a 
'temporary' measure.  The politics of the matter may prove to be different.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 10:14:33 -0400

> 'temporary' measure.  The politics of the matter may prove to be different.

You do not need to upgrade DNS anywhere to support an unknown RRTYPE.
How to handle unknown RRTYPEs in the DNS was standardized in 2003.
Frankly, if you are using a DNS system that hasn't been upgraded since
that era, you gots bigger problems than being able to handle something
other than TXT.

What is probably true is that the support tools need to be upgraded.
I gather that there remain some client libraries that cannot handle
unknown RRTYPEs, but I don't have a complete list or an understanding
of how much pain they cause.  Someone once suggested to me, in
seriousness, that the gating library was VBA; if that's true, someone
might want to explain to me how that could be a gating factor on an
Internet protocol.  Certainly my interlocutor at the time did not, but
I was pretty sure he was confused.  (Maybe he meant "VB"?)
Suggestions for a list of such libraries would help.

Remember that one of the biggest problems with TXT is the ease with
which you can collide with others.  Since there is no registry for how
to handle the right hand side of a TXT record (and by definition,
there cannot be), you are simply having to trust that nobody else will
specify a format for the TXT record that is like enough to yours so as
to cause your special-handling TXT records to become broken.  The more
people try to put a protocol inside TXT records, the more likely this
eventuality becomes.  Moreover, this needs to be part of your security
considerations, particularly in a case like reputation where there
will always be an incentive to try to cause the reputation system to
break.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 2 Aug 2011 10:44:25 -0400

On Tuesday, August 02, 2011 10:14:33 AM Andrew Sullivan wrote:
> > For SPF we got a new RR type (99) assigned because the DNS gurus of the
> > day insisted it was essential.  Despite being widely supported for many
> > years in the relevant software and tools it has essentially zero
> > deployment.  This is because there is zero incentive to move from TXT to
> > the dedicated RR.
> > 
> > The choices were then (and as far as I know are now) either use TXT or
> > put deployment into a several year wait state while DNS is upgraded
> > everywhere.  I don't see any technical point in pretending to use a new
> > RR with TXT as a 'temporary' measure.  The politics of the matter may
> > prove to be different.
> 

In 2006, when we were looking into this for SPF, there was a large vendor in 
the northwest of the USA that had a DNS product that would handle unknown RRs 
when they were loaded, but they had to be reloaded after every reboot as the 
configuration wasn't retained.  Not being a user of this vendor's products, 
I've no idea if this is still the case. 

I agree with your other points.  The measures used by DKIM/ADSP are a 
reasonable response to those limitations of TXT.

Scott K

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 07:57:26 -0700

+1. There was a good argument five years ago to use TXT records for unstructured responses. There are only weak arguments now for using them for structured responses in completely new protocols.

--Paul Hoffman

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Aug 2011 08:06:14 -0700

> You do not need to upgrade DNS anywhere to support an unknown RRTYPE.

That's been the claim for the last 15 years.  It continues to be false, in 
practical terms.

New RRs will be zero systems cost when the there is broad, end-to-end support, 
from client resolvers, through recursive servers, to authoritative servers, for 
new RRs, requiring nothing more the administrative effort of specifying the new 
record.

That reality does not yet exist.  What exists is partial support.

In any event, the use of underscore-based subdomain naming renders the primary 
argument against TXT moot.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 15:33:39 -0000

>That's been the claim for the last 15 years.  It continues to be false, in 

Quite true.  Even if DNS servers and caches all support arbitrary RRs,
which may or may not be the case, there's vast amounts of provisioning
software that doesn't support new RRs at all, or only as long strings
of hex digits.

Really, we understand why it would have been nice if it were easy to
add and use new RRs.  But it's not.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 08:53:03 -0700

We had this discussion five years ago, but it is probably worth having it again now.

On Aug 2, 2011, at 8:33 AM, John Levine wrote:

> Even if DNS servers and caches all support arbitrary RRs,

Is there any evidence that any existing caches don't support arbitrary RRtypes?

> software that doesn't support new RRs at all, or only as long strings

Is that provisioning software used by anyone wanting to publish reputation data?

> add and use new RRs.  But it's not.

Who is "we" here? Some of "us" believe that things change over time. In specific, some of "us" believe that *for this specific proposal*, if someone publishing reputation data has a server that cannot be configured to accept the data, there is a strong incentive to get a server that does. 

--Paul Hoffman

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 2 Aug 2011 12:08:45 -0400

On Tue, 2 Aug 2011 08:53:03 -0700
Paul Hoffman <[email-masked]> wrote:

> Who is "we" here? Some of "us" believe that things change over time.

Yes, but some changes are better than others.  I think this change:

_repute.example.org  1h  IN  TXT "reputation-data-goes-here"

is better than:

exmple.org  1h  IN  REPUTE  "reputation-data-goes-here"

because it's less disruptive and equally good at avoiding clashes.

I think multiplying RRs that are really TXT records is a bad idea.
Multiplying domain prefixes like _repute is essentially free and
virtually 100% guaranteed to work with all existing implementations.

The only advantage to a specific RR is that the name server can, in
theory, check its syntax and reject malformed records.  But this
obviously will require a software upgrade and may not be worthwhile
since REPUTE records will probably not be human-generated.

Regards,

David.

---

From: "John R. Levine" <[email-masked]>
Date: 2 Aug 2011 12:13:45 -0400

> Is there any evidence that any existing caches don't support arbitrary 

Caches are one of the few places that are reliably OK with arbitrary 
records.

There are reasonably popular DNS servers like powerdns where the DNS data 
is stored in a database, and the server only supports specific record 
types. See http://doc.powerdns.com/types.html

This isn't abandonware; it's reasonably well supported and handles DNSSEC. 
It's open source so you can hack in support for whatever you want, but 
it's a lot more work than just adding a few records to a database.

There's also the question of what level of support there is in systems 
like .NET.  That's not my favorite development environment, but there sure 
are a lot of people who use it.

Or look at PHP, again, not my favorite language, but hugely popular for 
web applications.  The lowest level DNS lookup function dns_get_record() 
has a list of known RR types, again, possible to update since it's open 
source, but not trivial.

http://www.php.net/manual/en/function.dns-get-record.php

>> there's vast amounts of provisioning software that doesn't support new 
>> RRs at all, or only as long strings of hex digits.

> Is that provisioning software used by anyone wanting to publish 

Beats me.  It is my strong impression that it's the way that the vast 
majority of domains have their DNS provisioned today, so if we claim it 
doesn't matter, we're saying whatever we design is only for a narrow range 
of specialists.  Scott K. can probably tell you how painful it was to get 
it all to support TXT records so people could publish SPF.  We in the DKIM 
community were lucky that the SPFers already had those arrows in their 
backs.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 09:48:52 -0700

> Sent: Tuesday, August 02, 2011 7:15 AM
> To: [email-masked]
> Subject: [domainrep] More on TXT records (was: A sentence that confuses me)
> 

I don't know of any limitation on the client side, having written lots of client code by now.  What I don't know about is the server side, having written no server code at all.  How, for example, does one express binary data in a BIND zone file?

(There may be a way, but I've never seen it.)

For this to be painless and usable out-of-the-box, both have to be possible and relatively easy.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 13:36:48 -0400

On Tue, Aug 02, 2011 at 08:06:14AM -0700, Dave CROCKER wrote:

> New RRs will be zero systems cost when the there is broad,
> end-to-end support, from client resolvers, through recursive
> servers, to authoritative servers, for new RRs, requiring nothing
> more the administrative effort of specifying the new record.

So instead of addressing the distinction I was making in the mail I
sent, which exactly acknowledged your point and asked for help in
identifying the points of pain, you found it easier to point and
laugh?  Thanks.

> In any event, the use of underscore-based subdomain naming renders
> the primary argument against TXT moot.

Given that we can't even get people to agree on how underscores are to
be used (there's no registry, and there are two quite different use
patterns and no reason to suppose there won't be another one
tomorrow), I find it mighty hard to believe that the underscore
"convention" is a big improvement.  It's a one-at-a-time answer too.
It just moves the pain around.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 10:45:18 -0700

> Sent: Tuesday, August 02, 2011 10:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [domainrep] More on TXT records
> 

I did see an effort to create such a registry.  I don't know what happened to it though.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 14:50:11 -0400

On Tue, Aug 02, 2011 at 12:13:45PM -0400, John R. Levine wrote:

> There are reasonably popular DNS servers like powerdns where the DNS
> data is stored in a database, and the server only supports specific
> record types. See http://doc.powerdns.com/types.html

This is an excellent example, actually, and a good point.  PowerDNS is
very widely used in the domain hosting environment (particularly, I
understand, in Germany), so it might be a target of the repute work.

> This isn't abandonware; it's reasonably well supported and handles

On the other hand, the primary author resisted DNSSEC all the way,
until there were people lined up to add the support.  Then he did it.
I suspect demand actually causes a response in that product, but it's
not clear whether the cost would be worth it in this case.

> There's also the question of what level of support there is in
> systems like .NET.  That's not my favorite development environment,
> but there sure are a lot of people who use it.

This was what I was asking about.  Does .NET still not have that
support?  I thought I'd heard it did, but I don't know.

> Or look at PHP, again, not my favorite language, but hugely popular
> for web applications.  The lowest level DNS lookup function
> dns_get_record() has a list of known RR types, again, possible to
> update since it's open source, but not trivial.

This is another good example.  On the other hand, perhaps adding
support for unknown RRTYPEs would be a better thing to push for,
instead of asking everyone in the world to add yet another bunch of
special case handling for TXT records.

> Beats me.  It is my strong impression that it's the way that the
> vast majority of domains have their DNS provisioned today, so if we
> claim it doesn't matter, we're saying whatever we design is only for
> a narrow range of specialists.  Scott K. can probably tell you how
> painful it was to get it all to support TXT records so people could
> publish SPF.  We in the DKIM community were lucky that the SPFers
> already had those arrows in their backs.

It's a bitter result that the effort was all to get people to add
support for TXT records, which on their own don't actually solve the
problem.  This is not to denigrate the effort; it's just to note that
we seem to have fought a battle for the wrong ground.

To extend that military analogy, I'm not willing to die on this hill.
If people really want to proceed with TXT records, they are free to do
so given the well-established precedents.  This seems to me, for the
reasons I have outlined, to be a bad idea, but lots of people think my
advice is wrong.  However, I don't think the document undertaking to
define this TXT record ought to cite something that says, "Don't use
TXT records," as a reason why it is using a TXT record.  That was the
basis of my original question.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 15:03:31 -0400

> I did see an effort to create such a registry.  I don't know what

There's been more than one such effort.  The current one seems to be
struggling from want of review.

But even if we created a registry, there is no reason to suppose
people won't use those names in ways we don't like.  It is entirely
outside of the traditions of DNS administration to try to constrain
what domain name labels people use in their zones.  A registry
effectively tries to say, "Here are special purpose labels in the
DNS," and the problem is that, having delegated the namespace to
someone else, we're not going to be in a position to tell them what
they're allowed to do in their zones.  People could do anything the
like with those names.  That's a feature of DNS.  If you want rules
about whether the right hand side of the returned data is valid, you
need an RRTYPE to enforce it. 

Now, one might say, "If you want to use this feature, you can't use
that name for something else."  I would agree.  But that doesn't mean
that the underscore label somehow makes the name safe.  All the client
software for repute (or any other TXT-using protocol) needs to be able
to handle examples where the return data format doesn't conform to the
standard, which means that instead of relying on your DNS library to
do proper type checking, your application has to do it.  Not the end
of the world, but given my experience of in-application type checking
(in the database application support world I sometimes live in), I
can't say I am sanguine about robust interoperability over the long
haul.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 2 Aug 2011 15:19:43 -0400

On Tue, 2 Aug 2011 15:03:31 -0400
Andrew Sullivan <[email-masked]> wrote:

> [...] which means that instead of relying on your DNS library to
> do proper type checking, your application has to do it.

But one of the strongest arguments for a new RR is that you can
introduce it without any changes to DNS or resolver software.  If you
want your DNS library to do type-checking, that argument fails.

I'm not saying a new RR is necessarily a bad thing, but it's not as
easy to Just Implement as some people are saying.

Regards,

David.

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 19:32:54 -0000

>want your DNS library to do type-checking, that argument fails.

On my list of Things to Do When I Get Back from the Jersey Shore* is a
sketch of a DNS extension language so a computer could have a single
list of extended DNS type definitions like it has a list of ports or
of MIME types.  Then DNS software could look at that to support new
types, and you could add a new type by adding a line to the list.  You
couldn't do everything with it, e.g., I wouldn't try to do NSEC3 that
way, but for the kind of stuff we're talking about that's a list of
numbers, strings, names, and maybe bitmasks, it shouldn't be too hard.

R's,
John

* - no, not that part, the much quieter next island south. Oy.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 12:42:57 -0700

> numbers, strings, names, and maybe bitmasks, it shouldn't be too hard.

And I will offer to assist. I believe that I have probably not succeeded in getting folks here to consider something other than TXT, but such a tool would prevent this argument from happening five years from now.

--Paul Hoffman

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 2 Aug 2011 15:49:46 -0400

On 2 Aug 2011 19:32:54 -0000
"John Levine" <[email-masked]> wrote:

> of MIME types.

Ah, so we will reinvent ASN.1 :)  Actually, ASN.1 with PER might not be
too bad.

Regards,

David.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 16:06:19 -0400

> want your DNS library to do type-checking, that argument fails.

That's not actually my argument.  Unknown RRTYPE support is useful
because _everyone else_ isn't a gating factor on your using the new
RRTYPE.  I think that it would be foolish to use an unknown RRTYPE
directly in the application.  The library that is talking directly to
the DNS probably does want to know about the RRTYPE.

Now, in early deployment that might be a special-purpose resolver
library that you ship with the application to ensure it has support
for the RRTYPE; at installation time, you check the system library to
see whether it has the support you need and if not use your
special-purpose one (and hope that this withers on the vine
eventually).

> easy to Just Implement as some people are saying.

I for one was not trying to suggest that.  I was instead trying to
suggest that it's not a simple no-brainer decision.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Aug 2011 13:39:53 -0700

Andrew,

> identifying the points of pain, you found it easier to point and

Please feel entirely assured that there is no laughter anywhere in the room. 
Tears, perhaps, but no laughter.  There is nothing funny about years of having 
the core DNS community assert the demand that new RRs be used, but put no effort 
into making sure they are end-to-end viable.  That assurance should be the 
responsibility of the folks controlling the DNS, not of folks trying to use it.

As for addressing the distinction you made, please forgive my having jumped into 
the middle of things.   I thought that my text was rather straightforward at 
implying new RRs are not currently viable, or at least, not easily viable.  That 
was meant to address the distinction quite fundamentally.

> It just moves the pain around.

I suspect you are aware that I've been pressing rather forcefully to get the 
DNSEXT wg to consider the revised registry specification that I put forward at 
the end of March and have not even gotten an acknowledgement, nevermind discussion.

This probably does not qualify as "can't even get people to agree" because that 
would imply conversation and there hasn't been any.

At this point, I'm trying to discover an alternative path.  Suggestions and 
assistance are eagerly sought...

As for 'two different use patterns', that worthy of a separate thread and you've 
got my interest.

On 8/2/2011 11:50 AM, Andrew Sullivan wrote:
 >   This seems to me, for the

TXT with underscore is ugly, but is quite workable.  It scale just fine.

 > basis of my original question.

Indeed it would be reasonable for the draft to note the problematic nature of 
the recommendation in the IAB paper...

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 14:01:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Tuesday, August 02, 2011 12:43 PM
> To: [email-masked]
> And I will offer to assist. I believe that I have probably not
> succeeded in getting folks here to consider something other than TXT,
> but such a tool would prevent this argument from happening five years
> from now.

I'm comfortable with either approach, really.  They each have their own ups and downs.  Though I think TXT is the path of least resistance, it also is not problem-free.

<shields up>
What about doing both, and letting the less-implemented one die?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 17:08:02 -0400

On Tue, Aug 02, 2011 at 01:39:53PM -0700, Dave CROCKER wrote:

> As for addressing the distinction you made, please forgive my having
> jumped into the middle of things.   I thought that my text was
> rather straightforward at implying new RRs are not currently viable,
> or at least, not easily viable.  That was meant to address the
> distinction quite fundamentally.

Nonsense.  We had two problems in the DNS with new RRTYPEs.  One was
that the intermediate software all puked.  The other was that we have
support software that doesn't co-operate.  I was arguing that the
intermediate software mostly didn't do that any more, and
acknowledging that there is a problem with other software.  I was then
asking for help in identifying where those problems are.  To stamp
your foot and say, "DNS weenies are saying this over and over again,"
doesn't help.  

> I suspect you are aware that I've been pressing rather forcefully to
> get the DNSEXT wg to consider the revised registry specification

ITYM DNSOP.  If it were DNSEXT, I'd be aware of it, and I'd tell you
you need to take it to DNSOP because there's no protocol change.

> This probably does not qualify as "can't even get people to agree"
> because that would imply conversation and there hasn't been any.

Well, there was some.  For instance, you presented a previous draft at
a previous IETF meeting and did, ISTR, get some feedback from some guy
I used to know.  But it's true it would be nice to get more traction.

But the other point I was trying to make -- that putting this in a
registry still doesn't make this clean because it implies a
restriction inside a name space that, formally, we don't control -- is
still a problem.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 02 Aug 2011 23:37:16 +0200

> restriction inside a name space that, formally, we don't control -- is

OK, folks. Can we first concentrate on the outline of all the work to be 
done and later on get into the details? Things that need our attention:

- charter
- who will work on what document(s)
- milestones
- how to discuss the various documents without getting a cacophony of 
voices, interfering opinions on 'n' topics etc.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 14:41:25 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Tuesday, August 02, 2011 2:37 PM
> To: Andrew Sullivan
> Cc: [email-masked]

Already out for review.  Comments, please.

> - who will work on what document(s)

Nathaniel has said he'd like to keep the framework ("model") document.

I'll volunteer to take the email vocabulary one ("vocab-identity").  I think the other current vocabulary one ("vocab-email") should get a different author, or should be allowed to die.

I'd also like to take a crack at the DNS or UDP one, whichever one we decide to keep.

That leaves the HTTP query one and the media type registration looking for new owners, plus any others we decide we need.  Any takers?

I suspect David Skoll is in for resurrecting the one he had about how reputation systems can receive feedback from data providers.  He should confirm that.

And I'm up for reviewing and commenting on all of them.  And I'll be doing at least one of the implementations (an open source one) with my employer doing a commercial one.

I have sent to the ADs already a list of about 20 people that volunteered, either on the list, in the jabber room during the BoF, in the BoF or personally afterwards, to review and comment on documents and/or implement.

> voices, interfering opinions on 'n' topics etc.

That's for the co-chairs to do, whoever the ADs pick to do that.  I think that I need to step aside from that selection pool as I'm too immersed in the work to also be co-chairing.

If anyone's keen to co-chair that hasn't already said so, let me know.  I've submitted a few names to the ADs already.

-MSK

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 2 Aug 2011 18:21:41 -0400

On Tue, 2 Aug 2011 14:41:25 -0700
"Murray S. Kucherawy" <[email-masked]> wrote:

> I suspect David Skoll is in for resurrecting the one he had about how
> reputation systems can receive feedback from data providers.  He
> should confirm that.

Yes, confirmed.

Regards,

David.

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 22:54:25 -0000

>What about doing both, and letting the less-implemented one die?

Sure, but at this point it's functionally equivalent to just doing
text.

Ask SPF users how often they query for type 99 RR's.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 22:55:04 -0000

>Ah, so we will reinvent ASN.1 :)  Actually, ASN.1 with PER might not be

Ewww.  I was planning to stop at about 2% of the complexity of ASN.1.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 03 Aug 2011 17:21:56 +0200

> Sure, but at this point it's functionally equivalent to just doing

But with worse performance, see below.

> Ask SPF users how often they query for type 99 RR's.

At the risk of answering a rhetorical question, a compliant checker
has to _always_ query the SPF RR, since that would take precedence
over any TXT one.  I'd be curious how a revised SPF could remove this
particular arrow from its back...

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 3 Aug 2011 12:23:24 -0400

On Wednesday, August 03, 2011 11:21:56 AM Alessandro Vesely wrote:
> has to always query the SPF RR, since that would take precedence

No.  It doesn't.  RFC 4408 para 4.4 says:

"In accordance with how the records are published (see Section 3.1 above), a 
DNS query needs to be made for the <domain> name, querying for either RR type 
TXT, SPF, or both. If both SPF and TXT RRs are looked up, the queries MAY be 
done in parallel."

Operators are perfectly free to waste resources querying for Type SPF or not.  
If you get both back, then the Type SPF takes precident, but there's not 
requirement to look for it.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 09 Aug 2011 15:45:31 -0700

> your foot and say, "DNS weenies are saying this over and over again,"
Why balk at defining plugins that support the typical provider's user 
consoles?
> you need to take it to DNSOP because there's no protocol change.\
Agreed.  It is not accurate to describe the issue as representing a 
protocol limitation.
> I used to know.  But it's true it would be nice to get more traction.
Far greater attention must be paid to network amplification from 
recipient UDP requests that are chained to obtain HTTP pages worth of 
information.  At least HTTP runs over TCP.   Is such a resulting DDoS of 
innocent bystanders a DNS protocol issue or would this be due to using 
the wrong protocol?
> restriction inside a name space that, formally, we don't control -- is
Well said.

-Doug