Subject: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt

From: "Damick, Jeffrey" <[email-masked]>
Date: Wed, 1 Aug 2012 12:59:51 -0400

Believe I've posted to the appropriate location now.

------ Forwarded Message
From: <[email-masked]>
Date: Wed, 1 Aug 2012 11:29:43 -0400
To: "Damick, Jeffrey" <[email-masked]>
Subject: New Version Notification for draft-damick-dns-associated-names-record-00.txt

A new version of I-D, draft-damick-dns-associated-names-record-00.txt
has been successfully submitted by Jeffrey Damick and posted to the
IETF repository.

Filename:        draft-damick-dns-associated-names-record
Revision:        00
Title:           Associated Names DNS Record
Creation date:   2012-08-01
WG ID:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-damick-dns-associated-names-record-00.txt
Status:          http://datatracker.ietf.org/doc/draft-damick-dns-associated-names-record
Htmlized:        http://tools.ietf.org/html/draft-damick-dns-associated-names-record-00

Abstract:
   This document describes a new resource record for the Domain Name
   System (DNS) protocol.  The record introduced will allow associated
   domain names to be associated with a particular domain name and
   retrieved in in a single DNS query.

The IETF Secretariat

------ End of Forwarded Message

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 02 Aug 2012 02:26:18 +0900

Damick, Jeffrey wrote:

Hi,

>     retrieved in in a single DNS query.

Considering that address RRs will be looked up first and, then,
AN RRs, what's wrong to place the information at better place
of HTTP header?

						Masataka Ohta

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Wed, 1 Aug 2012 13:39:05 -0400

So http is one potential use case for this, not necessarily the only one, I've heard other use cases for spdy and other protocols that want to associate domains together.

On 8/1/12 1:26 PM, "Masataka Ohta" <[email-masked]> wrote:

Damick, Jeffrey wrote:

Hi,

                                                Masataka Ohta

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 01 Aug 2012 14:03:15 -0400

On 01/08/2012 12:59, Damick, Jeffrey wrote:
> Believe I’ve posted to the appropriate location now.
>
<no-hat>
I read the draft and have a design question.
You are placing the service selector inside the Record and
implying that there can be records for multiple services provided by 
this name.
Did you consider having the records stored at different names like
    _an-https.<fqdn>
    _an-http.<fqdn>
?

In the past DNS has suffered when a RR uses sub-typing inside the 
record, but in size and in complication of applications selecting the 
right sub-type.
If you store the AN records at selector names you can get rid of the 
service names inside the record.

	Olafur

> ------ Forwarded Message
> *From: *<[email-masked]>
> *Date: *Wed, 1 Aug 2012 11:29:43 -0400
> *To: *"Damick, Jeffrey" <[email-masked]>
> *Subject: *New Version Notification for
> draft-damick-dns-associated-names-record-00.txt
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-damick-dns-associated-names-record-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-damick-dns-associated-names-record
> Htmlized:
> http://tools.ietf.org/html/draft-damick-dns-associated-names-record-00
>
>
> Abstract:

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 1 Aug 2012 20:41:11 +0200

1 aug 2012 kl. 20:03 skrev Olafur Gudmundsson <[email-masked]>:

> implying that there can be records for multiple services provided by this name.
> In the past DNS has suffered when a RR uses sub-typing inside the record, but in size and in complication of applications selecting the right sub-type.
> If you store the AN records at selector names you can get rid of the service names inside the record.

Agree with this comment.

Please see RFC 5507.

You could even use the URI record type with a prefix to announce the URIs that will be needed, so you can pre-fetch not only the domain names, but start to fetch the actual data needed...

   Patrik

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Wed, 1 Aug 2012 15:13:34 -0400

I believe the drawback is that rather than being to in bulk query for all AN records the client would have to poke for each service they are using.  For 1 service this isn't  really an issue but if the application wanted to fallback to another another type it would have to re-query for each..  Of course this could be a client optimization exercise.

I agree the service name on the name itself may still make more sense, and I'll review 5507 as Patrik suggested.

Thanks
-jeff

On 8/1/12 2:03 PM, "Olafur Gudmundsson" <[email-masked]> wrote:

<no-hat>

        Olafur

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 1 Aug 2012 21:19:25 +0200

1 aug 2012 kl. 21:13 skrev "Damick, Jeffrey" <[email-masked]>:

> I agree the service name on the name itself may still make more sense, and I’ll review 5507 as Patrik suggested.

Maybe you need what you do _and_ a prefix.

The key thing (I wrote 5507 so I can explain) is that you ensure that clients do not get "too much" data back. If all clients all the time want to have all records in the rr-set, then you are correct. As soon as the client must parse the rdata and select the subset that it is interested in, then you are on the slippery slope and want to insert a selector in the triple {type, class, owner} in the query so that the calculation of the subset is made on the server side.

  Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 02 Aug 2012 05:04:46 +0900

