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.org/mailman/listinfo/bind-users


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) 
> <brian.cutt...@health.ny.gov> 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 tables and config, running in the same environment, 
> in this case my DMZ.
> 
> Because I didn't want to risk damage to the master, as we have corrupted 
> tables and crashed servers, we implement changes on the test server, and if 
> it works as expected we rsync the updated tables to the live master from the 
> test master.
> 
> Someone else reported a problem with dig to my server, and I'd thought the 
> list was CC'd, but the test is 199.184.16.7 and is apparently blocked at the 
> FW, as the test master and the actual master both live in the DMZ but the 
> test machine does not normally need to be seen from outside.
> 
> My - what an extraordinary result!
> 
> Looking again at the SOA from dig, included below we see 1604xxx, an April 
> date "YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a 
> March date, 1603xxx (yes, I have a script that subs that in when I move the 
> tables from the source to the root directory, complex combo of RCS, followed 
> by # SED as RCS doesn't provide integer revision numbers and an # rsync to 
> the directory read by the daemon, all on my test machine. If that all checks 
> out, an rsync from the test machine live (rather than source) directory to 
> the live directory on the actual master server).
> 
> In any case, I stopped and started the server, and the A record is now being 
> reported.
> 
> So, for reasons I don't understand, the SOA as reported by DIG does not match 
> the SOA serial imbedded in the file and reported by the server log.
> 
> We solved my first problem, but I am now very confused by the apparent cause.
> 
> I have run the rsync from my test server to my production master, reloaded 
> the tables, reloaded the tables. I see the same SOA as the test server (I 
> rsync the tables with no changes, SOA on my test and production servers is 
> the same), in the named logs, in DIG output, in the source files.
> 
> Something is a bit hinky with my test server and I've no idea what.
> 
> If anyone has any suggestions I'd love to hear them, but with your help the 
> issue I was having has been resolved by restarting the server, rather than 
> reloading the zones files.
> 
> Many thanks,
> Brian
> 
>> -Original Message-
>> From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov]
>> Sent: Thursday, May 05, 2016 3:03 PM
>> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
>> Subject: RE: Forward record for WWW
>> 
>> ATTENTION: This email came from an external source. Do not open
>> attachments or click on links from unknown senders or unexpected emails.
>> 
>> 
>> Ah, I found it.
>> When I query, I get your old serial number, not the new one.
>> Perhaps the zone is "stuck" in cache and an rndc reload is not working for
>> you?
>> You can either stop/restart the server or try rndc flushname and rndc
>> reload again.
>> 
>> [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org.
>> soa
>> 
>> ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us.
>> wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got
>> answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa
>> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion
>> requested but not available
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;wadsworth.org. IN  SOA
>> 
>> ;; ANSWER SECTION:
>> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org.
>> qll.wadsworth.org. 1604120926 10800 3600 604800 86400
>> 
>> ;; AUTHORITY SECTION:
>> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
>> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
>> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
>> 
>> ;; ADDITIONAL SECTION:
>> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
>> beacon.health.state.ny.us. 10800 IN A   192.135.176.22
>> 
>> ;; Query time: 68 msec
>> ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31
>> GMT 2016 ;; MSG SIZE  rcvd: 203
>>

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 master, as we have corrupted tables 
and crashed servers, we implement changes on the test server, and if it works 
as expected we rsync the updated tables to the live master from the test master.

Someone else reported a problem with dig to my server, and I'd thought the list 
was CC'd, but the test is 199.184.16.7 and is apparently blocked at the FW, as 
the test master and the actual master both live in the DMZ but the test machine 
does not normally need to be seen from outside.

My - what an extraordinary result!

Looking again at the SOA from dig, included below we see 1604xxx, an April date 
"YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a March 
date, 1603xxx (yes, I have a script that subs that in when I move the tables 
from the source to the root directory, complex combo of RCS, followed by # SED 
as RCS doesn't provide integer revision numbers and an # rsync to the directory 
read by the daemon, all on my test machine. If that all checks out, an rsync 
from the test machine live (rather than source) directory to the live directory 
on the actual master server).

In any case, I stopped and started the server, and the A record is now being 
reported.

So, for reasons I don't understand, the SOA as reported by DIG does not match 
the SOA serial imbedded in the file and reported by the server log.

We solved my first problem, but I am now very confused by the apparent cause.

I have run the rsync from my test server to my production master, reloaded the 
tables, reloaded the tables. I see the same SOA as the test server (I rsync the 
tables with no changes, SOA on my test and production servers is the same), in 
the named logs, in DIG output, in the source files.

Something is a bit hinky with my test server and I've no idea what.

If anyone has any suggestions I'd love to hear them, but with your help the 
issue I was having has been resolved by restarting the server, rather than 
reloading the zones files.

Many thanks,
Brian

> -Original Message-
> From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov]
> Sent: Thursday, May 05, 2016 3:03 PM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Subject: RE: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> Ah, I found it.
> When I query, I get your old serial number, not the new one.
> Perhaps the zone is "stuck" in cache and an rndc reload is not working for
> you?
> You can either stop/restart the server or try rndc flushname and rndc
> reload again.
> 
> [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org.
> soa
> 
> ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us.
> wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa
> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion
> requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  SOA
> 
> ;; ANSWER SECTION:
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org.
> qll.wadsworth.org. 1604120926 10800 3600 604800 86400
> 
> ;; AUTHORITY SECTION:
> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
> 
> ;; ADDITIONAL SECTION:
> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
> beacon.health.state.ny.us. 10800 IN A   192.135.176.22
> 
> ;; Query time: 68 msec
> ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31
> GMT 2016 ;; MSG SIZE  rcvd: 203
> 
> [rbisc...@nsc1.nasa.gov ~]$
> 
> 
> Thank you,
> Ralph F. Bischof, Jr.
> The opinions expressed within this communication are not necessarily those
> of NASA.
> 
> 
> 
> > -----Original Message-
> > From: Cuttler, Brian R. (HEALTH) [mailto:brian.cutt...@health.ny.gov]
> > Sent: Thursday, May 05, 2016 2:00 PM
> > To: Bischof, Ralph F. (MSFC-IS40)[NICS] <ralph.bisc...@nasa.gov>
> > Subject: RE: Forward record for WWW
> >
> > Good suggestions all.
> >
> > First was a look with # cat, # cat -evt has proven 

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 have been my guesses also, but I'm unable to resolve 
wadsworth.org.wadsworth.org which I'd expect to be the result of a missing dot.

I'm including the head of the file, it is longer than we really need.

Also including the last few lines of the server log file, SOA serial matches 
the zone file.

12-Apr-2016 09:29:23.221 general: info: reloading zones succeeded
12-Apr-2016 09:29:23.225 general: info: zone wadsworth.org/IN/internal: loaded 
serial 1604120926
12-Apr-2016 09:29:23.229 general: info: zone wadsworth.org/IN/external: loaded 
serial 1604120926
05-May-2016 11:27:07.264 general: info: received SIGHUP signal to reload zones
05-May-2016 11:27:07.265 general: info: loading configuration from 
'/etc/named.conf'
05-May-2016 11:27:07.266 general: info: reading built-in trusted keys from file 
'/etc/bind.keys'
05-May-2016 11:27:07.267 general: info: using default UDP/IPv4 port range: 
[1024, 65535]
05-May-2016 11:27:07.267 general: info: using default UDP/IPv6 port range: 
[1024, 65535]
05-May-2016 11:27:07.274 general: info: sizing zone task pool based on 48 zones
05-May-2016 11:27:07.275 general: warning: Warning: view internal: 
'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
05-May-2016 11:27:07.280 general: info: reloading configuration succeeded
05-May-2016 11:27:07.281 general: info: reloading zones succeeded
05-May-2016 11:27:07.284 general: info: zone wadsworth.org/IN/internal: loaded 
serial 1605051125
05-May-2016 11:27:07.287 general: info: zone wadsworth.org/IN/external: loaded 
serial 1605051125
[root@euclid named]#



[euclid]: /etc/dns-root > more db.wadsworth.org
$TTL 86400
@   IN  SOA pauling.wadsworth.org.  qll.wadsworth.org. (
1605051125  ; serial number
10800   ; refresh after 3 hours
3600; retry after 1 hour
604800  ; expire after 1000 hour
86400 ) ; minimum ttl of 1 day

IN  NS  pauling.wadsworth.org.
IN  NS  ns1.albany.edu.
IN  NS  beacon.health.state.ny.us.

pauling.wadsworth.org.  IN  A   199.184.16.6

; 27-feb-2007

gatecl1-dmz1IN  A   199.184.16.8
gatecl2-dmz1IN  A   199.184.16.9
gatecl-dmz1 IN  A   199.184.16.10


;ns1.albany.edu.IN  A   169.226.1.100
;beacon.health.state.ny.us. IN  A   192.135.176.22



localhost   IN  A   127.0.0.1

gate3.wadsworth.org.  INA 199.184.16.5

; 2016-03-24 BRC
; short TTL forward record pointing domain name to WWW IP address. DO NOT USE CN
AME, they are
; "cononical" and would screw up the MX records!!
; If no problems we can lengthen the TTL and later remove the record specific va
lue.
; Tested with no issues on intra-net DNS servers.

wadsworth.org.  300  IN A 199.184.16.22
; simply not being served, removed until I can figure out why

; 2012-12-10 per ivan
wadsworth.org.  IN  TXT "v=spf1 ptr:wadsworth.org ip4:199.184.28.0/22 ?all"

--removing dig output and other already posted information--

Thank you,
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.org/mailman/listinfo/bind-users


Re: Forward record for WWW

2016-05-05 Thread Barry Margolin
In article <mailman.731.1462469692.73610.bind-us...@lists.isc.org>,
 "Cuttler, Brian R. (HEALTH)" <brian.cutt...@health.ny.gov> 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.
> 
> Sorry that prior email had bad line breaks, looked ok when I wrote it but 
> they have moved us to outlook and I am apparently not sufficient proficient 
> in its use.

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.

> 
> This is the output from dig against this server.
> 
> [euclid] ~ 201> dig @199.184.16.7 wadsworth.org
> 
> ; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  A
> 
> ;; AUTHORITY SECTION:
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
> qll.wadsworth.org. 1603081507 10800 3600 604800 86400
> 
> ;; Query time: 0 msec
> ;; SERVER: 199.184.16.7#53(199.184.16.7)
> ;; WHEN: Thu May 05 13:29:15 EDT 2016
> ;; MSG SIZE  rcvd: 90
> 
> 
> 
> [euclid] ~ 213> dig any @199.184.16.7 wadsworth.org
> 
> ; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  ANY
> 
> ;; ANSWER SECTION:
> wadsworth.org.  86400   IN  MX  10 smtptoo.wadsworth.org.
> wadsworth.org.  86400   IN  MX  10 smtpproxy.wadsworth.org.
> wadsworth.org.  86400   IN  MX  5 wish1.wadsworth.org.
> wadsworth.org.  86400   IN  TXT "v=spf1 ptr:wadsworth.org 
> ip4:199.184.28.0/22 ?all"
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
> qll.wadsworth.org. 1603081507 10800 3600 604800 86400
> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
> 
> ;; ADDITIONAL SECTION:
> wish1.wadsworth.org.86400   IN  A   199.184.16.38
> smtptoo.wadsworth.org.  86400   IN  A   199.184.16.18
> smtpproxy.wadsworth.org. 86400  IN  A   199.184.16.16
> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
> 
> ;; Query time: 0 msec
> ;; SERVER: 199.184.16.7#53(199.184.16.7)
> ;; WHEN: Thu May 05 13:30:49 EDT 2016
> ;; MSG SIZE  rcvd: 369
> 
> [euclid] ~ 214>
> 
> > -Original Message-
> > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> > Sent: Thursday, May 05, 2016 12:12 PM
> > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> > Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org
> > Subject: Re: Forward record for WWW
> > 
> > ATTENTION: This email came from an external source. Do not open
> > attachments or click on links from unknown senders or unexpected emails.
> > 
> > 
> > On Thu, May 05, 2016 at 04:06:06PM +,  Cuttler, Brian R. (HEALTH)
> > <brian.cutt...@health.ny.gov> 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-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1
> > server found) ;; global options: +cmd ;; connection timed out; no servers
> > could be reached

