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
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
