Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

From: Jakob Schlyter <[email-masked]>
Date: Mon, 1 Nov 2010 11:14:09 +0100

On 31 okt 2010, at 05.51, James Cloos wrote:

> I do like the idea of using SRV or NAPTR RRs.  Of course, if you are
> going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to
> also resolve _sip._tcp.example.com. IN TLSFP.  Maybe it would even be
> better to just resolve _sip._tcp.example.com. IN ANY and expect both
> in the same reply.  (Is that, with the dnssec overhead, still small
> enough for a udp packet?)

Publishing the key/hash material at the same name as the SRV doesn't work that well with managed services, e.g. if I use Google Apps for my jabber services, storing the keys at _jabber._tcp.kirei.se will not help, as I do not manage the keys - Google does. In this case, the key material that will be used is better stored at the SRV destination (e.g., xmpp-server.l.google.com.). I believe this is discussed further in draft-saintandre-tls-server-id-check. Given this, IMHO, the key material for my mail server should be stored at the MX destination mail.kirei.se - not kirei.se nor _smtp._tcp.kirei.se.

	jakob

-- 
Jakob Schlyter
Kirei AB - http://www.kirei.se/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Nov 2010 09:46:07 -0400

+1

There are several use cases here. I think they are all manageable but we need more than just a single flag.

Performance matters here. But we should not allow performance to drive requirements. If we can get all the requirements on the table (performance included) we can then see who can propose the best trade off that gets most support.

Remember that in the context of a complete transaction a better discovery mechanism that allows the client to select the nearest service may be better overall than one that minimizes dns round trips. Also there is scope for optimizing the DNS protocol itself.

For example, we could use EDNS to advertise support for a 'megaquery' which would be a new query format that contains separate slots for the protocol, name, try number. If we have a common discovery architecture defined the resolver can then ferret out all the data required and deliver it on a plate.

A secondary advantage of this approach is that the DNS resolver can optimize its cache strategy for protocols where interactive response is most important.

Sent from my iPad

On Nov 1, 2010, at 6:14 AM, Jakob Schlyter <[email-masked]> wrote:

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

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 2 Nov 2010 11:30:46 +0100

> For example, we could use EDNS to advertise support for a 'megaquery' which would be a new query format that contains separate slots for the protocol, name, try number. If we have a common discover…

Although I agree with the usefulness of such an EDNS option, I do not think this is within the scope of KIDNS to extend the current DNS protocol with such an option.

	jakob

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Nov 2010 06:36:40 -0400

On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:
> 
> For example, we could use EDNS to advertise support for a
> 'megaquery' which would be a new query format that contains separate
> slots for the protocol, name, try number. If we have a common
> discovery architecture defined the resolver can then ferret out all
> the data required and deliver it on a plate.

I am not a big fan of turf wars in the IETF, but it seems to me that
any development along the lines you are suggesting is pretty clearly
going to need to go through DNSEXT.  A clear (and I do mean painfully
clear) requirements document outlining exactly what functionality is
required, however, would go a long way to making such development
possible in DNSEXT.  Note that I am very keen to avoid a repeat of the
current disaster with respect to "aliases" in the DNS, and I think
this community is more sensitive to details of how DNS works than the
community whence came the alias work.  So if this is something
desirable, I would encourage the development of such a requirements
document either in this proto-group or else independently, by some of
the participants.

Best,

A

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Nov 2010 08:54:09 -0400

Of course any proposal to implement would have to go through DNSEXT.

But the option of optimizing the DNS protocol is relevant to the question of
performance and the number of round trips discovery takes.

Performance and functionality need to be considered differently in this
respect. I don't think we should develop a proposal in one WG that depends
on another WG accepting some structural change to work at all.

So depending on DNSEXT producing a BNAME specification would be a disaster
in my view. There are enough constraints on that problem already without
introducing even more. But proposing to DNSEXT a rather modest performance
improvement that is not essential does not bother me much.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 09:49:36 -0400

On Nov 2, 2010, at 6:36 AM, Andrew Sullivan wrote:

> going to need to go through DNSEXT.

Yes, fully, 100% agree...

