[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: BDX address recipe outline.
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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]