Problem with 2 named's running on one Linux box.

Kevin Darcy kcd at daimlerchrysler.com
Wed Dec 15 23:05:40 UTC 1999


Steve Cooper wrote:

> Here is our situation:
>
> We have one Red Hat 6.1 Linux box running both an internal name server
> (on port 53) and and external name server (on port 5353), running a
> current version of Bind 8.X.  The Internic shows our two name servers as
> NS's belonging to our ISP.  These two boxes are set up as slaves,
> pointing to our Linux box, port 5353, as the master.  Our Cisco router
> is blocking in-coming port 53 requests to the Linux box, but allowing
> in-coming port 5353 requests from our ISP's systems.
>
> Our ISP claims that this will not work.  They say that zone transfers
> will occur over port 5353, but SOA requests will still come in (or try
> to) over port 53 and this is not configurable.  So, the slave servers
> are currently unable to see if the serial number has changed, so they
> never initiate a zone transfer.
>
> Is this correct?  Do we have to open port 53 in the Cisco to allow this
> to work?  If so, how do we allow SOA questions, but not general NS
> questions on port 53?

Your ISP is correct, to the best of my knowledge. The SOA serial-number
check is just a regular query (albeit iterative), so it'll use the regular
query destination port, 53.

Why not just configure your external nameserver instance (or your Cisco) to
only accept queries from your ISP's servers? You shouldn't be getting any
queries other than serial-number checks and zone transfers anyway, since
they are authoritative for the zone. I'm not familiar with Cisco packet
filtering -- I imagine with the proper bit-value-matching at the proper
packet offsets, it would be possible to distinguish SOA queries from other
kinds of DNS queries -- but I doubt it would be worth the hassle and
possible performance degradation.

If you're worried about the ISP's servers querying *other* zones besides
the ones they slave, remember that the allow-query option can be specified
on a per-zone basis.


- Kevin




More information about the bind-users mailing list