Subject: [dnsext] Moving policy data away from DNS

From: Jay Daley <[email-masked]>
Date: Thu, 23 Dec 2010 11:51:54 +1300

Forgive me if this has been discussed before, I find it hard to keep up enough with this list to be sure that it hasn't ...

More and more people are looking to publish information in DNS that is intended to signal a set of instructions to a third party to control their actions.  This might include:

1. what configuration the third party should hold with respect to the publishing domain
2. the nature of service that the publishing domain regards as acceptable for a third party to provide  (e.g. the recent CAA proposal)
3. what the connection acceptance policy of a host found at the publishing domain will be.  (e.g. DKIM discussions)
4. information on the publishing host that can be used by another host when deciding whether or not to accept a connection from it (or was this the DKIM discussion?).

There are a number of problems with storing policy in the DNS

- we could end up with many (pick a number) records of a particular type at any domain and as we all know DNS does not provide a sub-selector to aid with that.
- there is no boundary definition on what is appropriate for the DNS and what is not
- this will eat up RR codes quickly
- it changes the nature of the way DNS is used, in particular it undermines the comfortable acceptance of loose synchronisation and pushes DNS more towards a traditional database
- the careful process for getting new RRs assigned leads many to use TXT records as a quick way out and that is now becoming overloaded and increasingly misused.

So I would propose that we have a mechanism for pushing this policy away from DNS but using the DNS to point to the location.

One complication though is that a distinction needs to be made between this policy information and information that describes the structure of a part of the DNS tree.  Examples of the latter include:

- Constraints on the format of domains found at the next level (for example a declaration by a TLD on what characters it supports at the next level in IDN domains)
- A statement of the expected depth of a series of labels (for example the number of digits in a specific section of the ENUM tree).

One way to do this is to define a service policy record that can be used to publish the location of a policy protocol server where the policy for a domain can be published.  This record would use the same form as the SRV record with the LHS specifying the service and the RHS the location.  Examples:

	_tls._tcp.www.example.com.     POL     my-tls-policy-server.example.com
	_sip._tcp.7.7.9.6.1.3.9.4.6.e164.arpa.     POL     my-sip-policy-server.example.com

The definition of policy would be anything that meets the four numbered criteria above, excluding information that specifically describes the structure of the tree.

Obviously there is no such thing as a policy protocol yet so someone has to define one or define one per LHS protocol.  But at least this way we point people to the real problem that needs to be solved and away from DNS.

Any thoughts?
Jay

PS I don't think this undermines keyassure as that is not policy - if it is extended to add details on what certificates might be used then it does become policy.

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 15:25:28 -0800

>- we could end up with many (pick a number) records of a particular type at any domain and as we all know DNS does not provide a sub-selector to aid with that.

Can you say more why this is a problem for the records you are talking about but not the ones we already have?

>- there is no boundary definition on what is appropriate for the DNS and what is not

There is: it's called IETF consensus. So far, IETF consensus has been that the DNS is an (the?) appropriate place to put information that relates to a domain.

>- this will eat up RR codes quickly

Where is the evidence for "quickly"? I certainly don't see it looking at the RRTypes registry in <http://www.iana.org/assignments/dns-parameters>

>- it changes the nature of the way DNS is used, in particular it undermines the comfortable acceptance of loose synchronisation and pushes DNS more towards a traditional database

That seems completely wrong. The records I have seen discussed lately in fact (after a rev or two to get terminology right) do look like they use the same data model we use for the long-established RRtypes. Can you give examples where that is not the case?

>- the careful process for getting new RRs assigned leads many to use TXT records as a quick way out and that is now becoming overloaded and increasingly misused.

...which argues directly against your proposal for making it harder for proposals to use the RRType mechanism for things that relate to domains.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Dec 2010 16:12:26 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
> Sent: Wednesday, December 22, 2010 2:52 PM
> To: DNSEXT Working Group
> Subject: [dnsext] Moving policy data away from DNS
> 
> More and more people are looking to publish information in DNS that is
> intended to signal a set of instructions to a third party to control
> their actions.  This might include:
> [...]
> 3. what the connection acceptance policy of a host found at the
> publishing domain will be.  (e.g. DKIM discussions)
> 4. information on the publishing host that can be used by another host
> when deciding whether or not to accept a connection from it (or was
> this the DKIM discussion?).

DKIM isn't really interested in either of these.  You might be thinking of SPF.

