Hi Stephan,
When relying on S-NAPTR (RFC3958), redirection is only possible inside
sub-domains of the original domain name. This is a restriction compared to the
use of normal NAPTR and REGEXP. The following recommendations can be also found
in the RFC6733: "The domain suffixes in the NAPTR replacement field SHOULD
match the domain of the original query." Actually, I don't even understand the
"SHOULD" here without any clarification on what to do if not... but it is
another debate.
Therefore, my understanding is that the use of S-NAPTR is not suitable for
redirection when the target domain name is different from the original one. And
the current draft proposes to allow any kind of redirection without any impact
on existing DNS infra.
But as I said, it is only based on my understanding and I'm not an expert on
DNS.
Regards,
Lionel
-----Message d'origine-----
De : dime-bounces(_at_)ietf(_dot_)org [mailto:dime-bounces(_at_)ietf(_dot_)org]
De la part de Stefan Winter
Envoyé : lundi 19 août 2013 10:16
À : dime(_at_)ietf(_dot_)org; 'IETF Discussion Mailing List'
Objet : Re: [Dime] Last Call: <draft-ietf-dime-realm-based-redirect-11.txt>
(Realm-Based Redirection In Diameter) to Proposed Standard
Hello,
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Realm-Based Redirection In Diameter'
<draft-ietf-dime-realm-based-redirect-11.txt> as Proposed Standard
Sorry for bringing this up so late, but as I was writing my own dynamic
discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for
Diameter brings a built-in support to signal realm-based redirect
*if* S-NAPTR discovery is used.
That only affects this document periphally; it describes realm-based redirect
for agent-based redirects, not for DNS-based; but still, the wording in section
2 implies that using a realm-based-redirect-aware Diameter agent is the only
choice, and I think that should be rectified.
The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec
by allowing for "non-terminal" lookups; this is signalled by having neither an
"s" flag (for SRV targets) nor an "a" flag (for A/AAAA targets); but instead an
"" (empty) flag. The replacement string in the NAPTR record is then the label
of /another/ NAPTR lookup; that lookup is then to be performed with the same
service/protocol tag.
That makes the whole realm-based redirect problem very easy protocol-wise.
Consider a realm "foo.example" who wants to tell its Diameter peers that its
realm's application ID 123 is from now on served from "example.com". It puts
into DNS
foo.example. 43200 IN NAPTR 100 10 "" "aaa+ap123:diameter.tls" ""
example.com
A client who got this answer would then query for
example.com NAPTR "aaa+ap123:diameter.tls"
and would get example.com's servers via SRV or A/AAAA records as configured by
the admins of example.com.
This is described in section 2.2.3 of RFC3958.
Now for the wording in the draft:
Sction 2: the first para needs a bit of a rewrite to factor in S-NAPTR's
capabilities.
I suggest something along the lines of:
"Realm-based redirection is implicitly a part of the Diameter base protocol,
but only where peer discovery using S-NAPTR is used (section
5.2 of [RFC6733], by using the non-terminal S-NAPTR flag). This allows for both
application-specific realm-based redirects, and for application-agnostic
(unconditional) realm-based redirects, and does not require any Diameter agents.
For deployments which do not make use of S-NAPTR peer discovery, support of
realm-based redirection MUST be specified as part of functionality supported by
a Diameter application. (... continue with the rest of the section ...)
Greetings,
Stefan Winter
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-08-27. Exceptionally, comments
may
be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
the
beginning of the Subject line to allow automated sorting.
Abstract
Message redirection is a basic capability provided by the Diameter
base protocol. In its conventional form, message redirection is
performed by an application-independent "redirect agent", which
returns one or more individual hosts to the message sender as
possible destinations of the redirected message.
However, in some circumstances an operator may wish to redirect
messages to an alternate domain without specifying individual hosts.
This document specifies an application-specific mechanism by which
that can be achieved. New applications may incorporate this
capability by reference to the present document.
Because the redirection mechanism is application-specific, it must be
performed by a Diameter server or proxy rather than a basic redirect
agent as defined in the Diameter base protocol. A new term, "Realm-
based Redirect Server", is introduced in this document to
differentiate the application-specific nature of realm-based
redirection from the conventional Diameter redirection performed by a
basic redirect agent.
This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to
the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
AVPs.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/b
allot/
The following IPR Declarations may be related to this I-D:
http://datatracker.ietf.org/ipr/1254/
_______________________________________________
DiME mailing list
DiME(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dime
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche 6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.