On Friday, November 14, 2014, Wolfgang Nagele (AusRegistry) <
wolfgang.nag...@ausregistry.com.au> wrote:
> Hi,
>
> AS112 absolutely proves that unowned anycast can work at scale; that's
> not
> my concern. But if my neighbor announces a route to the AS112 addresses,
> and then misconfigures a server, fills it with lies, or logs all my
> queries, the practical effect on me is pretty small: the worst case
> scenario I can think of offhand is that somebody gleans information about
> my internal network topology that probably wouldn't have been difficult to
> guess anyway.
>
> One of my biggest concerns about the current proposal is that it seems
> to suggest that AS112 works.
>
Actually, AS112 works just fine....
.
.
.
... except when it doesn't.
It is very hard to discover who is answering AS112 queries and go poke them
when things go awry - luckily, the primary effect of a "bad" AS112 node is
often (usually?) just a reduction in the AS112 benefit - it doesn't
actually break you, it just means you don't get the win.
The very fact that anycast works so well means that finding all the AS112
nodes and contacting them, to either delegate new space to them, or remove
existing delegations lead to the omniscient-as112 draft, and
then draft-ietf-dnsop-as112-dname ("AS112 Redirection using DNAME"), which,
IIRC finished IETF LC is waiting for us to incorporate a comment or two.
> I would like to find some definition of “works” and how we come to that
> conclusion. In my experience there are AS112 nodes out there that are
> misconfigured in many ways (RIPE Atlas be your friend). Returning
> SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC
> in this proposal, malfunction is likely to occur still and can be just as
> bad.
>
Well, luckily DNSSEC is ubiquitous at this point...
> In the current system this issue is lessened due to the many different
> operators.
> Within a given enterprise or ISP that would have limited impact and one
> could just point the finger at them and not care (although I don’t agree
> with that either). However route leaks are going to occur as they have in
> the past (no-export stripping happens by accident) and will start to have
> impact on users outside of that admin/routing domain. Assuming that local
> routes are always the routes that are chosen first is a flawed assumption.
> Routing is integral to this proposal and cannot be disregarded if you wanna
> find a workable solution.
>
> From a TLD operator perspective I think it’s a huge step backwards that
> we will loose our update propagation assurance. Will I have to rely on the
> RRSIG expiry as my worst case scenario for a zone update to be fully
> propagated? With the sort of requirements that are put on TLD operators and
> DNS operators these days that sounds completely unacceptable path to me.
> It’s very different from AS112 where there is are simple zones that are
> configured as master and then remain that way.
>
> I support the expansion of root server deployments. In my opinion this
> can be fully achieved in the given framework and ICANN as the operator of
> L-root has shown what can be done in a very short period of time. The
> discussion should be about the standards of operation that each root server
> operator is held to these days. There should be no question that some of
> the current root server operators muscle a way more substantial deployment
> than others. If it’s politically too sensitive/hard to establish any level
> of quality with the given root server operators, the addition of other root
> server operators within the current protocol limitations could be used to
> hold them to a certain standard. For the overall system to function well
> this would suffice. This is very similar what was done as part of the new
> gTLD program from ICANN where a whole set of requirements was added that
> didn’t exist before (IPv6, DNSSEC, etc.).
>
> In closing, this draft proposes a solution to a problem that hasn’t been
> quantified and has no measure of success. Personally I think that’s bad
> practice.
>
> Regards,
> Wolfgang
>
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