> - we could end up with many (pick a number) records of a particular
> type at any domain and as we all know DNS does not provide a sub-
> selector to aid with that.

The "_name" mechanism introduced by things like ADSP, DKIM and VBR seem to be dealing with this problem just fine so far.

I do concur with the observation that getting new RR types is non-trivial, but that by itself is less of a problem than the fact that a new type then has to be integrated into a nameserver release from various vendors.  That reality is outside of the influence of the IETF.  Those two things together are why people gravitate towards TXT records.

But coupled with underscore-name tagging that has come to be in popular use, this doesn't seem to be a big problem either.

---

From: Joe Abley <[email-masked]>
Date: Wed, 22 Dec 2010 19:14:33 -0500

On 2010-12-22, at 19:12, Murray S. Kucherawy wrote:

> I do concur with the observation that getting new RR types is non-trivial, but that by itself is less of a problem than the fact that a new type then has to be integrated into a nameserver release from various vendors.

Or those vendors could just implement RFC 3597.

Joe

---

From: Jay Daley <[email-masked]>
Date: Thu, 23 Dec 2010 14:25:00 +1300

> Can you say more why this is a problem for the records you are talking about but not the ones we already have?

I didn't say or imply that.  There are some existing ones that have the problem, NAPTR and TXT for example, but those horses have bolted.

> There is: it's called IETF consensus. So far, IETF consensus has been that the DNS is an (the?) appropriate place to put information that relates to a domain.

"relates to a domain" is about as wide as it gets and a boundary that wide isn't a practical boundary.  What we get instead is that when people discuss individual proposals they are forced to repeat a debate about wider principles.  This is an attempt to codify those principles and move on.

BTW Do I take it from this that you don't agree with what I've proposed? 

> Where is the evidence for "quickly"? I certainly don't see it looking at the RRTypes registry in <http://www.iana.org/assignments/dns-parameters>

I'm not going to do a quant analysis to justify this, but I certainly perceive the number of proposals to put policy in DNS increasing, particularly as people realise just how useful DNSSEC is.

> That seems completely wrong. The records I have seen discussed lately in fact (after a rev or two to get terminology right) do look like they use the same data model we use for the long-established…

Unless you mean something very different for 'data model' from what it means to me, we are talking about two very different things.  

> ...which argues directly against your proposal for making it harder for proposals to use the RRType mechanism for things that relate to domains.

Eh?  Are you seriously suggesting that because people misuse TXT in response to how hard it is to get a new RR, we should make it easier to get an RR to protect poor old TXT? 

I'm not sure you understood the implications of my last point there - if we provide a standard mechanism for pointing to policy elsewhere then it provides an alternative to the "stuff it into TXT as you'll never get an RR" way of thinking.

cheers
Jay

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 17:45:13 -0800

>I didn't say or imply that.  There are some existing ones that have the problem, NAPTR and TXT for example, but those horses have bolted.

OK. What then are the actual problems with not having sub-selectors in recent RRType proposals?

>"relates to a domain" is about as wide as it gets and a boundary that wide isn't a practical boundary.  What we get instead is that when people discuss individual proposals they are forced to repeat…

This seems like an attempt to force a new paradigm, not to codify the current principles. I'd be happy to help with (but not originate) an effort to codify the current principles, such as "RRTypes must relate to a domain" and "RRTypes must not affect domains other than the one named".

>BTW Do I take it from this that you don't agree with what I've proposed?

Correct.

>I'm not going to do a quant analysis to justify this, but I certainly perceive the number of proposals to put policy in DNS increasing, particularly as people realise just how useful DNSSEC is.

I am going to do that analysis from the URL I just gave: we have either 65000 or 150 RRTypes left (depending on who you talk to), and we are burning them at a rate of about 3 per year.

>Unless you mean something very different for 'data model' from what it means to me, we are talking about two very different things. 

Please say more about which RRType proposals you think "undermines the comfortable acceptance of loose synchronisation" or "pushes DNS more towards a traditional database". I just haven't seen these other than in a few abandoned -00 drafts.

>Eh?  Are you seriously suggesting that because people misuse TXT in response to how hard it is to get a new RR, we should make it easier to get an RR to protect poor old TXT?

No, I'm saying we have reached a good equilibrium of how people use both TXT and new RRTypes.

>I'm not sure you understood the implications of my last point there - if we provide a standard mechanism for pointing to policy elsewhere then it provides an alternative to the "stuff it into TXT as…