>  A clear (and I do mean painfully

I am not convinced that this is path that we want to go down (the idea, not the "write it up if y'all want DNSEXT to even consider it"), I think that, at the moment, we are more rumbling about various blue sky possibilities... If it turns out that we do end up going down this path, it will be after some serious thought -- making changes that affect basic plumbing and require changes in the behavior of resolvers is not to be taken lightly, and will make deployment *really* *really* hard...

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Nov 2010 10:16:52 -0400

I think my original point has been lost, what I originally wrote was:

"Performance matters here. But we should not allow performance to drive
requirements. If we can get all the requirements on the table (performance
included) we can then see who can propose the best trade off that gets most
support.

Remember that in the context of a complete transaction a better discovery
mechanism that allows the client to select the nearest service may be better
overall than one that minimizes dns round trips. Also there is scope for
optimizing the DNS protocol itself."

If people care about performance then they should be looking at the whole
protocol interaction and not just one module in isolation.

On Tue, Nov 2, 2010 at 9:49 AM, Warren Kumari <[email-masked]> wrote:

> I am not convinced that this is path that we want to go down (the idea, not
> the "write it up if y'all want DNSEXT to even consider it"), I think that,
> at the moment, we are more rumbling about various blue sky possibilities...
> If it turns out that we do end up going down this path, it will be after
> some serious thought -- making changes that affect basic plumbing and
> require changes in the behavior of resolvers is not to be taken lightly, and
> will make deployment *really* *really* hard...
>
> W
>
> >
> > Best,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > [email-masked]
> > Shinkuro, Inc.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 02 Nov 2010 15:29:42 +0100

On 2.11.2010 14:49, Warren Kumari wrote:
>> A clear (and I do mean painfully clear) requirements document
>> outlining exactly what functionality is required, however, would go
>> a long way to making such development possible in DNSEXT.  Note
>> that I am very keen to avoid a repeat of the current disaster with
>> respect to "aliases" in the DNS, and I think this community is more
>> sensitive to details of how DNS works than the community whence
>> came the alias work.  So if this is something desirable, I would
>> encourage the development of such a requirements document either in
>> this proto-group or else independently, by some of the
>> participants.
>
> I am not convinced that this is path that we want to go down (the
> idea, not the "write it up if y'all want DNSEXT to even consider
> it"), I think that, at the moment, we are more rumbling about various
> blue sky possibilities... If it turns out that we do end up going
> down this path, it will be after some serious thought -- making
> changes that affect basic plumbing and require changes in the
> behavior of resolvers is not to be taken lightly, and will make
> deployment *really* *really* hard...

I agree with Warren.  Crafting a solution in KIDNS which is based on 
"EDNS1" is a good way how to kill it.  I think we are talking here about 
premature optimizations while we don't have the basic work done.

There are more interest groups which would benefit from packing multiple 
queries into one packet, but my view is that such a change is even more 
bothersome then "aliasing".

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 02 Nov 2010 15:42:52 +0100

On 2.11.2010 15:16, Phillip Hallam-Baker wrote:
> requirements. If we can get all the requirements on the table
> (performance included) we can then see who can propose the best trade
> off that gets most support.
>
> Remember that in the context of a complete transaction a better
> discovery mechanism that allows the client to select the nearest service
> may be better overall than one that minimizes dns round trips. Also
> there is scope for optimizing the DNS protocol itself."

Changes (optimizations) of DNS protocol affects more parties than just 
creating new RRs and teaching clients to ask for them.  You need support 
for new "option" all along the way (in all resolvers), and it becomes 
even more complicated when there are chained caches (with mixed support).

Also you will need to support old clients for a long time and the 
percentage of those who will be able to use the optimization will be 
very low (for a long period of time).

 > If people care about performance then they should be looking at the
 > whole protocol interaction and not just one module in isolation.

Well in case of optimizing the DNS protocol you need to think in much 
broader scope because it affects not just our field, but almost 
everybody out there.

Ondrej

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 10:47:24 -0400

On Nov 2, 2010, at 10:16 AM, Phillip Hallam-Baker wrote:

> "Performance matters here. But we should not allow performance to drive requirements. If we can get all the requirements on the table (performance included) we can then see who can propose the best trade off that gets most support.
> 
> Remember that in the context of a complete transaction a better discovery mechanism that allows the client to select the nearest service may be better overall than one that minimizes dns round trips. Also there is scope for optimizing the DNS protocol itself."
> 
> 
> If people care about performance then they should be looking at the whole protocol interaction and not just one module in isolation.

Yup, sorry, point taken -- I am perhaps overly sensitive about ratholes and distractions, but realize that you were just kaing a general point, not "Let's go down this path...". Apologies...

So, specifically to the 'megaquery' (and similar) suggestions -- one (obvious) plan would be to build this all using "current technology" and the cool DNS tricks would be a future optimization. I know that I have alway wanted to be able to query 'www.foo.com' and get a port in addition to an IP (this is less interesting with SNI, but, still...), but haven't wanted it enough to bother *doing* anything about it :-)

W

(Obviously, through DNSEXT, etc...)

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 10:56:05 -0400

On Nov 2, 2010, at 10:42 AM, Ondřej Surý wrote:

> Changes (optimizations) of DNS protocol affects more parties than just creating new RRs and teaching clients to ask for them.  You need support for new "option" all along the way (in all resolvers), and it becomes even more complicated when there are chained caches (with mixed support).

Yes -- look at DNSSEC for an example...

> 
> Also you will need to support old clients for a long time and the percentage of those who will be able to use the optimization will be very low (for a long period of time).
> 
> Well in case of optimizing the DNS protocol you need to think in much broader scope because it affects not just our field, but almost everybody out there.

Yes, not a job to be undertaken lightly, but, once we have consensus (and implementations) of the base work, it MAY be interesting for some of us to consider writing up something and pursue it in DNSEXT, as a DNSEXT (not KIDNS) item -- please note the liberal use of weasel words. 

If all this were to happen, I'd think that the KIDNS "requirements" would be a tiny consideration, and the work would be driven by general utility...

I guess my summary here is that this idea sounds interesting and useful, and that folk should feel free to pursue it if they like, but that (IMO), this isn't the place for it...

W

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 02 Nov 2010 16:00:26 +0100

On 2.11.2010 15:47, Warren Kumari wrote:
>> "Performance matters here. But we should not allow performance to
>> drive requirements. If we can get all the requirements on the table
>> (performance included) we can then see who can propose the best
>> trade off that gets most support.
>>
>> discovery mechanism that allows the client to select the nearest
>> service may be better overall than one that minimizes dns round
>> trips. Also there is scope for optimizing the DNS protocol
>> itself."
>>
>>
> Yup, sorry, point taken -- I am perhaps overly sensitive about
> ratholes and distractions, but realize that you were just kaing a
> general point, not "Let's go down this path...". Apologies...
>
> So, specifically to the 'megaquery' (and similar) suggestions -- one
> (obvious) plan would be to build this all using "current technology"
> and the cool DNS tricks would be a future optimization. I know that I
> have alway wanted to be able to query 'www.foo.com' and get a port in
> addition to an IP (this is less interesting with SNI, but, still...),
> but haven't wanted it enough to bother *doing* anything about it :-)

[moderator hat on]

Could we please stop here.  We are getting off-topic.  So if you 
(generic you, not Warren-you) want to discuss it, please take it to 
DNSEXT.  (And I suggest you go read archives first, I am quite sure this 
has been beaten to the death already when there was A+AAAA.)

O.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Nov 2010 11:34:30 -0400

> premature optimizations while we don't have the basic work done.

Then isn't it  good thing that nobody actually proposed doing that?

My argument was that it was premature to optimize the protocol.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 15:32:25 +0000

On Sat, 30 Oct 2010, Matt McCutchen wrote:
>
> The flag has a simple and clear semantic, "I authorize this certificate
> and only this certificate for use on my TLS server"

That's too simple. You need to be able to publish multiple certificates
(or fingerprints) and exclude certificates that don't match any of them.
This is necessary for rollover, amongst other things.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 16:03:53 +0000

On Sat, 30 Oct 2010, Warren Kumari wrote:
>
> I (no hats) was against the _selector_ idea as I feel that all records
> related to a thingie (technical term) should exist at the same level
> [...], but this is an elegance viewpoint and enough folk have pointed
> out that this is a needed feature that I'm open to it as an idea....
>
> Another option (which has some (IMO) of the elegance retained, but
> probably has scalability and leakage issues) is [...] basically, have
> the records for foo.example.com (or just exmaple.com) all at the same
> level, but have the ports included in the response.

I think both of these are argued against by section 3.1 of RFC 5507.

That RFC also argues against a _prefix approach, but it also fails to
provide any solution for RRs that can apply to any service and which need
to be selected per service.

Another argument against putting all the records at the same domain name
is that it couples the policies for the services together. For instance, I
would want to be able to put certs or fingerprints in the DNS for my
secure services without forcing my colleagues to upgrade their services to
secure-only. (It's reasonable not to prioritize the deployment of
encryption for anonyous services.)

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Nov 2010 09:36:38 -0700

>to be selected per service.

I read that section (and lots of other sections of 5507) as saying "don't assume one solution fits all". But I also note that the section 3.1 talks about the problems of "a large number of services for a single domain name" causing fallback to TCP. In the case of KIDNS, the solution is simple: don't allow a large number of services to be accessed by that domain name just because they are all running on the same box. That is, if the use of subtyping causes a TCP-fallback problem for the nameserver of a particular domain name, the solution is in the hands of the affected parties: use subdomains (which they probably are already doing anyhow...).

>encryption for anonyous services.)

First off, the proposal for "say which services require TLS" is not part of KIDNS, despite what it might seem from reading some of the list traffic. When that protocol is specified, it does not (and I think should not) be linked to the KIDNS key association.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 16:38:59 +0000

On Sun, 31 Oct 2010, Ilari Liusvaara wrote:
>
> If the lookups are done after resolving indirection by SRV, one could
> get along with optional port numbers and protocols (as in, UDP, TCP,
> SCTP...).

That would work except for protocols that do not use SRV.

If you publish the cert material attached to the service domain (as
opposed to the service target hostname) then you also get a performance
advantage since you can do the two lookups concurrently, which your
proposal does not permit.

e.g.

_smtp._tcp.example TLSFP ...
_smtp._tcp.example SRV ...

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 16:44:52 +0000

On Mon, 1 Nov 2010, Jakob Schlyter wrote:
>
> Publishing the key/hash material at the same name as the SRV doesn't
> work that well with managed services, e.g. if I use Google Apps for my
> jabber services, storing the keys at _jabber._tcp.kirei.se will not
> help, as I do not manage the keys - Google does.

Why doesn't CNAME solve this problem?

_jabber._tcp.kirei.se. CNAME _jabber._tcp.whatever.google.com

> In this case, the key material that will be used is better stored at the
> SRV destination (e.g., xmpp-server.l.google.com.).

This forces the two DNS lookups to be sequential which is slow.

> Given this, IMHO, the key material for my mail server should be stored
> at the MX destination mail.kirei.se - not kirei.se nor
> _smtp._tcp.kirei.se.

If they are stored at _smtp._tcp.kirei.se then you can use a CNAME to deal
with outsourced service, and support concurrent lookups of target hostname
and cert material.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 16:57:47 +0000

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> In the case of KIDNS, the solution is simple: don't allow a large number
> of services to be accessed by that domain name just because they are all
> running on the same box. That is, if the use of subtyping causes a
> TCP-fallback problem for the nameserver of a particular domain name, the
> solution is in the hands of the affected parties: use subdomains (which
> they probably are already doing anyhow...).

I think this is foolishly short-sighted and it ruins the simplification
allowed by the SRV record. Just because pre-SRV protocols have to use
subdomains for scalability doesn't mean that is a good usability idea.

It implies that I should change my email address to [email-masked] and
my Jabber ID to [email-masked] etc. etc. so that I can put their
certificates in the DNS.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Nov 2010 13:14:11 -0400

+1 on the RFC 5507

This was actually a major change that was made to the document.
Originally there was a blanket proscription on prefixes that some of
us spent a lot of time and effort to get changed.

There are certainly issues that arise with prefixes as I mentioned in
my other post. But they are tractable provided that:

1) You are prepared to allow an additional DNS round trip.
2) You are prepared to introduce a new DNS RR.

