Forward record for WWW
Cuttler, Brian R. (HEALTH)
brian.cuttler at health.ny.gov
Thu May 5 19:30:01 UTC 2016
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.bischof at nasa.gov]
> Sent: Thursday, May 05, 2016 3:03 PM
> To: Cuttler, Brian R. (HEALTH) <brian.cuttler at 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.
>
> [rbischof at 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
>
> [rbischof at 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.cuttler at health.ny.gov]
> > Sent: Thursday, May 05, 2016 2:00 PM
> > To: Bischof, Ralph F. (MSFC-IS40)[NICS] <ralph.bischof at 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.bischof at nasa.gov]
> > > Sent: Thursday, May 05, 2016 2:52 PM
> > > To: Cuttler, Brian R. (HEALTH) <brian.cuttler at 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.
> > >
More information about the bind-users
mailing list