That's true, but it is also true to say if we encourage people to put domain-specific policy in new RRTypes, then it provides an alternative to the "stuff it into TXT as you'll never get an RR" way of thinking.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Dec 2010 13:02:15 +1100

In message <[email-masked]
>, "Murray S. Kucherawy" writes:
> The "_name" mechanism introduced by things like ADSP, DKIM and VBR seem to be d
> ealing with this problem just fine so far.
> 
> I do concur with the observation that getting new RR types is non-trivial, but 
> that by itself is less of a problem than the fact that a new type then has to b
> e integrated into a nameserver release from various vendors.  That reality is o
> utside of the influence of the IETF.  Those two things together are why people 
> gravitate towards TXT records.

Which isn't a issue with modern nameservers either as they can
store, load and serve the record as unknown records, i.e. a hex dup
of the rdata field.

I don't know about other vendors but named is designed to make the
introductions of new records easy.  It doesn't require a new release
to add a new type to named.  It just requires someone to publish a
set of methods to parse the records and a recompile.  We have had
users do this themselves for records they wanted to experiment with.
Many of the methods end up being the proforma methods and there is
lots of example code.

e.g. for HIP 
	fromtext_hip
	totext_hip
	fromwire_hip
	towire_hip		* proforma
	compare_hip  		* proforma
	fromstruct_hip
	tostruct_hip
	freestruct_hip
	additionaldata_hip  	* proforma
	digest_hip  		* proforma
	checkowner_hip  	* proforma
	checknames_hip  	* proforma
	casecompare_hip

TXT records have their own limitations especially when you exceed
what fits in a single string as DKIM records can.  You then end up
having to teach the users how to break breakup the TXT record so
that it can be properly parsed.

Mark

> But coupled with underscore-name tagging that has come to be in popular use, th
> is doesn't seem to be a big problem either.
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jay Daley <[email-masked]>
Date: Thu, 23 Dec 2010 15:45:42 +1300

> OK. What then are the actual problems with not having sub-selectors in recent RRType proposals?

What we've got emerging as a de facto standard is a combination of _name prefix and parameter values embedded in a long string.  While this is very clever I would argue that it is deeply sub-optimal because it is forcing what could be quite expressive and complex policy into a poor container, of which a one-dimensional _name prefix is a characteristic.

Say I wanted to state, for host X
- here is how hosts that conform to Y should connect to me
- here is how hosts that conform to Z should connect to me
- here is the default how hosts should connect to me
- here is how I intend to connect to hosts that conform to A
- and so on

then either we use lots of sub-selectors or a big string on the RHS or lots of RRs.

My point, in case it is not clear, is that putting that in DNS is a kludge that follows the path of least resistance for the IETF process rather than the path of what's the best technology to use here.

> Please say more about which RRType proposals you think "undermines the comfortable acceptance of loose synchronisation" or "pushes DNS more towards a traditional database". I just haven't seen thes…

Any RRs that put third party policy into DNS and so create a mutually inconsistent set of data unless all instances are synchronised.  

If I state in DNS that says "my key is ..." and two different answers are available during synchronisation, then that it is not inconsistent per se because I might have two keys.

If I state in DNS "I will only allow ..." and two different answers are available during synchronisation then that is inconsistent.

Jay

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 20:21:27 -0800

At 3:45 PM +1300 12/23/10, Jay Daley wrote:
>What we've got emerging as a de facto standard is a combination of _name prefix and parameter values embedded in a long string.

I'm confused. Is the proposal that started this thread:
a) to stop folks from making new "policy" RRTypes?
b) to stop folks creating new TXT record semantics?
c) both?

The reason I ask is that you said in the first message:
>- we could end up with many (pick a number) records of a particular type at any domain and as we all know DNS does not provide a sub-selector to aid with that.

To me, that sounds like (a), and I have been responding to that. Now it sounds like you're talking more about (b) or possibly (c). I find (a) and (b) to be completely different.

>  While this is very clever I would argue that it is deeply sub-optimal because it is forcing what could be quite expressive and complex policy into a poor container, of which a one-dimensional _name prefix is a characteristic.

Any RRtype is a one-dimensional characteristic.

>then either we use lots of sub-selectors or a big string on the RHS or lots of RRs.

What is the problem with "lots of RRs" that is so bad that this should be outside the DNS? We have this debate periodically on things more familiar, such as "give me both the IPv4 and IPv6 addresses together".

