Date: Tue, 2 Jul 2002 00:33:44 -0400 (EDT)
From: Tim Gladding <[email protected]>
To: [email protected]Subject: BIND 9.2.1 patch, multiple RR's for singleton types.
---1463811840-1992755250-1025584157=:3589
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email protected]>
With the release of the libbind buffer overflow a number of people have
suggested loading a copy of BIND locally and pointing your local resolver
at just that name server, providing a sanity check of all incoming DNS
traffic. For the most part this will work, however, for it to work
effectively you must be using BIND 9.x because BIND 8.x does not
reconstruct all responses before forwarding them on.
For more information on the libbind buffer overflow bug please see:
http://www.cert.org/advisories/CA-2002-19.html
However, your situation may preclude you from running BIND 9 either locally
or at the site level. One such situation would be that you are already
running BIND 8 and you have zones loaded that will not load in to BIND 9
because they have multiple resource records assigned to one singleton data
type. For example, an A record pointing to a list of CNAMES:
fuzzy IN CNAME www.snuggie.com.
IN CNAME www.r-9.net.
Normally BIND 9 would reject this as part of a zone.
To overcome this particular problem I have produced the attached patch(1)
to BIND 9.2.1 which, when applied, will again allow you to use multiple
CNAMEs etc. on one RR. This patch is the equivalent of the 'multiple-cnames
yes;' option in bind 8.x.
WARNING!! Although I am running this patch in a production environment
I cannot guarantee that this patch will work for you. Please be sure to
double check the functionality of this patch before employing it in any
environment!!
--
Tim Gladding
---1463811840-1992755250-1025584157=:3589
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="rdataslab.c.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <[email protected]>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="rdataslab.c.patch"
LS0tIGJpbmQtOS4yLjEvbGliL2Rucy9yZGF0YXNsYWIuYy5vcmlnCVR1ZSBK
YW4gIDkgMTY6NTE6MjUgMjAwMQ0KKysrIGJpbmQtOS4yLjEvbGliL2Rucy9y
ZGF0YXNsYWIuYwlNb24gSnVsICAxIDIyOjQ5OjE5IDIwMDINCkBAIC0xMTEs
MTQgKzExMSwxNCBAQA0KIAkvKg0KIAkgKiBFbnN1cmUgdGhhdCBzaW5nbGV0
b24gdHlwZXMgYXJlIGFjdHVhbGx5IHNpbmdsZXRvbnMuDQogCSAqLw0KLQlp
ZiAobml0ZW1zID4gMSAmJiBkbnNfcmRhdGF0eXBlX2lzc2luZ2xldG9uKHJk
YXRhc2V0LT50eXBlKSkgew0KKwkvKiBpZiAobml0ZW1zID4gMSAmJiBkbnNf
cmRhdGF0eXBlX2lzc2luZ2xldG9uKHJkYXRhc2V0LT50eXBlKSkgeyAqLw0K
IAkJLyoNCiAJCSAqIFdlIGhhdmUgYSBzaW5nbGV0b24gdHlwZSwgYnV0IHRo
ZXJlJ3MgbW9yZSB0aGFuIG9uZQ0KIAkJICogUlIgaW4gdGhlIHJkYXRhc2V0
Lg0KIAkJICovDQotCQlyZXN1bHQgPSBETlNfUl9TSU5HTEVUT047DQorCQkv
KiByZXN1bHQgPSBETlNfUl9TSU5HTEVUT047DQogCQlnb3RvIGZyZWVfcmRh
dGFzOw0KLQl9DQorCX0gKi8NCiANCiAJLyoNCiAJICogQWxsb2NhdGUgdGhl
IG1lbW9yeSwgc2V0IHVwIGEgYnVmZmVyLCBzdGFydCBjb3B5aW5nIGluDQpA
QCAtMzEwLDEzICszMTAsMTMgQEANCiAJLyoNCiAJICogRW5zdXJlIHRoYXQg
c2luZ2xldG9uIHR5cGVzIGFyZSBhY3R1YWxseSBzaW5nbGV0b25zLg0KIAkg
Ki8NCi0JaWYgKHRjb3VudCA+IDEgJiYgZG5zX3JkYXRhdHlwZV9pc3Npbmds
ZXRvbih0eXBlKSkgew0KKwkvKiBpZiAodGNvdW50ID4gMSAmJiBkbnNfcmRh
dGF0eXBlX2lzc2luZ2xldG9uKHR5cGUpKSB7ICovDQogCQkvKg0KIAkJICog
V2UgaGF2ZSBhIHNpbmdsZXRvbiB0eXBlLCBidXQgdGhlcmUncyBtb3JlIHRo
YW4gb25lDQogCQkgKiBSUiBpbiB0aGUgcmRhdGFzZXQuDQogCQkgKi8NCi0J
CXJldHVybiAoRE5TX1JfU0lOR0xFVE9OKTsNCi0JfQ0KKwkJLyogcmV0dXJu
IChETlNfUl9TSU5HTEVUT04pOw0KKwl9ICovDQogDQogCS8qDQogCSAqIENv
cHkgdGhlIHJlc2VydmVkIGFyZWEgZnJvbSB0aGUgbmV3IHNsYWIuDQo=
---1463811840-1992755250-1025584157=:3589--
