Zone refresh fails due to cached server. how to use different port

[Kevin Darcy]

Michael A. Hess wrote:

>Greetings,
>
>My DNS is located behind a firewall. Specifically a Dlink 614+ router.
>It works find as a DNS and as a Master but there is a problem as a
>slave. My DNS acts as a slave for several domains. However Zone
>transfers fail.
>
>The reason is that the Dlink rounter has a caching server embedded
>that traps any DNS requests attempting to go out of the network. This
>only applies to UDP requests. It doesn't matter if you specifically
>ask to retrieve the information from a DNS outside of your network or
>not. The router intercepts any DNS request an processes it before
>actually recursing the request out to the DNS server you specify. The
>result is that my router always responds to any of my Zone transfer
>requests which isn't authoritative so my zone updates fail.
>
It's a shame D-Link doesn't have an option to turn its "DNS proxy" off, 
limit its operation by source and/or destination address, or at least 
provide a checkbox in the GUI which says "only proxy DNS queries which 
are sent to the nameservers configured via DHCP, and leave all other DNS 
queries alone"...

>Question:
>
>I have been reading the Bind 9 docs trying to understand if it is
>possible to get the DNS to do a refresh request on a different port
>other then 53. I still need the server to listen and respond on 53 I
>just want the zone transfers done on a different port. 
>
According to the BIND 9 documentation, you can set a *source* port 
number for zone transfers, but not a destination port. I suppose it 
would be kind of neat to be able to set this on a server-by-server 
basis, e.g. in a "server" statement, but currently BIND does not appear 
to support that.

>If that is not
>possible can the zone transfer be setup to be done over TCP instead of
>UDP? TCP requests do respond with a flag of aa since the router is
>only trapping UPD 53 requests.
>
Well the zone transfers _per_se_ would already use TCP, but the 
transaction probably doesn't get that far since the SOA response, being 
non-authoritative, would be rejected.

Frankly, I don't see how you can get a slave working behind a device 
like this, short of resorting to non-standards-defined replication 
methods, such as getting the master to rsync the zone file to your box 
over ssh...

                                                                         
                                                   - Kevin