>My point, in case it is not clear, is that putting that in DNS is a kludge that follows the path of least resistance for the IETF process rather than the path of what's the best technology to use he…

We disagree here. I believe that data that relates to a domain actually belongs in the DNS.

>Any RRs that put third party policy into DNS and so create a mutually inconsistent set of data unless all instances are synchronised. 

We fully agree that that would be bad. Which specific RRType proposals are those?

>If I state in DNS that says "my key is ..." and two different answers are available during synchronisation, then that it is not inconsistent per se because I might have two keys.

That depends on the semantics of the RRType. I would say that the semantic is not "my key is" but "this key is mine". That eliminates your synch problem as well as a slew of related problems.

>If I state in DNS "I will only allow ..." and two different answers are available during synchronisation then that is inconsistent.

We fully agree there. Again, I don't think that is part of any fleshed-out proposal.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Dec 2010 00:51:14 -0500 (EST)

> I'm not sure you understood the implications of my last point there - if we provide a standard mechanism for pointing to policy elsewhere then it provides an alternative to the "stuff it into TXT a…

Your POL RRTYPE will have some structure that won't fit in someone and they will go stuff it into a TXT
record anyway.

One use I could see is a modification to TXT that allows it to come along as additional data, but instead
of using some ADDTXT RRTYPE for that, I'd rather see some nice structured ENDS method that can work for
more types (even if Miek kills a kitten every time :)

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 12:55:56 +0000

Well I am going to surprise everyone by pointing out that I appear to be in
agreement with Paul Hoffman here.

> > There is: it's called IETF consensus. So far, IETF consensus has been
> that the DNS is an (the?) appropriate place to put information that relates
> to a domain.
>
> "relates to a domain" is about as wide as it gets and a boundary that wide
> isn't a practical boundary.  What we get instead is that when people discuss
> individual proposals they are forced to repeat a debate about wider
> principles.  This is an attempt to codify those principles and move on.
>

I don't see an attempt to codify those principles. I see a demand that we
halt everything for an unspecified period of time while we go down a very
deep rat-hole.

The DNS is the Internet infrastructure for managing assertions that relate
to domain names. The problems arise when people make a assertions that
relate to a domain name and they are NOT using the DNS.

The DNS infrastructure is more than sufficient to meet this need.

> > Where is the evidence for "quickly"? I certainly don't see it looking at
> the RRTypes registry in <http://www.iana.org/assignments/dns-parameters>
>
> I'm not going to do a quant analysis to justify this, but I certainly
> perceive the number of proposals to put policy in DNS increasing,
> particularly as people realise just how useful DNSSEC is.

So you are going to make assertions but not bother to back them up with
actual facts or figures?

At the moment we have about 75 records allocated. There are proposals on the
table for a couple more. Since there is an expert review criteria I cannot
imagine how we could possibly get to as many as 20 records a year without
someone saying 'hey wait a minute, something is wrong'. At that rate it will
take 3,705 years to exhaust the RR code space.

>> - the careful process for getting new RRs assigned leads many to use TXT
> records as a quick way out and that is now becoming overloaded and
> increasingly misused.
> >
> > ...which argues directly against your proposal for making it harder for
> proposals to use the RRType mechanism for things that relate to domains.
>
> Eh?  Are you seriously suggesting that because people misuse TXT in
> response to how hard it is to get a new RR, we should make it easier to get
> an RR to protect poor old TXT?
>

Yes, because one of the main reasons for opening up the RR code registry in
the first place was the observation that if people are not given a feasible
path for getting a new RR code point assigned officially they will either
(1) use a TXT record or (2) ignore the official process and assign their own
RR code.

I'm not sure you understood the implications of my last point there - if we
> provide a standard mechanism for pointing to policy elsewhere then it
> provides an alternative to the "stuff it into TXT as you'll never get an RR"
> way of thinking.
>

Which was precisely the point of the new RR allocation process.

Since the policy statements I am proposing are considerably shorter than the
typical URI, I fail to see the point in using an external reference.

Moreover, since I am proposing security policy, and looking to use DNSSEC to
secure the security policy, any external reference would require a digest
specifier to prevent alteration. So the external reference would be in
addition to the information already there.

I can now pack all the policy and extended discovery information relevant to
a query in a single response.

The key here being the realization that we can pipeline signature
verification and connection establishment - but I will put that in a
separate post.

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Dec 2010 07:59:29 -0500

