Bug 251336
Summary: | dynamic update - deleting a srv record - bind asserts name.c:1695: INSIST(count <= 63) failed and aborts | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vinay Y S <vinay> | ||||
Component: | bind | Assignee: | Adam Tkac <atkac> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 7 | CC: | bressers, ovasik | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 9.4.1-9.P1.fc7 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-08-15 19:46:34 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Vinay Y S
2007-08-08 13:53:30 UTC
Created attachment 160901 [details]
bind-abort-bugreport.tgz - has config files, and python code that can repro the issue.
Let me know if you need any help/info in reproducing the bug. The difference between python-dns update and nsupdate cmdline tool is that nsupdate does with ANY and python-dns does with NONE rrtype. Cursory examination of bind code tells me that they are different code paths. Submitted the same bug report to bind9-bugs. The ticket there has been assigned an ID of [ISC-Bugs #17074]. This bug is reproduced in BIND 9.5.0a6 too. The log message seen is: name.c:1695: INSIST(count <= 63) failed exiting (due to assertion failure) Same as earlier. I tried the same query with nsupdate by using the following line: update delete _store._net.user.dummy.com. 300 SRV 0 0 8091 dbserver.dummy.com. Server didn't assert and quit. The update worked. So, captured the transaction using ethereal and here's the diff: diff -u nsupdate.log dnspython.log --- nsupdate.log 2007-08-10 16:57:22.000000000 +0530 +++ dnspython.log 2007-08-10 16:58:03.000000000 +0530 @@ -1,6 +1,6 @@ Domain Name System (query) - Length: 82 - Transaction ID: 0x9a27 + Length: 73 + Transaction ID: 0xeefd Flags: 0x2800 (Dynamic update) 0... .... .... .... = Response: Message is a query .010 1... .... .... = Opcode: Dynamic update (5) @@ -23,7 +23,7 @@ Type: SRV (Service location) Class: NONE (0x00fe) Time to live: 0 time - Data length: 26 + Data length: 17 Priority: 0 Weight: 0 Port: 8091 As you can see the Data length is different. I don't know which is correct. But in any case, the server shouldn't terminate if the request is bad. Hope this helps. Adam, have you started working on this issue? If you can confirm the problem and give a hint as to if it is in bind's nsupdate or the dnspython it would be helpful. (There is problem in bind server for sure as a crash can be caused by a network input). If the problem is in dnspython, I would like to raise it on the dnspython forum. But that would mean this problem with bind server would become public. Would that be ok? I've started doing on this. Please don't put this to any forum yet. It looks that dnspython sends some corrupted data. This issue also have to be discussed in upstream before we could mark this one as public. Thanks, Adam Problem is that named can't handle non-absolute domain names in "Target" label of update section. Let me discuss how solve this problem in upstream Btw I don't think this will be marked as security issue because affected query has to come from trusted server/user. But please still don't tell about this on any public forum I don't think dnspython is sending a non absolute domain name in Target label. See the ethereal capture here: Domain Name System (query) Length: 73 Transaction ID: 0xeefd Flags: 0x2800 (Dynamic update) 0... .... .... .... = Response: Message is a query .010 1... .... .... = Opcode: Dynamic update (5) .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Zones: 1 Prerequisites: 0 Updates: 1 Additional RRs: 0 Zone dummy.com: type SOA, class IN Name: dummy.com Type: SOA (Start of zone of authority) Class: IN (0x0001) Updates _store._net.user.dummy.com: type SRV, class NONE, priority 0, weight 0, port 8091, target dbserver.dummy.com Name: _store._net.user.dummy.com Type: SRV (Service location) Class: NONE (0x00fe) Time to live: 0 time Data length: 17 Priority: 0 Weight: 0 Port: 8091 Target: dbserver.dummy.com The domain is a fully qualified domain name. But, here, the "Data length" is 17. Whereas for the same query from nsupdate, the ethereal capture is like this: Domain Name System (query) Length: 82 Transaction ID: 0x9a27 Flags: 0x2800 (Dynamic update) 0... .... .... .... = Response: Message is a query .010 1... .... .... = Opcode: Dynamic update (5) .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Zones: 1 Prerequisites: 0 Updates: 1 Additional RRs: 0 Zone dummy.com: type SOA, class IN Name: dummy.com Type: SOA (Start of zone of authority) Class: IN (0x0001) Updates _store._net.user.dummy.com: type SRV, class NONE, priority 0, weight 0, port 8091, target dbserver.dummy.com Name: _store._net.user.dummy.com Type: SRV (Service location) Class: NONE (0x00fe) Time to live: 0 time Data length: 26 Priority: 0 Weight: 0 Port: 8091 Target: dbserver.dummy.com Here the "Data length" is 26. Everything else is same. The assert happens only in first case and not in second case. So, I expect one of the above lengths (mostly the one from dnspython) to be wrong. What exactly utility you used for capture packet? I've used dnscap (this shows fine-grained output, only in rawhide). If you analyze update query from python-dns it's not fully qualified domain name Adam I used tshark (tethereal). tshark -i lo -V Can I get dnscap on Fedora 7? I tried another experiment. With nsupdate I ran the following: server 127.0.0.1 zone dummy.com. update delete _store._net.user.dummy.com. 300 SRV 0 0 8091 dbserver send As you notice the target isn't fqdn. But this works. The packets captured from the ethereal also confirm the same. But the data lengths are different again. This time it is just off by 1. So, I still feel that it is something to do with the data length. What is the definition of data length expected by Bind? Hi Adam, Bug #17074 at isc.org is marked as resolved by Mark Andrews. Do you agree? I didn't quite get what the resolution is. If I apply that patch given to message.c, will Bind no more assert for the same request? Also, what should we communicate to dnspython upstream? I assume there is a bug in there too? Thanks, Hi, please see http://people.redhat.com/atkac/bind/ . There's patched bind (9.4.1-9.P1.fc7) and also dnscap if you're interested. In the end python-dns sends correct query. This will be marked as public later today because upstream don't think this is security sensitive. Update will be avaliable very soon Adam Agreed, not security issue. Opening bug now upstream have dealt with this. bind-9.4.1-9.P1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. Thanks a lot! Verified the package with the dnspython code. It works well. |