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 >> >> [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 very helpful in the >>> past, but no apparent error. >>> >>> Removed and reentered the line, using tabs. >>> >>> Removed the TTL. >>> >>> Reloads both successful and showing new SOA each time, but no >>> difference in results from dig. >>> >>>> -----Original Message----- >>>> From: Bischof, Ralph F. (MSFC-IS40)[NICS] >>>> [mailto:ralph.bisc...@nasa.gov] >>>> Sent: Thursday, May 05, 2016 2:52 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. >>>> >>>> >>>>> -----Original Message----- >>>>> ; 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 >>>> >>>> Perhaps it is the email, but the formatting is different than the >>>> other lines. >>>> Since this is a *NIX system, how about completely deleting the entry >>>> and adding it back? Perhaps there is "hidden" corruption in the line. >>>> Try leaving out the TTL, try using "tab" instead of space between >>>> the parameters. >>>> >>>> >>>> Thank you, >>>> Ralph F. Bischof, Jr. >>>> The opinions expressed within this communication are not necessarily >>>> those of NASA. >>>> > > _______________________________________________ > 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