> So I would propose that we have a mechanism for pushing this policy away from DNS but using the DNS to point to the location.

I'm not actually convinced that you have the right audience on this
list.  But the audience I think _is_ right has not been interested in
proposals of this sort.

Over the past couple years, I made hand-wavy sketchy suggestions along
these lines more than once.  To my mind, the so-called "cookie
problem" and the public-suffix.org mess would be better handled by
authoritative (and DNSSEC verifiable) statements on the part of zone
operators about where their actual administrative boundaries lie.  A
number of issues with IDNA and knowing what character sets are
included in a zone operator's (or "registry" as we used to call it,
before that word was co-opted to mean "thing dealing with ICANN) IDNA
policies -- right now, AFAICT, the Mozilla answer to this has been to
code the policies into the browser.  And so on.

But every time I tried to drum up some interest (generally among
application devleopers) for such an effort, if only to persuade myself
to write the -00 draft, the reaction was, "Why do I care?  What I have
[which included underscore + TXT] works fine."

I therefore don't think that the people whose problem we might try to
solve with a DNS policy pointer believe they have a problem.
Nevertheless, if you want to have a whack at this, I'd be happy to
work on it with you.  I think the right forum is the Applcations Area
Working Group, however, since it's their problems we're trying to
solve.  This isn't really an extension of the DNS at all; instead,
it's an attempt to point out just how few extensions are needed :) 

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 23 Dec 2010 08:57:03 -0500

+1 that a zone policy pointer, with or without registry-thingee-ness 
tending towards icann policy and joy, is of some utility, and
+1 that it is an apps area activity, and
+1 that i am willing to contribute in the work to get to -00

-e

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 23 Dec 2010 14:20:34 +0000

On 23 Dec 2010, at 13:57, Eric Brunner-Williams wrote:
> +1 that a zone policy pointer, with or without registry-thingee-ness tending towards icann policy and joy, is of some utility, and

To which I reply:
Hi Eric, folks,
 Are you suggesting that "icann policy" and "joy" are two discrete items, or mutually exclusive?
More important ...
 are you really sure you want to engage in a dialogue with icann policy stakeholders?
(at least to find out what they want?)

all the best,
  Lawrence

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Dec 2010 09:54:42 -0500

> (at least to find out what they want?)

Given our notable lack of success in learning anything at all about
what the presumed policy stakeholders think about the "alias" issue, I
don't believe for a New York minute that we're going to be successfun
in engaging in dialogue.

But it doesn't matter.  If there's a mechanism with a pointer to a
repository that then has some way to express various policy things,
then anyone can express their policies in there.  If there are ICANN
policy stakeholders who then want to express such a policy, they can
either write the policy in keeping with whatever mechansism we come up
with or they can hire someone(s) from these parts to do that work for
them.

FWIW, what originally made me think along these lines was the
historical confluence of the IDNA2008 start up and the deployment of
publicsuffix.org.  The latter struck me -- and still does strike me --
as a miserable hack that is there to try to solve the problem of legal
boundaries around DNS administrative boundaries.  The IDNA2008 work
started from the premise that what was really wanted was localization
of DNS, only in a fully global context.  Both of these strike me as
obviously amenable to statements on the part of a zone operator (or
maybe multiple zone operators) that their policies follow certain sets
of rules.

Anyway, if people are really interested in this, I will endeavour to
put together a draft some time in the early months of 2011.  I won't
have time for sure until mid-Jan anyway, so if someone else wants to
go ahead & start writing, don't let me stop you!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Dec 2010 16:09:18 +0000

> Date: Thu, 23 Dec 2010 07:59:29 -0500
> From: Andrew Sullivan <[email-masked]>
> 

> > So I would propose that we have a mechanism for pushing this policy
> > away from DNS but using the DNS to point to the location.
> 
> ...

well, we could certainly benefit from subclassing that wasn't affected by
zone cuts.  to have done this right in dnssec we could have had to say
aaaa.rrsig._dnssec.www.example.com and ds.www._dnssec.example.com, noting
that the _dnssec marker is *after* the delegation point name in the parent,
just to keep this data both "in the parent" and "not in the same node".  to
avoid this fought a harder and longer battle which was to change the model
for delegation and allow a DS RR to be in the parent even though nothing
else can be.  this is a systemic weakness in the dns design, and if we'd
been thinking correctly we would have added subclassing instead.  it's not
too late to think about what we want dns to really be.  i don't like TXT
for stuff like SPF even though i do understand why people use it.  since
that's how new apps (like kaminsky's tlssec work) are going to occur, this
is the working group where we ought to help them not break dns with lots
and lots of large unsubclassable and unrelated TXT RRs in an RRset.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Dec 2010 11:22:47 -0500

