RE: Forward record for WWW
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
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
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
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
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
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
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
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
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
On 5 May 2016 at 11:55, Stephane Bortzmeyerwrote: > 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