There is a much simpler way to get around all these problems:
Delegate these zones to 127.0.0.1.
This has the following benefits:
-- Operators with incorrectly configured recursors will have an
opportunity to get a 'recursion to self' error, which won't make them
think they are being attacked, and which will alert them to the problem
of misconfiguration.
-- If they don't get an error, at least they get a cacheable response
that will remove load from the IN-ADDR servers. The removal of this load
is the purpose of AS112. Obviously, that solution to the problem is
expensive, and has its own drawbacks.
-- Delegation to 127.0.0.1 is cheap and has no drawbacks.
-- In addition, one also won't have a continuing security issue of
securing these particular logs of recursors.
-- Also, one avoids the contentious issue of what the correct response
should be from these servers. Eliminating the servers eliminates the
question about what the correct response should be.
-- This also eliminates the problem of unreliable Anycast TCP, since the
delegation to 127.0.0.1 works for both TCP and UDP, while the Anycast
solution doesn't reliably work for TCP or for DNSSEC UDP.
--Dean
On Tue, 20 Mar 2007, David W. Hankins wrote:
> In section 6,
>
> service (DoS) attack. In some case the source ports used by
>
> I suggest the author intended either 'in some cases' or 'in one case',
> and I would like to submit my claim at this time for the "Joe Abley's
> Typographical Error of the Year" trophy.
>
>
> I note that the document has failed to capture the angst and
> bitterness of the authors' cumulative lifetimes spent answering
> phonecalls from people who think as112 is 'haxing their base'.
>
> This is a feature.
>
>
> I am concerned that the document as read is appropriate for an
> IETF audience, rather than the target audience (people who think
> they are under attack). The ~16 year old voice-cracking operator
> of a network of several hundred desktops in Dallas I spoke with
> most recently would not get past page 1 before being distracted, and
> most certainly would not be able to read the 4 options described in
> section 7 and understand that the draft is actually recommending
> only one of them, and not the first one.
>
> Or maybe I don't give him enough credit.
>
> Anyway, the point is I'm not really sure this is something I
> would have used to explain the situation when I did field those
> phonecalls. It's quicker to give the short explanation, using
> small words, than to field a second phonecall later. I certainly
> would have been able to use this as additional information to
> support may 'claims' that I am not a 'hax', but would still have
> done the usual "here's what's wrong, and here's how to fix it"
> spiel.
>
> Honestly, the biggest timesink in these calls is just getting
> the caller to stop talking long enough to answer.
>
>
> One major point about prisoner.iana.org (covered in the other
> as112-ops document) is that people who complain about
> prisoner.iana.org are sending what is coloquially referred
> to (among the target audience) as 'updates', not 'queries'.
>
> I think this point is missing from this document (or I missed
> it), and without it I don't think the target audience can be
> convinced that they are doing something to cause the responses
> from prisoner.
>
>
> But, there is nothing factually wrong in this document, and my
> opinion of it is positive overall.
>
> I recognize that the above are matters of personal preference or
> taste, and would not be moved to object if the authors disagree.
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
