[Dnsmasq-discuss] Large AXFR through dnsmasq causes dig to hang with partial results

[Connor Bell]

Hi everyone,

I've had a strange issue I've been trying to resolve over the past few days where dnsmasq seems to only be allowing part of a zone transfer through, causing dig to hang.

I opened a Stackoverflow post to track it with most of the information I've found.
https://serverfault.com/questions/933956/large-axfr-through-dnsmasq-causes-dig-to-hang-with-partial-results

With a tcpdump comparing a request with dnsmasq acting as forwarder and without, I can see in both cases that the upstream bind server replies with two packets, 2521 bytes and 189 bytes. When digging dnsmasq, the first packet is read out correctly and dig sits and waits for the second packet, which for some reason it never seems to receive.

When digging bind directly, dig receives both packets and reads out the answer correctly. I'm guessing I'm hitting a packet size limit causing it to split the response, but why does dig not receive the second packet from dnsmasq?

Kind regards,
Connor Bell

[Simon Kelley]

Post by Connor Bell
Hi everyone,
 
I’ve had a strange issue I’ve been trying to resolve over the past few
days where dnsmasq seems to only be allowing part of a zone transfer
through, causing dig to hang.
 
I opened a Stackoverflow post to track it with most of the information
I’ve found.
https://serverfault.com/questions/933956/large-axfr-through-dnsmasq-causes-dig-to-hang-with-partial-results
 
With a tcpdump comparing a request with dnsmasq acting as forwarder and
without, I can see in both cases that the upstream bind server replies
with two packets, 2521 bytes and 189 bytes. When digging dnsmasq, the
first packet is read out correctly and dig sits and waits for the second
packet, which for some reason it never seems to receive.
 

A single packet of 2521 bytes doesn't seem to correspond with the
transfer hanging after 700 lines - it's pretty difficult to get 700
lines of output from one 2500 bytes packet, I think.

I suspect that what's happening is that the zone transfer exceeds 65536
bytes,
which is the limit for a single mesage over TCP. AXFR have special-case
continuation methods to push the transfer into multiple messages. (if
the message doesn't end with a repeat of the SOA record at the start of
the transfer, then expect further messages)

Dnsmasq, forwarding replies in TCP mode, was never really designed with
AXFR in mind, and doesn't implement this function.

Does it really make sense to do AXFR through dnsmasq: surely you'd talk
directly to the authoritative sever for the domain of interest?


Cheers,

Simon.

Post by Connor Bell
When digging bind directly, dig receives both packets and reads out the
answer correctly. I’m guessing I’m hitting a packet size limit causing
it to split the response, but why does dig not receive the second packet
from dnsmasq?
 
Kind regards,
Connor Bell
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Connor Bell]

Thank you very much for your response, Simon.

That makes sense, and confirms my assumption (and fills in the bits I was missing!).
Your suggestion to talk directly to the authoritative server is definitely correct, I was just trying not modify our legacy systems too much. We have a few old scripts that everything relies on that I was reluctant to change, but it looks like I'll be putting in a change request.

Thank you again,

Kind regards,

Connor Bell

-----Original Message-----
From: Dnsmasq-discuss <dnsmasq-discuss-***@lists.thekelleys.org.uk> On Behalf Of Simon Kelley
Sent: 10 October 2018 21:49
To: dnsmasq-***@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Large AXFR through dnsmasq causes dig to hang with partial results

Post by Connor Bell
Hi everyone,
 
I've had a strange issue I've been trying to resolve over the past few
days where dnsmasq seems to only be allowing part of a zone transfer
through, causing dig to hang.
 
I opened a Stackoverflow post to track it with most of the information I've found.
https://urldefense.proofpoint.com/v2/url?u=https-3A__serverfault.com_q
uestions_933956_large-2Daxfr-2Dthrough-2Ddnsmasq-2Dcauses-2Ddig-2Dto-2
Dhang-2Dwith-2Dpartial-2Dresults&d=DwIF-g&c=ObqWq9831a7badpzAhIKIA&r=i
e76wBjeuPtjJtmSTY59J2xyS957_vFuhX0BksPJddk&m=odIo70ogaqgQDZRdMWd5ZVLvD
a_kjBhxdCpj0iLtmhc&s=sWxCQ_USCCAuGIgi7rjNnRJDSY_YmtwBgr0y7tRk_0A&e=
 
With a tcpdump comparing a request with dnsmasq acting as forwarder
and without, I can see in both cases that the upstream bind server
replies with two packets, 2521 bytes and 189 bytes. When digging
dnsmasq, the first packet is read out correctly and dig sits and waits
for the second packet, which for some reason it never seems to receive.
 

A single packet of 2521 bytes doesn't seem to correspond with the transfer hanging after 700 lines - it's pretty difficult to get 700 lines of output from one 2500 bytes packet, I think.

I suspect that what's happening is that the zone transfer exceeds 65536 bytes, which is the limit for a single mesage over TCP. AXFR have special-case continuation methods to push the transfer into multiple messages. (if the message doesn't end with a repeat of the SOA record at the start of the transfer, then expect further messages)

Dnsmasq, forwarding replies in TCP mode, was never really designed with AXFR in mind, and doesn't implement this function.

Does it really make sense to do AXFR through dnsmasq: surely you'd talk directly to the authoritative sever for the domain of interest?


Cheers,

Simon.

Post by Connor Bell
When digging bind directly, dig receives both packets and reads out
the answer correctly. I'm guessing I'm hitting a packet size limit
causing it to split the response, but why does dig not receive the
second packet from dnsmasq?
 
Kind regards,
Connor Bell
_______________________________________________
Dnsmasq-discuss mailing list
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.thekelleys.o
rg.uk_mailman_listinfo_dnsmasq-2Ddiscuss&d=DwIF-g&c=ObqWq9831a7badpzAh
IKIA&r=ie76wBjeuPtjJtmSTY59J2xyS957_vFuhX0BksPJddk&m=odIo70ogaqgQDZRdM
Wd5ZVLvDa_kjBhxdCpj0iLtmhc&s=cTRw319Gyw5OyI9CO6ig5v0DvtRJnOUaCsQXkdp2D
k8&e=