-- 
Barry Margolin
Arlington, MA
___
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: 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 but they 
have moved us to outlook and I am apparently not sufficient proficient in its 
use.

This is the output from dig against this server.

[euclid] ~ 201> dig @199.184.16.7 wadsworth.org

; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wadsworth.org. IN  A

;; AUTHORITY SECTION:
wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
qll.wadsworth.org. 1603081507 10800 3600 604800 86400

;; Query time: 0 msec
;; SERVER: 199.184.16.7#53(199.184.16.7)
;; WHEN: Thu May 05 13:29:15 EDT 2016
;; MSG SIZE  rcvd: 90



[euclid] ~ 213> dig any @199.184.16.7 wadsworth.org

; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wadsworth.org. IN  ANY

;; ANSWER SECTION:
wadsworth.org.  86400   IN  MX  10 smtptoo.wadsworth.org.
wadsworth.org.  86400   IN  MX  10 smtpproxy.wadsworth.org.
wadsworth.org.  86400   IN  MX  5 wish1.wadsworth.org.
wadsworth.org.  86400   IN  TXT "v=spf1 ptr:wadsworth.org 
ip4:199.184.28.0/22 ?all"
wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
qll.wadsworth.org. 1603081507 10800 3600 604800 86400
wadsworth.org.  86400   IN  NS  ns1.albany.edu.
wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.