We have to keep an eye on efficiency, but anything we do here is going
to depend on deployment of new DNS support infrastructure and require
transport that supports new RRs.

I think that we should first decide on all the features we might want
and then look at how we implement.

Certificates typically bind to an entire domain.

Statements concerning configuration of a security policy naturally
bind to a specific service at a domain.

I may use the same certificate for my mail and web servers. But I
almost certainly have not configured them identically.

When we start to look at the consequences of outsourcing, the fact
that I have outsourced my Web site to outsource.net does not
necessarily mean I want to trust them with my mail service so maybe
the assumption that certificates are global to a domain also starts to
break down.

So I am thinking that we are going to end up with a requirement for
protocol specific key assurance.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Nov 2010 10:14:49 -0700

>subdomains for scalability doesn't mean that is a good usability idea.

It is still far from clear how KIDNS will deal with SRV, so it is premature to say that subdomains will be a problem. If KIDNS records are retrieved for the name gotten from (not given to) the SRV request, there is no issue, is there?

>my Jabber ID to [email-masked] etc. etc. so that I can put their

No, it does not imply that at all. The discussion of how to deal with end-user certificates in KIDNS has barely begun, and I doubt it will end with what you just said was the implication.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 17:28:30 +0000

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> It is still far from clear how KIDNS will deal with SRV, so it is
> premature to say that subdomains will be a problem. If KIDNS records are
> retrieved for the name gotten from (not given to) the SRV request, there
> is no issue, is there?

