Re: [dane] terminology question

Olafur Gudmundsson <> Fri, 14 February 2014 21:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A9BF1A0437 for <>; Fri, 14 Feb 2014 13:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.493
X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QMY9E-W84RhI for <>; Fri, 14 Feb 2014 13:49:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC2951A03E4 for <>; Fri, 14 Feb 2014 13:49:46 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (SMTP Server) with ESMTP id 4281B148405; Fri, 14 Feb 2014 16:49:45 -0500 (EST)
X-Virus-Scanned: OK
Received: by (Authenticated sender: with ESMTPSA id 035D7148257; Fri, 14 Feb 2014 16:49:44 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Fri, 14 Feb 2014 16:49:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Peter Saint-Andre <>
X-Mailer: Apple Mail (2.1510)
Cc: " list" <>
Subject: Re: [dane] terminology question
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 21:49:53 -0000

On Dec 6, 2013, at 3:40 PM, Peter Saint-Andre <> wrote:

> Hash: SHA1
> Hi Olafur, thanks for the reply. Comments inline.
> On 12/4/13 6:47 AM, Olafur Gudmundsson wrote:
>> On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre <> 
>> wrote:
>> In RFC 6125, Jeff Hodges and I tried hard to define some
>> terminology related to certificate checking in TLS. That
>> terminology might not be ideal, but I'd like to see if we can
>> align draft-ogud-dane-vocabulary with the RFC 6125 terms.
>> In particular, RFC 6125 uses the term "source domain" to refer to 
>> the fully qualified domain name that a TLS client expects to find
>> in the certificate (or, in DANE, potentially the key) that is
>> presented by the TLS server. RFC 6125 also uses the term "derived
>> domain" to refer to a domain name (or host name) that the client
>> has derived from the source domain in an automated fashion (e.g.,
>> via a DNS SRV record).
>> As far as I can determine, draft-ogud-dane-vocabulary uses the
>> terms "Query [Name]" and "Final [Name]" for something like "source
>> domain" and "derived domain". However, draft-ogud-dane-vocabulary
>> also uses the terms "Service Specification Records" and "Service
>> Address Records" in a way that might be similar, although I confess
>> that I don't really grok draft-ogud-dane-vocabulary in fullness and
>> the latter two terms are unclear to me.
>>> Peter,
>>> Thanks asking this question,
>>> You made me read RFC6125 and to my horror the vocabulary there
>>> is attempting similar things as I'm doing in my draft, but in
>>> section 1.8 I realized that you might have taken a shortcut that
>>> leads to a incomplete specification i.e. you are not taking into
>>> account the effects of CNAME and DNAME records on the resolution,
>>> in particular DNAME requires careful rules as to the names used
>>> to present to the servers.  (my guess is this is where the "i
>>> don't really grok" comment comes from)  (I think NAPTR has
>>> similar effects).
> You are right, we did not address CNAME, DNAME, or NAPTR. The spec was
> already convoluted enough. :-) But I think that was an oversight on
> our part. I've bcc'd Jeff so he's aware of it.
>>> "Source domain" definition  is a good example of this. In 
>>> -vocabulary- draft the application issues query for "query name"
> Which, I take it, is roughly equivalent to "Name" in RFC 2782, right?

Yes just more expressive :-) 

>>> where it is expecting to find the "Service Specification
>>> Records".
> I'm not clear on exactly what those are. Perhaps a few (clearer?)
> examples would help. The current examples confuse me:
>   Protocols have different ways to provide information about where
>   servers are located.  Web servers are frequently specified by name
>   i.e. the "www" prefix.  Email servers have a special RR type (MX),
>   Jabber uses SR records, ENUM uses NAPTR records etc. and there are
>   also protocols that use a combination like S-NAPTR a schema where
>   NAPTR records are used to specify where to look for SRV records.  For
>   all practical purposes NAPTR + SRV should combined be treated as the
>   Service Specification.
> Does this mean that "www" is a Service Specification Record? ;-)
No it says the "A" record at www… is the SSR 
I will fix this text to be clearer, rewrote the section to large extent. 

> It makes sense to me that, say, the result of an MX or SRV query is a
> "Service Specification Record" -- a query for _Service._Proto.Name
> gives you one or more addresses that together specify the service. For
> example:
In my terminology the MX is the Service Specification Record. 
> $ dig +short -t SRV
> 5 0 5269
> 20 0 5269
> 20 0 5269
> 20 0 5269
> 20 0 5269
> Is that what you have in mind?

>>> but DNAME/NAPTER/CNAME  rules may rewrite the name sent to 
>>> application server to the "resulting name" from the query
> Understood.
>>> thus the term "Offered Name".
> Offered by whom?
The application when it sends a "name" in its request after connecting. 

>>> For HTTP Service Specification Records == Service Address
>>> records i.e. address record is the service specification,
> I assume that's because no MX, SRV, etc. is used for HTTP?

Yes we are living with the mistake of HTTP of not using SRV records in the beginning :-) 

>>> but Jabber  uses SRV records for the Service Specification
>>> Records and the Service Address Records are associated with the
>>> servers listed in the SRV RRset.
> What does "associated with" mean here?

The intent is say, "the address records returned when the address records of the 
servers are queried for"  ? 
> I find the definition of "Service Address Records" confusing, too:
>   This is where the address records used by the servers reside,
>   specifications SHOULD NOT make a difference between what kind of
>   address records are used.
> I am not sure what you mean when you talk about location here, i.e.,
> the place where the address records reside. What kind of location are
> we talking about?

I agree and will fix I was trying to cover both IPv4 and v6 plus the possibility of
geolocated address being returned. 

How about: "These are the address records for the that offer the service." 

>>> To a large extent I think the differences we see are due to the 
>>> different approaches, i.e. you are attempting to word rules for 
>>> existing applications.
> Yes. Plus I don't have a pair of DNS glasses that enables me to see
> things the way you do.

Nor do I have good App glasses :-) 

>>> I'm defining rules that are general and ignore the names
>>> existing applications have used an concentrate on concepts that
>>> then can be used by application specifications. I wanted to
>>> create definitions that allow minimal DNS related text inside a
>>> DANE application specification (not sure I'm there yet).
> Yes, I can see that's what you're doing. However, I find the level of
> abstraction you've reached to be a bit rarified. At least, it's not
> grounded in things that I can grasp easily (application space). But
> that's perhaps my problem, not yours. :-)

I think it is both our problems, I need to do better job of explaining,
others need to tell me what needs explanation. 

>> Naming is hard, and I hope we can get it right.
>>> Naming of concepts is hard, definitions are hard, understanding
>>> the nuances of interaction of multiple protocols is even harder
>>> :-)
> Indeed. :-)

Sorry for taking this long to respond this fell of my todo list :-( 


> Peter
> - -- 
> Peter Saint-Andre