;; ADDITIONAL SECTION:
wish1.wadsworth.org.86400   IN  A   199.184.16.38
smtptoo.wadsworth.org.  86400   IN  A   199.184.16.18
smtpproxy.wadsworth.org. 86400  IN  A   199.184.16.16
pauling.wadsworth.org.  86400   IN  A   199.184.16.6

;; Query time: 0 msec
;; SERVER: 199.184.16.7#53(199.184.16.7)
;; WHEN: Thu May 05 13:30:49 EDT 2016
;; MSG SIZE  rcvd: 369

[euclid] ~ 214>

> -Original Message-
> From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> Sent: Thursday, May 05, 2016 12:12 PM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org
> Subject: Re: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> On Thu, May 05, 2016 at 04:06:06PM +,  Cuttler, Brian R. (HEALTH)
> <brian.cutt...@health.ny.gov> 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-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1
> server found) ;; global options: +cmd ;; connection timed out; no servers
> could be reached
___
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: 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-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
___
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: 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 
changes on, so if we lost a zone or crashed the server we could find that out 
without taking out the actual master.

I did check the log files for my test server, there were no errors, the zone 
file seemed to reload without error and even noted the update in the soa serial 
number.

> -Original Message-
> From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> Sent: Thursday, May 05, 2016 11:55 AM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Cc: bind-users@lists.isc.org
> Subject: Re: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> On Thu, May 05, 2016 at 03:42:24PM +,  Cuttler, Brian R. (HEALTH)
> <brian.cutt...@health.ny.gov> 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 *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected for
> some reason.
___
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: 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 *not* reloaded. Did you check its BIND logs to
see? May be the new zone with the A record at the apex was rejected
for some reason.
___
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: 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 for wadsworth.org serve this A record.
>
> It seems the master was *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected
> for some reason.
>

Or perhaps the record was added to a hidden master without the serial
number being updated, and so a zone transfer hasn't happened?
___
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