> > so the policy you're arguing for is that clients should always randomize?
>
> When the client has topology information it should follow that (i.e. rules
> 1 - 8). When it doesn't have topology information it should use the order
> it gets from the DNS (i.e. rule 10, and historical practice). T
> > only in the case where the server is depending on rr ordering within
> > rrsets, which dns has never guaranteed and which many caches (both rdns
> > and stubs) randomize or reorder anyway, and where the server's
> > imputation of topology knows about every private interconnect that may
> > affe
On Thu, 5 Mar 2009, Paul Vixie wrote:
>
> so the policy you're arguing for is that clients should always randomize?
When the client has topology information it should follow that (i.e. rules
1 - 8). When it doesn't have topology information it should use the order
it gets from the DNS (i.e. rule 1
>/24 - could be, but is it worth?
>/16 - not a chance; there are a lot of LIRs with /20 in RIPE region, so
>/16 is way too
>much (and you can have quicker connection to U.S. than to some parts of
>Europe).
there are three modes here.
first, you can do some good.
second, you ca
> RFC 3484 is correct as it is.
>
>Here I don't. The idea behind is good, the implementation is not.
>Client would have to know BGP path to DA + DB and decide on basis of
>routing protocol. Selection based on longest matching prefix will work
>in only very small percent of cas
On Wed, Mar 4, 2009 at 9:04 PM, wrote:
> we now return you to your rant.
Sorry, if I sounded too harsh.
my error here - Paul said DNS does no ordering... he did not specify
> ordering of what.
Order of RRs in zone file is not relevant for the order "on the wire".
DNS (as in DNS protocol) do
On Wed, Mar 4, 2009 at 6:57 PM, wrote:
> On Wed, Mar 04, 2009 at 05:11:47PM +, Paul Vixie wrote:
> > > > i disagree. dns-based load balancing is an unfortunate overloading
> and
> > > > should never be done. RFC 3484 is correct as it is.
> > >
> > > Why is it right for topology-ignorant cli
* Christian Huitema:
> The order of5C records in a DNS response is, at best, a
> hint. Relying on it as if it were a mandate to clients is a gamble.
When you run RRset-based load balancing, you don't rely on servers
preserving order, or reordering responses. It is completely
sufficient that ther
* Paul Vixie:
> neither a client or a server can be guaranteed topology-aware. dns leaves
> ordering deliberately undefined and encourages applications to use their
> own best judgement.
The "leaves undefined" part is at odds with your previous statement
that RFC 3484 is correct. It is complian
On Mar 4 2009, Ondřej Surý wrote:
On Wed, Mar 4, 2009 at 6:57 PM, wrote:
[...]
DNSSEC does reorder RRSets within a zone. Which is a new feature.
When we started talking about order of RRSets? This is purely discussion
about order of RRs in RRSet. Order of RRSets in zone is irrelev
my error here - Paul said DNS does no ordering... he did not specify
ordering of what. we now return you to your rant.
--bill
On Wed, Mar 04, 2009 at 07:54:37PM +, Chris Thompson wrote:
> On Mar 4 2009, OndEej SurC= wrote:
>
> >On Wed, Mar 4, 2009 at 6:57 PM, wrote:
> [...]
> >>
On Wed, 4 Mar 2009, Paul Vixie wrote:
> only in the case where the server is depending on rr ordering within
> rrsets, which dns has never guaranteed and which many caches (both rdns
> and stubs) randomize or reorder anyway, and where the server's
> imputation of topology knows about every private
For this section to be useful you needs to be done at break
points. LAN /64, SITE /56 or /48 and ISP /??. Doing it
on every bit boundary is just plain wrong. The intent was
good. The specification was wrong. To make this useful
you need a protocol to d
On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> "in my same /24" or "in my same /16" is a pretty good indicator, though.
Pity that ain't what the spec says.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
_
i disagree. dns-based load balancing is an unfortunate overloading and
should never be done. RFC 3484 is correct as it is.
re:
> It seems that Vista implements RFC 3484 address selection, including the
> requirement to sort IP addresses. This breaks a great deal of operational
> dependence on D
On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie wrote:
> dns-based load balancing is an unfortunate overloading and
> should never be done.
Here I agree.
> RFC 3484 is correct as it is.
Here I don't. The idea behind is good, the implementation is not.
Client would have to know BGP path to DA + D
I've added the ALTO mailing list to this discussion:
What it comes down to is you want "localization", not RFC 3484.
On Mar 4, 2009, at 8:05 AM, Ondřej Surý wrote:
On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie wrote:
dns-based load balancing is an unfortunate overloading and
should never be d
* Tony Finch:
> It seems that Vista implements RFC 3484 address selection, including the
> requirement to sort IP addresses. This breaks a great deal of operational
> dependence on DNS-based load balancing, as well as being based on an
> incorrect understanding of how IP addresses are allocated.
> > i disagree. dns-based load balancing is an unfortunate overloading
> and
> > should never be done. RFC 3484 is correct as it is.
>
> Why is it right for topology-ignorant clients to override topology-
> aware
> DNS servers based on wishful thinking about RIR address allocation
> policies?
Th
On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> neither a client or a server can be guaranteed topology-aware. dns leaves
> ordering deliberately undefined and encourages applications to use their
> own best judgement.
Rule 9 kicks in when the client has no topology information, which is why
it is brok
On Wed, 4 Mar 2009, Paul Vixie wrote:
> i disagree. dns-based load balancing is an unfortunate overloading and
> should never be done. RFC 3484 is correct as it is.
Why is it right for topology-ignorant clients to override topology-aware
DNS servers based on wishful thinking about RIR address a
On Wed, 4 Mar 2009, Florian Weimer wrote:
>
> I assume you are referring to IPv4 address sorting.
It's also wrong to sort IPv6 addresses by longest matching prefix (unless
the match is very long) because IPv6 addresses are also not allocated
according to network topology.
Tony.
--
f.anthony.n.fi
22 matches
Mail list logo
