RE: Multiple $TTL values
> This is a common point of confusion. DNS does not transfer > zoneFILES. Zone files are read and converted into the > in-memory tree structure. Zones are sent in wire format > from the in-memory tree. The receiving end populates its > in-memory tree. It can then convert the information to > zone file format, and write it out, but do not expect it > to look anything like the original zone file. It has no > idea what the original file looked like, or what order the > records were in. > > $ORIGIN and $TTL only apply to the zone they are in, so no > need to reset them at the end of the file since they cease > to exist at that point. They apply "from this line down > until changed" and are merely a convenience to shorten > the size of the file. > > -- > Bob Harold > > Bob, Thanks for your response. Although I was aware the zone data is transferred in wire-format between nameservers I was more concerned with the processing of the file when it is read (i.e. on startup, reconfig, etc.) We are "lucky" enough to be importing more zones into a DB backed provisioning system and as bind is getting more and more strict with each release regarding transfers we have scrapped our older scrubbing logic and started using bind to provide this service and couldn't be happier. Just wanted to confirm this $TTL logic was exactly as I suspected before requiring code changes (non-bind). Thanks again, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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: Multiple $TTL values
On Thu, Sep 22, 2016 at 3:36 PM, Woodworth, John R < john.woodwo...@centurylink.com> wrote: > Hello, > > > > We’ve recently noticed multiple $TTL values in transferred zonefiles which > do not exist in the original zonefiles. They appear to be aggregates of > TTLs set for individual records and I am definitely a fan of the organized > look and feel. > > > > However, I am curious about how they should be interpreted where $ORIGIN > is concerned. I just re-read rfc2308 and it states quite simply: > > “ All resource records appearing after the directive, and which do not > > explicitly include a TTL value, have their TTL set to the TTL given > > in the $TTL directive. “ > > > > My confusion is $ORIGIN basically defines the default origin while reading > in the file and creates a mini-universe for interpreting records until > redefined. Would a $TTL after a $ORIGIN be encapsulated by and restricted > to records within that $ORIGIN block? > > > > My gut tells me no, and to follow the RFC literally (or loosely stated > “from this point down”) but looking at the file it seems as if the $TTL is > intended to be for the records within the $ORIGIN only (i.e. it is not > reset to global value at the end). > > > > I need to investigate this more on my own but I thought it might prove > useful to ask the group as part of my research. > > > > > > Thanks in advance, > > John > > > This is a common point of confusion. DNS does not transfer zoneFILES. Zone files are read and converted into the in-memory tree structure. Zones are sent in wire format from the in-memory tree. The receiving end populates its in-memory tree. It can then convert the information to zone file format, and write it out, but do not expect it to look anything like the original zone file. It has no idea what the original file looked like, or what order the records were in. $ORIGIN and $TTL only apply to the zone they are in, so no need to reset them at the end of the file since they cease to exist at that point. They apply "from this line down until changed" and are merely a convenience to shorten the size of the file. -- Bob Harold ___ 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
Multiple $TTL values
Hello, We've recently noticed multiple $TTL values in transferred zonefiles which do not exist in the original zonefiles. They appear to be aggregates of TTLs set for individual records and I am definitely a fan of the organized look and feel. However, I am curious about how they should be interpreted where $ORIGIN is concerned. I just re-read rfc2308 and it states quite simply: " All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive. " My confusion is $ORIGIN basically defines the default origin while reading in the file and creates a mini-universe for interpreting records until redefined. Would a $TTL after a $ORIGIN be encapsulated by and restricted to records within that $ORIGIN block? My gut tells me no, and to follow the RFC literally (or loosely stated "from this point down") but looking at the file it seems as if the $TTL is intended to be for the records within the $ORIGIN only (i.e. it is not reset to global value at the end). I need to investigate this more on my own but I thought it might prove useful to ask the group as part of my research. Thanks in advance, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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
