An Experiment in DNS Based IP Routing
RFC 1383
|
Document |
Type |
|
RFC - Experimental
(December 1992; No errata)
|
|
Author |
|
Christian Huitema
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1383 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group C. Huitema
Request for Comments: 1383 INRIA
December 1992
An Experiment in DNS Based IP Routing
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Table of Contents
1. Routing, scaling and hierarchies ...................... 1
2. Routing based on MX records ........................... 2
3. Evaluation of DNS routing ............................. 3
3.1 Loops and relays ..................................... 4
3.2 Performances and scaling ............................. 5
3.3 Tunneling or source routing .......................... 6
3.4 Choosing a gateway ................................... 6
3.5 Routing dynamics ..................................... 6
3.6 DNS connectivity ..................................... 7
3.7 On the way back ...................................... 8
3.8 Flirting with policy routing ......................... 8
4. Rationales for deployment ............................. 9
4.1 The good citizens .................................... 10
4.2 The commercial approach .............................. 10
5. The experimental development .......................... 11
5.1 DNS record ........................................... 11
5.2 Interface with the standard IP router ................ 12
5.3 The DNS query manager ................................ 12
5.4 The real time forwarder .............................. 12
5.5 Interaction with routing protocols ................... 13
6. Acknowledgments ....................................... 13
7. Conclusion ............................................ 13
8. References ............................................ 14
9. Security Considerations ............................... 14
10. Author's Address ..................................... 14
1. Routing, scaling and hierarchies
Several recent studies have outlined the risk of "routing explosion"
in the current Internet: there are already more than 5000 networks
announced in the NSFNET routing tables, more than 7000 in the EBONE
Huitema [Page 1]
RFC 1383 DNS based IP routing December 1992
routing tables. As these numbers are growing, several problems
occur:
* The size of the routing tables grows linearly with the
number of connected networks; handling this larger tables
requires more resources in all "intelligent" routers, in
particular in all "transit" and "external" routers that
cannot rely on default routes.
* The volume of information carried by the route exchange
protocols such as BGP grows with the number of networks,
using more network resources and making the reaction to
routing events slower.
* Explicit administrative decisions have to be exercised by
all transit networks administrators which want to
implement "routing policies" for each and every
additional "multi-homed" network.
The current "textbook" solution to the routing explosion problem is
to use "hierarchical routing" based on hierarchical addresses. This
is largely documented in routing protocols such as IDRP, and is one
of the rationales for deploying the CIDR [3] addressing structure in
the Internet. This textbook solution, while often perfectly adequate,
as a number of inconveniences, particularly in the presence of
"multihomed stubs", e.g., customer networks that are connected to
more than one service providers.
The current proposal presents a scheme that allows for simple
routing. It is complementary with the classic "hierarchical routing"
approach, but provides an easy to implement and low cost solution for
"multi-homed" domains. The solution is a generalization of the "MX
record" scheme currently used for mail routing.
2. Routing based on MX records
The "MX records" are currently used by the mail routing application
to introduce a level of decoupling between the "domain names" used
for user registration and the mailbox addresses. They are
particularly useful for sending mail to "non connected" domains: in
that case, the MX record points to one or several Internet hosts that
accept to relay mail towards the target domain.
We propose to generalize this scheme for packet routing. Suppose a
routing domain D, containing several networks, subnetwork and hosts,
Show full document text