Not from the RRset size point of view, but doing that is bad for
performance.

> No, it does not imply that at all. The discussion of how to deal with
> end-user certificates in KIDNS has barely begun, and I doubt it will end
> with what you just said was the implication.

I'm not talking about personal certificates, I'm talking about the mail
and jabber services identified by the domain parts of the addresses.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Nov 2010 10:47:43 -0700

>Not from the RRset size point of view, but doing that is bad for

Can you be specific here? I'm not at all saying you are wrong; I might have dropped something in the redirection. My thought (possibly incorrect) is that one would only do a KIDNS lookup after they had gotten to the terminal end of an SRV chain.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 3 Nov 2010 20:55:40 +0200

> 2) You are prepared to introduce a new DNS RR.

Considering the adoption of CERT RR, CERT RR can almost be treated as
new RR.

And there's a diffrence between having to serialize the query and
firing off the query in parallel with some other qurey one would have
to do anyway.

> transport that supports new RRs.

Well, there's RFC 3597. But of course, new RRs (even if RFC 3597-compliant)
have issues with adminstration.

> Certificates typically bind to an entire domain.

They may, or they may not. Some services use certificates in bizarre
manner and can't share them with anything.

> bind to a specific service at a domain.

If you think HSTS is good example of security policy, consider that
HSTS is really a special kind of protcol-level redirect and is only
well-defined because of interactions between HSTS spec and HTTPS
spec.

