Re: transparent addrsel policy adjustment for outbound TE

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
> I mean, since the SRV record has this special name associated, it may not 
> trivial for the resolver to figure out which SRV record to query if the 
> application wants to initiate a communication with machine1.foo.com
>
> so perhaps it makes sense to go all the way and use new RR

Could be though, it could probably be trivial to define a something 
special like _shim6._ip.FQDN

> > This would not have any negative impact on the application as all the 
> > addresses would still be there but the ordering would just be modified 
> > based on preferences, though running transparent SRV lookups could incur 
> > delays etc. if it's not done in parallel.
> >
> > This could be very effective means for outbound TE decisions without a need 
> > to touch applications at all.
>
> well, actually i see it exactly the opposite :-)
> this is really useful for inbound TE
>
> I mean, outbound TE is the easy part, since the multihomed site is 
> in control of the packets and it can route them however it wants to. 
> So, outbound TE can be done by affecting routing or by configuring 
> the source address selection policy table and so on.

Simple routing changes don't help if ingress filtering is in place, 
because the sources select the addresses and have to be routed in a 
very restricted manner.  A part of this is an alternative means for 
"policy distribution" for hosts, I guess.

> > This doesn't really help with inbound TE though.  (One could add similar 
> > function the site's authoritative DNS server, and unmodified resolvers 
> > might comply with that policy, but caching DNS servers would mess this up.)
>
> why?
> i agree that the expressed policy has to be quite stable, i mean, the cache 
> will introduce certain inertia, and changing the preferences may take some 
> time, but at least you can express some preferences about which addresses the 
> site preffers for incoming communications...

The problem is that DNS caches in the middle will cache both IP_1 and 
IP_2, but lose the "preference" which is conveyed by the weighted 
address ordering, because from the DNS cache perspective IP_1 and IP_2 
are equivalent.

So this only works if there are no DNS caches in the middle, AFAICS.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings