how to list ALL zones of my master server

Jim Reid jim at rfc1035.com
Mon Sep 30 21:06:00 UTC 2002


>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Kevin> Jim, I haven't seen anyone suggest that all of this
    Kevin> implementation-specific configuration data be crammed into
    Kevin> the NOTIFY packet.

Indeed. However this is the logical next step if NOTIFY was to be
abused like the OP suggested. Why just add the zone and not have some
way of adding the zone-specific configuration info? Ever heard of the
phrase "function creep"?

    Kevin> I really don't understand why people are so hostile to
    Kevin> using NOTIFY as a zone-creation trigger.

Well for starters the NOTIFY protocol was not intended to do such a
thing. If someone wants a DNS provisioning protocol to add/remove
zones or change zone-specific configuration options, why not define
and implement something that was properly developed for that specific
purpose? Why corrupt another protocol that was never intended to
provide that functionality?

    >> And as for the DoS possibilities...

    Kevin> I see this as just another facet of the trust issue, which
    Kevin> you said you were ignoring.

That's why I didn't enumerate them: my remark simply indicated that
there are serious DoS problems with the OP's suggestion. I was also
thinking about a trust problem on the slave server where the name
server process has the ability to read but not change its config file.

    Kevin> If the NOTIFY is unsigned or the signature doesn't verify,
    Kevin> ignore the NOTIFY. How is this a serious DoS possibility?

Flooding the server with duplicated NOTIFYs? Who cares if the
signatures or timestamps don't verify? Just keep the server busy
verifying them: great fun on a single-threaded server.


More information about the bind-users mailing list