That's why I think that records specifying secure equivalent of service
must specify where to locate the service and how to connect to it
(there are essentially two ways).

> the assumption that certificates are global to a domain also starts to

Actually, HTTP is just about the worst in this regard since it does
not support any kind of protocol-specific redirect from DNS. Yes, it
supports CNAME, but CNAME isn't prtocol-specific.

SMTP has MX records, many protocols have SRV, but HTTP does not have
anything like that.
 
> protocol specific key assurance.

Actually, at key assurance level, port numbers/services only matter
if you can partition port numbers/services (which might not be
possible) or if you have services with different security levels on
one name (to prevent attacking higher-security services using stolen
key from lower-security service).

-Ilari

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 19:04:23 +0000

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> Can you be specific here? I'm not at all saying you are wrong; I might
> have dropped something in the redirection. My thought (possibly
> incorrect) is that one would only do a KIDNS lookup after they had
> gotten to the terminal end of an SRV chain.

You can save time if you can do them concurrently.

SRV isn't a chain, it's a single layer of indirection.

Tony.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Nov 2010 21:32:54 +0100

> with outsourced service, and support concurrent lookups of target hostname

I most likely do not have the same key material for all SMTP servers.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Nov 2010 21:57:05 +0100 (MET)

> I most likely do not have the same key material for all SMTP servers.

Which particular situation do you have in mind.

Mutual MX-based backups with other servers is would be a different
issue with independent hostnames.

