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
