OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [bdx] BDX address recipe outline.

for a laymen, can i get a feel for how this varies from the use of DNS currently proposed by BDX (and implemented in PEPPOL)?

On 26/10/11 1:51 AM, Moberg Dale wrote:

In this message, a way to use IETF DNS functionality for the BDX address resolution is sketched.  The resolution using a canonical concatenated string of bdx metadata that has been made opaque (in whole or part) by using a cryptographic hash. Apparently this masking has been required  to meet some commercial concerns about not disclosing what organizations use which providers).


The main point here is to show that BDX address lookup requirements are met by using a known registry (DNS) with known internet scalability and manageability, using already existing approved standards.


By analogy with ENUM, (see information box below for an introduction to ENUM from voip-info.org), we can therefore concatenate BDX service metadata identifiers to a string in a canonical way, use sha-256 to produce a resource identifier, introduce a DNS NAPTR record for that identifier in the “peppol.org” domain or whatever , do a DNS query on the resulting value, and  resolve in a standardized way (indicated by the “A” flag of the NAPTR record) to A, AAAA or A6 address records.


(For extra spice, add DNSSEC to prevent cache poisoning at the “peppol.org” domain. Use DANE for DNS based PKI if desired for TLS. Many variations are possible for the NAPTR string on  concatenation order, separators, hashing procedures to meet visibility or nondisclosure concerns. Another variation would insert a “S” flag in the NAPTR RR, and then look up SRV records for a domain name key, from which address records would be obtained. This additional step would allow multiple BDX servers to be advertised for a provider, e.g.)


IETF has evolved DNS to support many use cases beyond simple FQDN to Inet address lookups. Isn’t it preferable to actually use DNS, its query system, and its zone update management procedures instead of creating a hybrid Web Service and DNS mashup for a use case that is already easily handled by a simple profile of current specifications?



From http://www.voip-info.org/wiki/view/ENUM


You can dial a telephone number and reach a SIP, H.323 or any other Internet Telephony user. This all happens in the background; you do need to do anything special while calling someone.

A server with ENUM support will lookup a dialed telephone number in the ENUM tree of the DNS to see if there's alternate ways to set up the call instead of just calling out on the PSTN telephone line. ENUM may contain a reference to a SIP URI, a telephone number to dial, a web page or an e-mail address.

Enum uses DNS NAPTR resource records.


DNS NAPTR resource records are documented in RFC 2915: This document describes a Domain Name System (DNS) resource record which specifies a regular _expression_ based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). […] This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.


fn:Tim McGrath
org:Document Engineering Services
title:Managing Director

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]