On Thu, Dec 23, 2010 at 04:09:18PM +0000, Paul Vixie wrote:
> too late to think about what we want dns to really be. 

I fully agree that proposals for subclassing belong here.  Maybe I
misunderstood Jay's suggestion, but I didn't think that's what he was
making.  Nevertheless, if people have plans for some sort of
subclassing mechanism, yes, I think it's completely on-topic here and
that this is the audience for how that ought to work.  (I still think
finding out whether the application users of the data want that
support is important.  The sound of crickets in response to our pleas
for input on aliasing has tended to make me think -- even more than I
used to -- that adding features to solve a problem that we don't
ourselves have is not a good idea.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 23 Dec 2010 11:55:31 -0500

troll daily nutritional requirements are met in another mailing list.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 23 Dec 2010 17:26:51 +0000

>> (at least to find out what they want?)

To which I reply:
OK -- to phrase it another way, I disagree with the way this appeared to be going (from Jay's original proposal).

I do not for a moment believe that this WG (or any other, or the IESG, or IAB) is going to be able to stop folk using existing RRs for their own purposes. or be able to decide what is a policy and what isn't. See the keyassure ML for proof (but not, of course, proof of trolls).

I am a load happier with Andrew's later response that this does not envisage "engaging", for the very reasons (e.g. aliases) he gave.

but ...
If this is just a pointer out to some other resource specifying policies, what's wrong with just provisioning a NAPTR with a pointer to an XML document on a server? No change to DNS needed. Others get to "engage" in specifying the XML schema.

If you really want to do some work, produce a semi-cloned RR with a new RR type that is only used to point to policy documents.

Why is anything else needed?
Otherwise, this seems to be just another occasional spasm over "misuse" of the DNS, without an incontrovertible basis.

atb,  L

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 17:38:17 +0000

I have been working on ways to make subclassing work. For a more detailed
exposition, please look at my posts in DANE (formerly keyassure).

Note that since most of my current work builds on DNSSEC, my interest in
subclassing is mostly limited to using it for distinguishing records by
protocol. In DKIM and SPF the protocol had to work with legacy DNS servers
and so the lack of support for unknown RRs was significant. If we are
building on an assumption of using DNSSEC, we can assume that the server
supports insertion of unknown RRs. So unless the process for getting new RRs
assigned proves to be unworkable, I prefer to use a new RR.

The basic limitation of sub-classing is that a given record can be used with
aliasing and/or wildcards or with subclass prefixes but not both.

So the general scheme I am using in my revised extended discovery scheme
combines two records

RR-A  may be wildcarded and aliased but not subclassed.
RR-B is always subclassed and must be applied to a canonical name.

So imagine that we have a zone as follows:

$origin example.com
.                          RR-A   "Global policy"
.                          RR-A   "Lookup SRV & ESRV"
www                        CNAME  example.com
*                          CNAME  example.com
_http._tcp.example.com     RR-B   "Protocol policy"
_http._tcp.example.com     SRV   1 1 80 h1.example.com
_http._tcp.h1.example.com  RR-B  "host policy"

The discovery chain always starts with a non-subclassed lookup for RR-A.

If we lookup example.com we get the RR-As. If we lookup www.example.com we
get a CNAME plus the RR-As and if we lookup anything else we get the RR-As
plus a wildcard CNAME.

But after this lookup we are guaranteed a canonical name. Or at the very
least it is not our fault if the name is not canonical and this causes the
DNS resolution to fail.

We can then use protocol level subclassing and even protocol+host level
subclassing without the issues that using direct subclassing would incur.

The main drawback to this approach is that it does require the use of two
records or else wildcarding is going to cause problems. If there is a
wildcard on RR-A it is going to be returned as protocol detail and that is
going to result in a lot of fixup code to avoid unexpected results.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Dec 2010 23:04:59 +0000

> Date: Thu, 23 Dec 2010 11:22:47 -0500
> I fully agree that proposals for subclassing belong here.  ...
> Nevertheless, if people have plans for some sort of subclassing
> mechanism, yes, I think it's completely on-topic here and that this is
> the audience for how that ought to work.  (I still think finding out
> whether the application users of the data want that support is
> important.  The sound of crickets in response to our pleas for input
> on aliasing has tended to make me think -- even more than I used to --
> that adding features to solve a problem that we don't ourselves have
> is not a good idea.)

the fact that dns does not offer what people want and need won't be
readily apparent to "us" here in ietf-dnsext, that much is true.
likewise the solutions we may be able to offer won't be readily relevant
to application designers either because they think of dns as frozen or
because they don't want to deal with this working group's cantakerousness.

that sounds like, but need not be, a deadlock.  what's needed is not a
generally agreed problem statement but a generally compelling vision
statement.  that's why i wrote:

>> it's not too late to think about what we want dns to really be. 

it's up to those who know where the limits are AND who know how those
limits have stressed application designers, to describe possible paths
forward.  that's what john's doing with his reputation proposal since he
knows a lot about the reputation industry.  those here asking the
question, "why are you using dns for this at all when rsync would do?"
can be just ignored.  don't debate that point here -- it's a useless waste
of the working group's energy.  either there's a compelling vision or not.

dns has very high inertia due to its installed base.  a simple proposal
like EDNS0 has taken a decade to come anywhere close to a tipping point.
it's possible that we should treat that as a given and never add more to
DNS again unless it's stepwise (like UPDATE or IXFR or NOTIFY) and has
immediate benefits to those who use it and zero costs to those who don't.

so, simple-sounding proposals like "in EDNS2, the RR CLASS field is a
selector within an RRSet, and is no longer a namespace selector or a
zone attribute" fills me with dread and i don't even want to bother to
write it up, not just because of working group cantankerousness but
because i don't know how many more decade-long DNS feature deployment
curves i can ride.

our useful questions are of the form "hey this would be cool and it would
make it easier to do things like XYZ that currently stress the model, does
anybody want to work on it with me?"

---

From: John Levine <[email-masked]>
Date: 23 Dec 2010 23:07:42 -0000

>what the presumed policy stakeholders think about the "alias" issue,
>I don't believe for a New York minute that we're going to be
>successfun in engaging in dialogue.

Actually, I think we learned pretty well.  They want aliased domains
to be "the same" for an ill-defined version of same that is far beyond
the abilities of any possible tweak to the DNS to provide.

The lesson I take away is that implementing powerful and complex
policy languages is a waste of time, because the only policy
assertions that are generally useful in a large scale environment like
the Internet are quite simple.

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: Otmar Lendl <[email-masked]>
Date: Mon, 27 Dec 2010 11:36:01 +0100

> - here is how I intend to connect to hosts that conform to A

FYI,

I proposed a scheme to solve these a few years ago in the context of SIP
peering. In hindsight, the proposal was way too ambitious to catch on in
the speermint WG. It also relies on the DDDS, which has its own problems,
especially the selector within the RDATA.

If you want to have a look, check out

http://tools.ietf.org/html/draft-lendl-domain-policy-ddds-02
(the generic framework)

http://tools.ietf.org/html/draft-lendl-speermint-federations-03
(a use-case for federation-based SIP peering)

http://tools.ietf.org/html/draft-lendl-speermint-technical-policy-00
(a use-case similar to what you listed)

There is even running code for this:
http://www.kamailio.org/docs/modules/stable/modules_k/domainpolicy.html
Look for "Usage Scenarios" to see some examples on what could be done with
this approach & code.

----

No, I'm not proposing that this list is taking these drafts up again. I
just hope that they might inspire some other ideas, and if they are just
used to fend off IPR claims in the future, I'm also satisfied.

cheers,

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Dec 2010 11:19:32 +0000

The principle objection to putting policy in the DNS seems to be that doing
so represents a slippery slope and that we might end up with people putting
so much information in their DNS that it 'breaks'.

I don't see any reason that the policy information need go beyond that
needed to establish a sufficient connection to negotiate any additional
parameters that might be needed.

So it is not necessary (at present) to say anything more than 'TLS version
1.0 or better always offered, key is X' as far as TLS configuration goes
since TLS has an adequate mechanism for in-band negotiation of cryptographic
parameters once it is known that it is to be used.

It would be very easy to define a property in an extensible mechanism such
as CAA that would allow for linking to an external policy, but I absolutely
do not see any need to do so at present.