Re: Monitor DNS queries toward Root severs

2016-05-05 Thread Warren Kumari
On Wed, May 4, 2016 at 4:37 AM, Daniel Dawalibi wrote: > Hello > > > > Is there any tool or configuration that allows us to monitor/graph the > number of outbound DNS queries toward the Root servers? > Others have provided information on how to capture the traffic. > As you can see in the below

RE: Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
Stanley, > Are you running DNSSEC? Negative, we are not running dnssec. Brian ___ 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

Re: Forward record for WWW

2016-05-05 Thread Stanley Weilnau
Are you running DNSSEC? Stanley Weilnau > On May 5, 2016, at 3:30 PM, Cuttler, Brian R. (HEALTH) > wrote: > > Ralf, All, > > Sorry, there was a brief side discussion. A couple of years ago we > implemented a test server, same platform (in this case cloned virtual > systems) with same source

RE: Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
Ralf, All, Sorry, there was a brief side discussion. A couple of years ago we implemented a test server, same platform (in this case cloned virtual systems) with same source tables and config, running in the same environment, in this case my DMZ. Because I didn't want to risk damage to the mast

RE: Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
Barry, > The output shows that there clearly isn't an A record for the zone apex. > You need to post the zone file if you want help with what you did wrong. > My guess is you either forgot the "." at the end of the name, or didn't > reload the server after updating the zone file. Those would hav

Re: Forward record for WWW

2016-05-05 Thread Barry Margolin
In article , "Cuttler, Brian R. (HEALTH)" wrote: > Since this is only a test server not production, and lives in the DMZ it must > be blocked at the FW. > > # dig with no specification for query type and with "A" both give the same > result. Dig with q-type "any" is output included. > > Sorr

RE: Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
Since this is only a test server not production, and lives in the DMZ it must be blocked at the FW. # dig with no specification for query type and with "A" both give the same result. Dig with q-type "any" is output included. Sorry that prior email had bad line breaks, looked ok when I wrote it

Re: Forward record for WWW

2016-05-05 Thread Stephane Bortzmeyer
On Thu, May 05, 2016 at 04:06:06PM +, Cuttler, Brian R. (HEALTH) wrote a message of 34 lines which said: > I configured the change for my external test server only > (199.184.16.7, which is _probably_ available for external query) No. % dig @199.184.16.7 A wadsworth.org ; <<>> DiG 9.9.5

RE: Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
Forgive me, while the records are fully live on my internal servers, I configured the change for my external test server only (199.184.16.7, which is _probably_ available for external query) but not on the master. We had issues years ago, and implemented a server parallel to the master to vet c

Re: Forward record for WWW

2016-05-05 Thread Stephane Bortzmeyer
On Thu, May 05, 2016 at 03:42:24PM +, Cuttler, Brian R. (HEALTH) wrote a message of 29 lines which said: > External record in the zone file is actually > wadsworth.org. 300 IN A 199.184.16.22 None of the three name servers for wadsworth.org serve this A record. It seems the master was *n

Re: Forward record for WWW

2016-05-05 Thread Matthew Pounsett
On 5 May 2016 at 11:55, Stephane Bortzmeyer wrote: > On Thu, May 05, 2016 at 03:42:24PM +, > Cuttler, Brian R. (HEALTH) wrote > a message of 29 lines which said: > > > External record in the zone file is actually > > wadsworth.org. 300 IN A 199.184.16.22 > > None of the three name servers

Forward record for WWW

2016-05-05 Thread Cuttler, Brian R. (HEALTH)
The recent discussion on using a forward (A) record matching the domain name but addressed to the webserver was very timely for our site. I had recently experimented with this at the request of our webmaster. On our internal server, running bind 9.9.5-p1, a solaris box, I was able to implement

Re: Problems after upgrade to 9.10.4

2016-05-05 Thread Michael Brunnbauer
hi all, On Thu, May 05, 2016 at 09:31:06AM +0200, Michael Brunnbauer wrote: > after upgrading from bind 9.10.3-P2 to 9.10.4, I have intermittent DNS lookup > errors on one of my servers with low DNS load. The server is not > authoritative > for the affected zones but the authoritative servers a

Re: Intermittent Issues Resolving Microsoft Hostnames

2016-05-05 Thread Sam Wilson
In article , Stephane Bortzmeyer wrote: > On Wed, May 04, 2016 at 02:02:24PM -0400, > Rob Heilman wrote > a message of 305 lines which said: > > > We run BIND 9.9.5-9 on Debian x86_64 to support a moderately sized > > email hosting system. System info listed at the end of this > > message.

Re: Multiple SERVFAIL/REFUSED unexpected RCODE

2016-05-05 Thread Mik J
Thank you guys for your answers. Le Mardi 3 mai 2016 16h09, Barry Margolin a écrit : In article , Mik J wrote: > Hello Mark, > Thank you for your answer. I'm not sure I've understood everything but I'll > read it numerous times if necessary.I have ACLs so I'm not surprised to see

Problems after upgrade to 9.10.4

2016-05-05 Thread Michael Brunnbauer
hi all, after upgrading from bind 9.10.3-P2 to 9.10.4, I have intermittent DNS lookup errors on one of my servers with low DNS load. The server is not authoritative for the affected zones but the authoritative servers are under my control and show no problems. So far, I have not been able to rep