Designate does not enforce the DNS protocol limit concerning record set sizes when adding records for a domain name. The protocol limit is slightly less than 2**16 bytes because of some data that must accompany any record set, as part of the zone file transfer.
As a result, the rendering loop in desginate-mdns can does not make progress because the problematic record set at rrsets[i] will never fit (per designate/mdns/handler.py:RequestHandler._handle_axfr):
# Render the results, yielding a packet after each TooBig exception.
i, renderer = 0, None
while i < len(rrsets):
# No renderer? Build one
if renderer is None:
renderer = dns.renderer.Renderer(
response.id, response.flags, max_message_size)
…
try:
renderer.add_rrset(dns.renderer.ANSWER, rrsets[i])
i += 1
except dns.exception.TooBig:
renderer.write_header()
if request.had_tsig:
…
yield renderer
renderer = None
When this happens, designate-mdns will keep sending SOA records over and over again:
sendto(37, "\0\35<{\204\0\0\1\0\0\0\0\0\0\7example\3org\0\0\374\0\1", 31, 0, NULL, 0) = 31
sendto(37, "\0\35<{\204\0\0\1\0\0\0\0\0\0\7example\3org\0\0\374\0\1", 31, 0, NULL, 0) = 31
sendto(37, "\0\35<{\204\0\0\1\0\0\0\0\0\0\7example\3org\0\0\374\0\1", 31, 0, NULL, 0) = 31
Here is how I triggered this. I created a domain example.org:
+--------------------------------------+--------------+------------+
| id | name | serial |
+--------------------------------------+--------------+------------+
| ded903fc-60ef-4b5e-a37c-f3181baf9516 | example.org. | 1435315435 |
+--------------------------------------+--------------+------------+
Then I added several hundred NS records for the same subdomain, using this shell command:
for x in {1..304} ; do
designate record-create --name 'sub.example.org.' --type NS --data \
$x'.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.'$x. \
ded903fc-60ef-4b5e-a37c-f3181baf9516
done
In the tested configuration, PowerDNS will attempt a zone file transfer, and trigger the bug. Because it keeps receiving data, it does not seem it will ever run into a timeout (and if it does, it will try again).
Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1236014
Attached a patch providing an initial candidate fix, based off master.
Tests are passing, but this has not yet been validated with BIND/PowerDNS etc