Damick, Jeffrey wrote:

> So http is one potential use case for this, not necessarily
> the only one, I've heard other use cases for spdy and other
> protocols that want to associate domains together.

My point is that applications should take care of themselves,
because they know how they will behave.

> Did you consider having the records stored at different names like

The problem is that necessary associated names depend not only
on service names but also on file names.

						Masataka Ohta

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Wed, 1 Aug 2012 17:17:48 -0400

On 8/1/12 4:04 PM, "Masataka Ohta" <[email-masked]> wrote:

But this record enables applications to take care of themselves, to me it's analogous to the intent of records like: SPF, SSHFP, MX, etc.

Sorry I don't follow the reference to 'file names'?

thanks
-jeff

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 02 Aug 2012 06:47:05 +0900

Damick, Jeffrey wrote:

> But this record enables applications to take care of themselves,

I mean your proposal depends details of application protocols
that let applications take care of themselves, especially
because getting HTTP header is not much more time consuming
than getting AN RRs.

> to me it's analogous to the intent of records like: SPF, SSHFP,
> MX, etc.

No, unlike them, AN burdens DNS blindly in a way not necessarilly
useful to applications.

> Sorry I don't follow the reference to 'file names'?

Do you want me to call them url-pathes?

						Masataka Ohta

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Thu, 2 Aug 2012 09:41:17 -0400

On 8/1/12 5:47 PM, "Masataka Ohta" <[email-masked]> wrote:

As previously mentioned, I'm not trying to solve something just for http, that is of course one use case however I've heard of others..

Would you please elaborate on your position?  I still so no difference between this and those other record types which have meaning to other applications such as, supporting smtp, etc..

I still don't see the connection you are making to URLs, this is only discussing domain names.

-jeff

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 03 Aug 2012 04:56:55 +0900

Damick, Jeffrey wrote:

> As previously mentioned, I'm not trying to solve something just
> for http, that is of course one use case however I've heard
> of others..

And, as I already said, my counter argument is not just for
http.

> Would you please elaborate on your position?

You should learn how to quote others' mails with proper
nesting and line wrapping.

> I still so no
> difference between this and those other record types which
> have meaning to other applications such as, supporting smtp, etc..

Suppose there are:

	http://www.example.com/page0.html with associated names of
	a.example.com and b.example.com

	http://www.example.com/page1.htmlhtml with associated names of
	b.example.com and c.example.com

	http://www.example.com/page2.htmlhtml with associated names of
	c.example.com and a.example.com

how can you set AN of www.example.com?

It all depends on application details of contents of files.

> this is only discussing domain names.

Not at all.

						Masataka Ohta

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Thu, 2 Aug 2012 16:17:22 -0400

> It all depends on application details of contents of files.

I believe the disconnect is that the AN record doesn't reference to or from
URLs, just the domain names.

so you could have: www.example.com with associated names: a.example.com,
c.example.com, b.example.com

But it is not granular to the level of a URL..

-jeff

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 03 Aug 2012 07:47:22 +0900

> c.example.com, b.example.com

Thus, "No, unlike them, AN burdens DNS blindly in a way not
necessarilly useful to applications".

> But it is not granular to the level of a URL..

Thus, "necessary associated names depend not only
on service names but also on file names".

Worse, even only with domain names, aggressive name based
virtual hosting makes NA practically useless. A virtual
name node with a CNAME RR can't have its own AN RRs.

Moreover, file contents and DNS may not shnchronize well
because of lazy administrations or DNS caching.

So, let applications, which exactly, automatically and timely
know what they need, take care of themselves.

						Masataka Ohta

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Fri, 3 Aug 2012 09:01:55 -0400

> necessarilly useful to applications".

Can you please provide more substance to this argument as I would assert
that many other records are 'not necessarily useful to applications' - it
really depends on your point of view.  For example if you application cares
nothing about email than an SPF or MX record doesn't apply to it so they
aren't 'useful' to it.

As far as DNS being blind to it, isn't that the point?

> on service names but also on file names".
They do not depend on file names, URLs, or URIs, no field like that is
defined in the record data..  So there is no tie to 'file names'...

> name node with a CNAME RR can't have its own AN RRs.

However, if I make the modification suggested by Olafur this would be
possible. So that's a good reason to pursue that route.

> know what they need, take care of themselves.

Then why are there records such as SSHFP, IPSSEC, SRV, etc. that 'enable'
applications to take care of themselves.  The draft doesn't specify the
'how' only the 'what', to enable applications to build on it do whatever
makes sense for them in the context of a group of associated domain names..

thanks for the input.

-jeff