Re: dots in hostnames problem
On Mar 10, 2011, at 4:24 PM, Matt Rae wrote: Thanks guys, sounds like a solution would be to transfer the zone files outside of bind. I'll give some of the suggestions a try. Matt I can't help but be curious. What problem would be solved by transferring the zone files outside of bind? John On Wed, Mar 9, 2011 at 1:01 PM, John Wobus jw...@cornell.edu wrote: On Mar 9, 2011, at 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1Ax.x.x.x host2.set1Ax.x.x.x host3.set1Ax.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 Ax.x.x.x host2 Ax.x.x.x host3 Ax.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? I bet you can't change that, but it doesn't matter to Bind or the DNS. The two files mean the same thing. ORIGIN doesn't assume anything about subdomains: it's just a convenience for abbreviating the file. If you need a consistent format for some purpose, you could use the output of named-compilezone. John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On Thu, Mar 10, 2011 at 01:24:01PM -0800, Matt Rae matt...@gmail.com wrote a message of 54 lines which said: sounds like a solution would be to transfer the zone files outside of bind. The solution to what? There is no problem at all, the files are absolutely identical after the transfer. The only issue is your flawed assumptions (as in the subject of the thread). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
Thanks guys, sounds like a solution would be to transfer the zone files outside of bind. I'll give some of the suggestions a try. Matt On Wed, Mar 9, 2011 at 1:01 PM, John Wobus jw...@cornell.edu wrote: On Mar 9, 2011, at 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1 A x.x.x.x host2.set1 A x.x.x.x host3.set1 A x.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 A x.x.x.x host2 A x.x.x.x host3 A x.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? I bet you can't change that, but it doesn't matter to Bind or the DNS. The two files mean the same thing. ORIGIN doesn't assume anything about subdomains: it's just a convenience for abbreviating the file. If you need a consistent format for some purpose, you could use the output of named-compilezone. John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
RFC 952 was the original follow-ons are RFC 1123 and 1178 Unless you write a script to parse your file and queries I know of no way around this. We use hypens instead of dots in our names.Mar 9, 2011 01:10:50 PM, matt...@gmail.com wrote: Hi, I'm working on setting up a slave dns server. Dots havehistorically beenused in the hostnames here. The dots cause theresulting zone file from a zone transfer to have $ORIGIN automaticallyset assuming the dots are indicating a subdomain.Here's an example of what's happening:master zone file:$ORIGIN example.com.host1.set1 A x.x.x.xhost2.set1 A x.x.x.xhost3.set1 A x.x.x.xslave's zone file after axfr:$ORIGIN set1.example.com.host1 A x.x.x.xhost2 A x.x.x.xhost3 A x.x.x.xIs there a way to have it not change the ORIGIN and assume the dotsare a subdomain?Thanks!Matt Rae___bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are a lot of unfortunate practices one can find in DNS names. I'd personally recommend not doing anything that conflicts with the RFC. At my place of business, we slave a zone from a group that has underscores in the hostnames which is also not allowed. It does not appear to hurt anything, but I wouldn't be surprised if something funny happens someday and is traced to that. On 03/09/2011 01:16 PM, Ben Croswell wrote: The dots delineate domains even if you don't view it as a new domain. -Ben Croswell On Mar 9, 2011 1:13 PM, Matt Rae matt...@gmail.com - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13xbkACgkQmb+gadEcsb4LQgCfePJlwOUhyw0mTQiARlCgIe6/ cWIAnRPnkvtp5FQFovoOKV28hZycYSTG =99Si -END PGP SIGNATURE- attachment: novosirj.vcf___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On 3/9/2011 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. What does the term hostname mean to you? If hostname is defined as the contents of the first label of a dot-delimited DNS name, then dot in hostname does not and cannot exist. Or, perhaps you have a different definition? The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1Ax.x.x.x host2.set1Ax.x.x.x host3.set1Ax.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 Ax.x.x.x host2 Ax.x.x.x host3 Ax.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? Well, technically, that is not just an assumption. set1.example.com is, in reality, a subdomain of example.com. $ORIGIN statements are just a convenience for named's zone-parsing routine. If you intend to parse zone contents yourself, you should look at the actual data rather than literally the zone file, which is only one way among many to express that data. Dealing with the actual data can be accomplished either through the DNS protocol itself (e.g. zone transfer), or via a script that parses the $ORIGIN statements, etc. and renders the data into a more digestible form. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On Mar 9, 2011, at 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1Ax.x.x.x host2.set1Ax.x.x.x host3.set1Ax.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 Ax.x.x.x host2 Ax.x.x.x host3 Ax.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? I see that there have already been a bunch of replies saying, in essence the bit after the dot is gong to be a different label... My question is why do you care? -- the slave files should be treated as opaque blobs of data. Yes, they look like real zone files (and *are* real zone files) but if you pretend that they are instead a blob of unparsable data that BIND writes out (and later read in), you will be much much better off... If you want to do some processing on the data, etc go to the source and read the files off the master (and / or AXFR it). W Thanks! Matt Rae ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On 03/09/2011 06:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Oh god, not this again... ;o) The . in a DNS name stands for label separator. If you have a hostname with dots in it all you have is a hostname with 1 label to the left of the enclosing DNS zone. It's legal, fine, nothing to worry about, move along. If you want a zonefile without $ORIGIN and so forth, use a tool to flatten it out - e.g. dig @server zone.name axfr named-compilezone -o output zone.name zone.file ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dots in hostnames problem
On Mar 9, 2011, at 1:09 PM, Matt Rae wrote: Hi, I'm working on setting up a slave dns server. Dots have historically been used in the hostnames here. The dots cause the resulting zone file from a zone transfer to have $ORIGIN automatically set assuming the dots are indicating a subdomain. Here's an example of what's happening: master zone file: $ORIGIN example.com. host1.set1Ax.x.x.x host2.set1Ax.x.x.x host3.set1Ax.x.x.x slave's zone file after axfr: $ORIGIN set1.example.com. host1 Ax.x.x.x host2 Ax.x.x.x host3 Ax.x.x.x Is there a way to have it not change the ORIGIN and assume the dots are a subdomain? I bet you can't change that, but it doesn't matter to Bind or the DNS. The two files mean the same thing. ORIGIN doesn't assume anything about subdomains: it's just a convenience for abbreviating the file. If you need a consistent format for some purpose, you could use the output of named-compilezone. John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
