Test (ie lab) data has been obtained to show that most Cisco routers (ie
non-GSR) can perform fine grained load balancing. Cisco manuals indicate that
the GSR series routers do fine grained load balancing.
Test (ie lab) data has been obtained to demonstrate that the Anycast Extension
(TCP) does not work in theory or in practice with fine grained, per packet load
balancing.
Root DNS specific operational data will be obtained when more people start
making TCP and large UDP packets and fragments to root servers. There is no
reason (in theory or in practice) to expect that the Anycast Extension can work
in general, or that current lab results won't be experienced.
However, all of the questions about the operational impact of the Anycast
Extension should have been __TESTED__ BEFORE deployment on critical servers such
as root servers. Even if the Anycast Extension worked, ISC would be still be
subject to valid and substantial criticism for deploying it on Root servers
without adequate testing and analysis, and IETF review.
That the Anycast Extension doesn't work in general only adds to the criticism
and the seriousness of the problem.
--Dean
On Fri, 23 Sep 2005, David Conrad wrote:
> Dean,
>
> Could you point to the data (not the theory) by which you have
> determined ISC is mis-operating F and the impact of that mis-operation?
>
> Thanks,
> -drc
>
> On Sep 23, 2005, at 5:06 PM, Dean Anderson wrote:
>
> > ISC's mis-operation of root DNS services and the impact of that mis-
> > operation is
> > plainly a genuine DNS operational issue.
> >
> > --Dean
> >
> > On Fri, 23 Sep 2005, David Kessens wrote:
> >
> >
> >>
> >> Dean,
> >>
> >> You are welcome to post to this list if you have DNS operational
> >> issues to discuss.
> >>
> >> Any issues that you might have with ISC are outside the charter of
> >> this working group and I would like to request you to take them up
> >> privately with ISC.
> >>
> >> Thanks,
> >>
> >> David Kessens
> >> ---
> >>
> >> On Fri, Sep 23, 2005 at 06:09:23PM -0400, Dean Anderson wrote:
> >>
> >>> Harald, you may be right about DNSSEC protecting from this. I
> >>> haven't looked at
> >>> your data, yet. However, you probably aren't about to be very
> >>> well protected by
> >>> DNSSEC, despite the progress of specifications on DNSEXT.
> >>>
> >>> DNSSEC isn't deployable on F-root nor the other anycast'ed*
> >>> roots, nor a lot of
> >>> other anycast'ed non-root servers. DNS servers with the Anycast
> >>> Extension are
> >>> increasingly popular due to suppression of discussion of negative
> >>> aspects of the
> >>> Anycast Extension on forums such as Nanog as recently as May,
> >>> 2005 because only
> >>> information that promotes ISC's view is allowed on Nanog,
> >>> misleading network
> >>> operators about the Anycast Extension. Many root server
> >>> operators accepted
> >>> ISC's assurances as an unofficial IETF liason and deployed
> >>> Anycast Extension on
> >>> production servers and on root servers in violation of RFC
> >>> 2870**. They appear
> >>> not to have understood that they were deploying an untested,
> >>> undocumented, and
> >>> unapproved Anycast Extension.
> >>>
> >>> And despite substantiated criticism on DNSEXT and DNSOP by
> >>> persons including Dan
> >>> Bernstein, Iljitsch van Beijnum, Dean Anderson, and others since
> >>> the 2002 Nanog
> >>> presentation by ISC, ISC has not yet even publicly acknowledged
> >>> the problems
> >>> with the Anycast Extension, and continues to promote the
> >>> extension as completely
> >>> safe. ISC even describes it to prospective customers as
> >>> "uncontroversial",
> >>> despite the controversies on DNSEXT, DNSOP, and Nanog beginning
> >>> after the Nanog
> >>> presentation in 2002.
> >>>
> >>> The Anycast Extension is now proposed to the GROW working group
> >>> some 3 years
> >>> after being described to Nanog as operationally safe and stable.
> >>> At present,
> >>> the Anycast Extension proposal appears to be dead or dying on
> >>> both DNSOP and
> >>> GROW WGs because of evidence that it can't work in general, and
> >>> the specialized
> >>> conditions where it can work are uninteresting to the current
> >>> users such as root
> >>> DNS operators and other DNS operators, and thus uninteresting to
> >>> ISC.
> >>>
> >>> The only reason there are no present complaints with root
> >>> operations is that DNS
> >>> is mostly still stateless small UDP packets, reducing to RFC 1546
> >>> Anycast***,
> >>> which works fine with stateless small UDP packets. And it may
> >>> well be that those
> >>> working on DNSSEC testing comply with the assumptions stated on
> >>> the Anycast
> >>> Extension.
> >>>
> >>> So the question is when will F-root and other roots be able to
> >>> handle TCP and
> >>> large UDP packets from any internet host, including those hosts
> >>> serviced by
> >>> networks that use fine-grained load-splitting as described by
> >>> RFC1812?. When
> >>> will operators be informed of these problems by ISC?
> >>>
> >>> Critics of these problems, particularly Dan Bernstein and Dean
> >>> Anderson, have
> >>> been attacked personally by persons generally associated with ISC
> >>> or friendly to
> >>> ISC with no remedial action by the respective organizations (IETF
> >>> and Nanog) in
> >>> spite of well-documented complaints. Uncontrolled personal
> >>> corruption at the
> >>> IETF and Nanog appears to be preventing actual progress.
> >>>
> >>> --Dean
> >>>
> >>> [* the Anycast Extension
> >>> http://www.ietf.org/internet-drafts/draft-ietf-grow-
> >>> anycast-01.txt doesn't work
> >>> in general because routers are allowed by RFC1812 to do fine-
> >>> grained "load
> >>> splitting" if they wish. Fine-grained load splitting, also known
> >>> as Per Packet
> >>> Load Balancing (PPLB) and other names, prevents Anycast from
> >>> being used with TCP
> >>> or large UDP packets and fragments. The draft documents a number
> >>> of assumptions
> >>> that have to be true in order for the Anycast Extension to work.
> >>> These
> >>> assumptions aren't true in general.]
> >>>
> >>> [** RFC 2870 section 2.6 specifies that Root DNS server operators
> >>> must operate
> >>> servers that respond to _any_ Internet host. That is, Root
> >>> nameservers that
> >>> only work for say, 95% of the world are not acceptable.
> >>>
> >>> 2.6 Root servers MUST answer queries from any internet host,
> >>> i.e. may
> >>> not block root name resolution from any valid IP address,
> >>> except
> >>> in the case of queries causing operational problems, in which
> >>> case the blocking SHOULD last only as long as the problem,
> >>> and be
> >>> as specific as reasonably possible.
> >>> ]
> >>>
> >>> [*** RFC1546 notes that:
> >>>
> >>> It is important to remember that anycasting is a stateless
> >>> service.
> >>> An internetwork has no obligation to deliver two successive
> >>> packets
> >>> sent to the same anycast address to the same host.
> >>> ]
> >>>
> >>>
> >>> On Fri, 23 Sep 2005, Harald Tveit Alvestrand wrote:
> >>>
> >>>
> >>>> I'm not sure this is on-topic for this list, but may be an
> >>>> illustrative
> >>>> story....
> >>>>
> >>>> I had some percentage of the queries for a domain I use hijacked
> >>>> by an
> >>>> attacker last week. The technique involved was interesting to me.
> >>>>
> >>>> Moral: Know your secondaries, and what happens to them..... if
> >>>> someone
> >>>> steals your secondary's NAME, you're toast.
> >>>>
> >>>> If I'd had DNSSEC, and the people looking it up had had DNSSEC,
> >>>> this would
> >>>> have been a detectable DOS attack, not a stealth redirection
> >>>> attack.
> >>>>
> >>>> Detailed writeup: http://www.alvestrand.no/subjects/dns-
> >>>> attack-1.html
> >>>>
> >>>> Harald
> >>>>
> >>>>
> >>>> .
> >>>> dnsop
> >>>> resources:_____________________________________________________
> >>>> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> >>>> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/
> >>>> index.html
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Av8 Internet Prepared to pay a premium for better service?
> >>> www.av8.net faster, more reliable, better service
> >>> 617 344 9000
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> .
> >>> dnsop
> >>> resources:_____________________________________________________
> >>> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> >>> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/
> >>> index.html
> >>>
> >>
> >> David Kessens
> >> ---
> >>
> >>
> >>
> >
> > --
> > Av8 Internet Prepared to pay a premium for better service?
> > www.av8.net faster, more reliable, better service
> > 617 344 9000
> >
> >
> > .
> > dnsop resources:_____________________________________________________
> > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
> >
> >
>
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
