Lol... man I brain farted on that. Right you are.... thanks for the correction.
-sc -----Original Message----- From: Free, Bob [mailto:[email protected]] Sent: Tuesday, November 17, 2009 1:00 PM To: NT System Admin Issues Subject: RE: https and certs issues Umm, my copy is by Paul Albitz & Cricket Liu, granted my book is ~12 years old but the last time I saw Cricket he had not changed his name. But as you infer, it remains the bible of DNS. His firm (infoblox) had some pretty nice educational type materials and test software up on their website. http://www.infoblox.com/library/ If you are considering any type of DNS or IPAM solutions, I would definitely look at their offerings. We are deploying a NS1 grid and it's pretty amazing what those appliances can do. -----Original Message----- From: Steven M. Caesare [mailto:[email protected]] Sent: Tuesday, November 17, 2009 8:54 AM To: NT System Admin Issues Subject: RE: https and certs issues Ben is absolutely correct here... "DNS & BIND" by Crickett & Lu is required reading if you are going to be doing some significant DNS hosting for yourself. Or even if not, it's great reference scan material... -sc -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Tuesday, November 17, 2009 11:40 AM To: NT System Admin Issues Subject: Re: https and certs issues On Mon, Nov 16, 2009 at 9:20 PM, Richard Stovall <[email protected]> wrote: > But I don't understand how creating nothing but a zone named > board.imcu.com would successfully resolve back to an ip address the > browser could use. board.imcu.com. SOA ns.example.com. [email protected]. [...] board.imcu.com. A 192.0.2.42 > I realize that he can have an A record for 'board' > in the imcu.com zone and also have a board.imcu.com zone without any > violation ... I'm afraid that doesn't make sense, in terms of DNS. A zone can't have resource records for domains outside of the zone of authority. (Excepting the cases of delegations and glue records.) So if <board.imcu.com> marks the start of a zone of authority, it is illegal for <imcu.com> to have an A record for <board.imcu.com>. (Unless it's a glue record.) If you're thinking of a zone as a container, that's generally wrong. Zone's aren't containers the way, say, a directory in a filesystem is a container. A zone of authority is simply an imaginary box we draw around the contiguous DNS records that a given set of nameservers has been delegated authority for. We talk of resource records being "in" that zone in the way that they are Take a look at these two zones (use a monospace font for easier viewing): ; first zone example.com. SOA ns1.example.net. [email protected]. ... example.com. NS ns1.example.net. www.example.com. A 192.0.2.10 support.example.com. A 192.0.2.11 www.support.example.com. A 192.0.2.11 lab.example.com. NS ns2.example.net. ; second zone lab.example.com. SOA ns2.example.net. [email protected]. ... lab.example.com. NS ns2.example.net. lab.example.com. A 192.0.2.42 www.lab.example.com. A 192.0.2.43 The first zone starts at the SOA record. We have several subdomains: <alpha>, <bravo>, <www>, <support>, <www.support> are all child domains of the <example.com.> domain. They all have resource records associated with them, "in" that zone. <lab.example.com> is also a subdomain, but the because the first zone has an NS record for a subdomain, that marks a boundary for that zone of authority. The NS record is a delegation of authority. The second zone starts with its SOA record. Given that the first zone has delegated authority for <lab.example.com.>, it would be illegal for the first zone to then say: lab.example.com. MX mail.example.com. Glue records: You are allowed to place A records in a domain for a delegated child domain only for nameservers within that child domain name. Otherwise, there would be no way to get an address for the nameservers authoritative for the child domain. It should be noted that glue records are *not* authoritative. (Makes sense: They're out of the zone of authority.) The child domain must still list the glue records for things to work properly. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
