Re: DMARC question
In article you write: >We have a couple of small domains whose DNS is served by BIND on our dedicated >machines. Almost 3 years ago we had set up DMARC records, >and were getting reports from various MXs every day until a couple of days ago >(Aug 13). Then they suddenly stopped! > >Nothing in the BIND config or zone files was changed, and our Postfix mail >logs (on our dedicated server) don't show *anything* addressed >to our DMARC target since then. (I.e., it's not that our spam filtering is >dropping them.) > >Has anyone ever observed anything like this? I'm getting the usual reports from Google, Yahoo, and other places, as recently as this morning. It's Just You. ___ 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: Local Slave copy of root zone
Doug Barton wrote: > > Slaving the root and ARPA zones is a small benefit to performance for a busy > resolver, [...] > This technique is particularly useful for folks in bad/expensive network > conditions. While the current anycast networks of root servers is much better > than it was "in the old days," the more data you have locally the more > resilient you are to DDOS against those targets. I should probably have said that it isn't just RFC 8198: * synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most cases you don't need to talk to the authorities to find out that the answer is no; this is on by default * prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1]) means your users won't suffer the latency of talking to the authorities when a popular name expires from the cache; this is on by default * stale-answer-enable / max-stale-ttl (https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale) means you can still function for a while if you can't reach the authorities These are all general-purpose features, not at all specific to the root. I think a local root was clearly a good idea before DNSSEC; since 2010 I have been less comfortable with it. [1] contains possibly my favourite ack ever Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet: Southwest veering west, 4 or 5, increasing 6 for a time. Moderate or rough, occasionally slight later. Rain then showers. Moderate or poor, becoming 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
DMARC question
We have a couple of small domains whose DNS is served by BIND on our dedicated machines. Almost 3 years ago we had set up DMARC records, and were getting reports from various MXs every day until a couple of days ago (Aug 13). Then they suddenly stopped! Nothing in the BIND config or zone files was changed, and our Postfix mail logs (on our dedicated server) don't show *anything* addressed to our DMARC target since then. (I.e., it's not that our spam filtering is dropping them.) Has anyone ever observed anything like this? Thanks! ___ 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: Local Slave copy of root zone
On 08/15/2018 09:11 AM, Bob McDonald wrote: I've recently been investigating having a local slave copy of the root zone on a caching/forwarder type server. I've even put the local slave copy of the root zone into a separate view accessed via a different loopback address. (An limited example of this exists on the ISC site) My question is this. Is there any benefit to also hosting local slave copies of arpa., in-addr.arpa., and ip6.arpa.? Although FreeBSD now comes with unbound as it's default DNS software, installing bind yields an example named.conf which floats the concept of the local slave copies of the above zones. (That is what led me down this path...) I'm responsible for the slave zone configuration in the FreeBSD named.conf. At least, I wrote the original version of it, and maintained it for many years. The version located here looks essentially as I left it: https://svnweb.freebsd.org/ports/head/dns/bind913/files/named.conf.in?revision=470832=markup Slaving the root and ARPA zones is a small benefit to performance for a busy resolver, and as long as you maintain a watch on your logs to make sure that slaving the zone does not fail, you're golden. I understand the reasoning behind maintaining these zones in a separate view, accessible only locally, but don't see any value in it. A resolver is going to cache the answers it gets anyway. This technique is particularly useful for folks in bad/expensive network conditions. While the current anycast networks of root servers is much better than it was "in the old days," the more data you have locally the more resilient you are to DDOS against those targets. In regards to production readiness, I've used it in heavy production at numerous sites, as have thousands of FreeBSD users. hope this helps, Doug ___ 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: Local Slave copy of root zone
Thank you sir! I'll investigate the newer bind implementations. Regards. Bob On Wed, Aug 15, 2018 at 12:41 PM Tony Finch wrote: > Bob McDonald wrote: > > > I've recently been investigating having a local slave copy of the root > zone > > on a caching/forwarder type server. > > I do this on my toy server for various strange reasons, and although it > has worked OK I'm not confident it's really solid enough for production. > > If you are running BIND 9.12 then its RFC 8198 implementation removes a > lot of the benefits of having a local root (and it also works for the arpa > zones). > > BIND 9.14 will have an improved local root implementation (called a > "mirror" zone) which validates the zone so you don't blindly serve bogus > data. The feature is available now in the 9.13 dev branch; I have not > tried mirroring the arpa zones - the docs suggest that isn't a supported > config for mirror zones. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > democracy, participation, and the co-operative principle > ___ 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: Local Slave copy of root zone
Bob McDonald wrote: > I've recently been investigating having a local slave copy of the root zone > on a caching/forwarder type server. I do this on my toy server for various strange reasons, and although it has worked OK I'm not confident it's really solid enough for production. If you are running BIND 9.12 then its RFC 8198 implementation removes a lot of the benefits of having a local root (and it also works for the arpa zones). BIND 9.14 will have an improved local root implementation (called a "mirror" zone) which validates the zone so you don't blindly serve bogus data. The feature is available now in the 9.13 dev branch; I have not tried mirroring the arpa zones - the docs suggest that isn't a supported config for mirror zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ democracy, participation, and the co-operative principle ___ 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
Local Slave copy of root zone
I've recently been investigating having a local slave copy of the root zone on a caching/forwarder type server. I've even put the local slave copy of the root zone into a separate view accessed via a different loopback address. (An limited example of this exists on the ISC site) My question is this. Is there any benefit to also hosting local slave copies of arpa., in-addr.arpa., and ip6.arpa.? Although FreeBSD now comes with unbound as it's default DNS software, installing bind yields an example named.conf which floats the concept of the local slave copies of the above zones. (That is what led me down this path...) Anyone care to weigh in? Regards, Bob ___ 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
