Re: [RPSEC] Interior vs exterior?

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Fri, 18 Oct 2002 bmanning@karoshi.com wrote:

> > - Supposedly, the information would reside inside the network advertising
> >   a routing policy itself. What happens if this network is unreachable?

> 	RFC 1219.  DNS servers should be on different pwoer grids, e.g.
> 	physically diverse.  So when your master dies or your network
> 	is degraded by backhoe fade, you have slaved the data to (at least)
> 	one other remote server.

Yes, but this secondary server can only repeat the existing data. If the
outage is caused by incorrect filters derived from an incorrect routing
policy, there is no clear recovery path.

> > - What about delays and inconsistencies that arise when new delegations
> >   must be created and/or information is changed but still cached in
> >   certain places?

> 	What about them?

Ever since people started refusing to have their resolvers talk to
outsiders, the DNS has been a lot harder to debug. The RR system is not
without problems because you never know when people updated their filters.
But by having this in the DNS you add another layer of uncertainty: you
don't know when they created their filters AND you don't know the version
number for the zone they used.

> > I love the DNS to death, but I think we should be very careful about
> > overloading it. (If only to keep the DNS guys off our back...) It might be
> > good to create a new distributed database for routing information (and
> > potentially other stuff), that can address some of the DNS weaknesses.

> 	Not nearly as big an overload as (NAPTR, ENUM, IDN, DNSSEC...)
> 	Its a bunch of TXT RRs for crying out loud.  No change in
> 	the DNS at all.  Its a simple matter of implementation.

> 	Its not goofy, like the proposal to validate all routes received
> 	by checking them in the DNS -BEFORE- using them.  This is an
> 	OOB check that the route received is being announced as intended
> 	by the proper delegee.

Lets not forget that this can't really work anyway since no router can
hold the configuration necessary to filter every announcement.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec