Re: Slaves or Forwarders?
Baird, Josh wrote: > > In the past, when I have had a requirement to bring a slave zone into > our environment; I created a slave zone on my master(s) (defining the > external nameserver as a master) and then created slave zones on my > slaves using *my* master as a master (not the master outside of my > environment). > Is this method of 'sub-slaves' considered an acceptable practice? Yes. (The new EDNS EXPIRE feature makes it a bit safer too.) > Some folks also like to use forwarders if they don't have the capability > to slave the zone. In this scenario, I would have to create a 'forward' > zone on each of my caching servers that forwards requests for 'xyz.com' > to the up-stream nameserver authoritative for the zone. Be careful doing that. The target forwarders have to be recursive servers. This matters if there is a delegated subdomain; if you are forwarding to an authoritative-only server which returns a referral, BIND will be upset that it did not get the final answer it expected. > I would think that slaving the zone would be the preferred method, since > my master/slaves could still serve the zone if the up-stream/forwarder > becomes unreachable (until my slave expires). Yes, slaving can be more robust. But forwarding can be simpler. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly 6 to gale 8 in east, otherwise northerly or northeasterly 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in east. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves or Forwarders?
>From an InfoSec standpoint, of course one would prefer to use cryptographic >methods of securing DNS data, but, in the absence of that, slaving could, >arguably, be considered more secure than forwarding, in the sense that >forwarding usually generates more network transactions, over time, for any >given resolution of any given name, and thus more chances for a bad guy to >successfully spoof a response and have that forged answer be cached. One could also eke out a small measure of extra security (again, if cryptographic methods are for some reason unavailable) by turning off IXFR and thus causing all zone transfers to occur with AXFR, which is TCP-based and thus presumably harder to spoof. But, that's a heavy price to pay for a small increment of extra security. Better to go for crypto, at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), by implementing (as many have) an out-of-band method of replicating zone data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN tunnels) or by securing *all* communication between nameserver instances (e.g. IPSEC tunnels). - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch Sent: Tuesday, August 23, 2016 11:00 AM To: Baird, Josh Cc: bind-users@lists.isc.org Subject: Re: Slaves or Forwarders? Baird, Josh wrote: > > In the past, when I have had a requirement to bring a slave zone into > our environment; I created a slave zone on my master(s) (defining the > external nameserver as a master) and then created slave zones on my > slaves using *my* master as a master (not the master outside of my > environment). > Is this method of 'sub-slaves' considered an acceptable practice? Yes. (The new EDNS EXPIRE feature makes it a bit safer too.) > Some folks also like to use forwarders if they don't have the > capability to slave the zone. In this scenario, I would have to create a > 'forward' > zone on each of my caching servers that forwards requests for 'xyz.com' > to the up-stream nameserver authoritative for the zone. Be careful doing that. The target forwarders have to be recursive servers. This matters if there is a delegated subdomain; if you are forwarding to an authoritative-only server which returns a referral, BIND will be upset that it did not get the final answer it expected. > I would think that slaving the zone would be the preferred method, > since my master/slaves could still serve the zone if the > up-stream/forwarder becomes unreachable (until my slave expires). Yes, slaving can be more robust. But forwarding can be simpler. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly 6 to gale 8 in east, otherwise northerly or northeasterly 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in east. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves or Forwarders?
In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > From an InfoSec standpoint, of course one would prefer to use > cryptographic methods of securing DNS data, but, in the absence of that, > slaving could, arguably, be considered more secure than forwarding, in > the sense that forwarding usually generates more network transactions, > over time, for any given resolution of any given name, and thus more > chances for a bad guy to successfully spoof a response and have that > forged answer be cached. > > One could also eke out a small measure of extra security (again, if > cryptographic methods are for some reason unavailable) by turning off > IXFR and thus causing all zone transfers to occur with AXFR, which is > TCP-based and thus presumably harder to spoof. But, that's a heavy price > to pay for a small increment of extra security. Better to go for crypto, > at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), > by implementing (as many have) an out-of-band method of replicating zone > data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN > tunnels) or by securing *all* communicati on between nameserver instances > (e.g. IPSEC tunnels). named only accepts IXFR over TCP. While the protocol supports sending deltas with IXFR/UDP named does not use that part of the protocol. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves or Forwarders?
Darcy Kevin (FCA) wrote: > From an InfoSec standpoint, of course one would prefer to use > cryptographic methods of securing DNS data, Yes, use TSIG for zone transfers. You can also use it for forwarding. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Fair Isle, North Faeroes: Variable becoming southerly 3 or 4. Slight or moderate. Rain with fog patches, becoming fair. Moderate or very poor, becoming mainly good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves or Forwarders?
In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: From an InfoSec standpoint, of course one would prefer to use cryptographic methods of securing DNS data, but, in the absence of that, slaving could, arguably, be considered more secure than forwarding, in the sense that forwarding usually generates more network transactions, over time, for any given resolution of any given name, and thus more chances for a bad guy to successfully spoof a response and have that forged answer be cached. One could also eke out a small measure of extra security (again, if cryptographic methods are for some reason unavailable) by turning off IXFR and thus causing all zone transfers to occur with AXFR, which is TCP-based and thus presumably harder to spoof. But, that's a heavy price to pay for a small increment of extra security. Better to go for crypto, at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), by implementing (as many have) an out-of-band method of replicating zone data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN tunnels) or by securing *all* communicati on between nameserver instances (e.g. IPSEC tunnels). On 24.08.16 08:00, Mark Andrews wrote: named only accepts IXFR over TCP. While the protocol supports sending deltas with IXFR/UDP named does not use that part of the protocol. just IXFRs or AXFRs too? Isn't edns over UDP enough in many cases? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves or Forwarders?
On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > just IXFRs or AXFRs too? > Isn't edns over UDP enough in many cases? >From what I've seen in past testing any attempt to request an AXFR against BIND using UDP gets an immediate TC response. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves or Forwarders?
AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given this, I would have expected either a FORMERR response (interpreting the request itself as "illegal"), or a NOTIMPL response (interpreting "undefined" as "might have been defined by an RFC subsequent to 5936, but I don't happen to know about it"). NOERROR response with TC is surprising. IXFR over UDP is defined (RFC 1995 Section 2), but not implemented (apparently) by BIND. So NOTIMPL would seem appropriate. - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr Sent: Thursday, August 25, 2016 4:09 PM To: bind-users Subject: Re: Slaves or Forwarders? On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > just IXFRs or AXFRs too? > Isn't edns over UDP enough in many cases? >From what I've seen in past testing any attempt to request an AXFR against >BIND using UDP gets an immediate TC response. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves or Forwarders?
In message <7db0887c1dbf4ce0b1590ee09d2cb...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given > this, I would have expected either a FORMERR response (interpreting the > request itself as "illegal"), or a NOTIMPL response (interpreting > "undefined" as "might have been defined by an RFC subsequent to 5936, but > I don't happen to know about it"). NOERROR response with TC is surprising. Named sends FORMERR. > IXFR over UDP is defined (RFC 1995 Section 2), but not implemented > (apparently) by BIND. So NOTIMPL would seem appropriate. Named sends back the current SOA record over UDP. This is equivalent to "up to date" or "retry over TCP as the answer will not fit in the space available" depending upon the serial in the request. Mark > - Kevin > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr > Sent: Thursday, August 25, 2016 4:09 PM > To: bind-users > Subject: Re: Slaves or Forwarders? > > On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > > just IXFRs or AXFRs too? > > Isn't edns over UDP enough in many cases? > > >From what I've seen in past testing any attempt to request an AXFR against > >BIND using UDP gets an immediate TC response. > > Steve > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