If your main SMTP hub uses several servers, sharing of private key
and certificate usually should be possible, unless there is a pkcs#12 problem
in the software, or the private key is (marked) non-exporable,
ultimately because the private key is in hardware.

Precluding multiple servers (redundancy) which cannot share keys
would not be a good idea for KIDNS.  For key-rollover, you need
to double that number again...

-Martin

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Nov 2010 22:39:57 +0100

> Which particular situation do you have in mind.

example.com. IN MX 5 mail.foo.com.
             IN MX 10 mail.bar.com.

where foo.com and bar.com does not share key material (e.g. run by different organizations).

in the TLSFP draft, we envision that there will be one TLSFP RR for mail.foo.com. and one for mail.bar.com.

In the example (of future) use of SRV for HTTP:

_https._tcp.www.example.com. IN SRV 0 0 443 web1.example.com.
                             IN SRV 0 0 443 web2.example.com.

where there would be TLSFP RRs for web1 and web2.

There is a possibility that someone wants to name all hostnames (as in, right hand side of SRV/MX/A/AAA) the very same, but still do not share key material. Is this problem large enough that we need to solve that scenario, or can we decide this is not a problem we need to address?

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 23:21:20 +0000

> I most likely do not have the same key material for all SMTP servers.

There's nothing stopping you from having multiple cert records alongside your MX records. It's easy to ensure the DNS is correct if your MXs are managed as a coherent service. Old style secondary MXs cause significant operational problems and no longer have any advantages.

Tony.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 08 Nov 2010 17:47:28 -0500

On 10/30/2010 09:02 PM, Warren Kumari wrote:
>
> On Oct 30, 2010, at 8:07 PM, James Cloos wrote:

> probably has scalability and leakage issues) is
> foo.example.com <http://foo.example.com> IN A 192.0.2.1
> IN KIDNS 443 545254634563546354
> IN KIDNS 993 435245243523452345
> IN KIDNS 5222 23452345435234545
> ) -- basically, have the records for foo.example.com
> <http://foo.example.com> (or just exmaple.com <http://exmaple.com>) all
> at the same level, but have the ports included in the response.
>
>>
>> Or both, preferring the more specific if both exist?
>
> Oooh, that's interesting -- to be honest I hadn't thought of that... One
> huge consideration is minimizing the number of DNS lookups needed to
> make all the magic happen -- if this system requires lots of lookups,
> the browser folk will be unwilling to implement as the user experience
> will be horrendous....
>
>>
>> The more specifc option permits different certs for, eg, _http._tcp
>> vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
>> identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.
>>
>> I can see how each might be perceived as necessary, but also how each
>> might be perceived as undesirable.
>
> Yes, both are (IMO) sub-optimal -- my *personal* view of the world

Rule #1 in DNS land: Do not optimize until you know exactly what the 
problem is as most "design" optimization have turned out to be bad
for protocol or operations.

> involves having unique names for each service (www.example.com
> <http://www.example.com>, imap.exmaple.com <http://imap.exmaple.com>,
> jabber.example.com <http://jabber.example.com>) which sidesteps this
> issue, but enough folk have raised this issue that it needs to be
> addressed....
>
>

There are multiple ways to address this, in general DNS people recommend 
strongly against "sub-typing" i.e. having multiple different protocols 
share the same RRset.
There are number of issues here to think about:
	size of the RRset
	Number of foot prints per protocol/port
	How is/are the RRsets are maintained, in particular is
		dynamic update used.

Think about operations for a minute, if the 'web' team has write access 
via dynamic update to the web KIDNS rrset then they maintain it without
involving the 'dns' team.
Now having the 'mail', 'web' and other protocols share one set then all 
of them either need write access or to involve the 'dns' team for 
arbitration.

As Chome has demonstrated there it is not that hard to have multiple 
queries in flight at the same time, in general the rule should be
"prefer more specific".

Additionally there may be different ways to reach the same service,
like www.foo.bar and foo.bar. are then two copies of KIDNS records 
stored or does the protocol need KIDNS_ALIAS [<port>] <name> that has
pointer to the real set?

I want to emphasize Jakob's point that it is important to differentiate 
between where service is described (MX) and where it is provided (A 
records).

	Olafur

	Olafur