Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

From: Paul Vixie <vixie at isc.org>
To: Ondřej Surý <ondrej.sury at nic.cz>
Cc: namedroppers at ops.ietf.org, ietf at ietf.org
Date: Wed, 04 Mar 2009 20:24:33 +0000
In-reply-to: Your message of "Wed, 04 Mar 2009 17:05:29 +0100." <e90946380903040805v15ad9e7dv92491667cd1f7656 at mail.gmail.com>
References: <alpine.LSU.2.00.0903041400220.8701 at hermes-2.csi.cam.ac.uk> <20563.1236179832 at nsa.vix.com> <e90946380903040805v15ad9e7dv92491667cd1f7656 at mail.gmail.com>

>      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 case, all other cases are based on pure
>    luck.

random tends to be best, honestly.  but if there's an alternative that's
in the same /24 or /16 with you then this will be a useful optimization.

References:
- RFC 3484 section 6 rule 9 causing more operational problems
  - From: Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
  - From: Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
  - From: Ondřej Surý

Prev by Date: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Next by Date: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Previous by thread: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Next by thread: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Index(es):
- Date
- Thread

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.