Re: Understanding cause of DNS format error (FORMERR)
Hello Sam, > There's some kind of delegation bug as well. If I query > dns1[0-3].one.microsoft.com for SOA and NS for > partners.extranet.microsoft.com you get sensible answers though the > origin host is different for each server queried and those origins are > privately addressed. Which kind of misconfiguration could lead to SOA records for hosts on the internet to be privately addressed? Misconfigured split horizon server? [...] > The authority for zero-answer responses such as > vlasext.partners.extranet.microsoft.com/IN/ is the SOA for > partners.extranet.microsoft.com What do you mean with "authority for zero-answer responses"? What is the normal authority response I should get when querying for non-existent records? I'm trying a few third level domains (e.g. fabric.readthedocs.org) and I most of the time get as authority section the SOA for the second level domain (readthedocs.org). Thanks! > It's all rather horrible. I concur! Gabriele ___ 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: Understanding cause of DNS format error (FORMERR)
In article , Gabriele Paggi wrote: > Hello Sam, > > > There's some kind of delegation bug as well. If I query > > dns1[0-3].one.microsoft.com for SOA and NS for > > partners.extranet.microsoft.com you get sensible answers though the > > origin host is different for each server queried and those origins are > > privately addressed. > > Which kind of misconfiguration could lead to SOA records for hosts on > the internet to be privately addressed? > Misconfigured split horizon server? It's not difficult for private addresses to escape. It need not actually be a problem. It's not necessarily a problem here but it does make it difficult to work out what's going on. > [...] > > The authority for zero-answer responses such as > > vlasext.partners.extranet.microsoft.com/IN/ is the SOA for > > partners.extranet.microsoft.com > > What do you mean with "authority for zero-answer responses"? > What is the normal authority response I should get when querying for > non-existent records? For a NXDOMAIN response, or NOERROR with an empty answer section, the server should provide the SOA record in the authority section. That SOA is the apex of the zone which doesn't contain the answer record you asked for, if you see what I mean. The server is proving that it has authority to tell you that the information doesn't exist. The fact that looking for nonexistent data for vlasext.partners.extranet.microsoft.com returns the partners.extranet.microsoft.com SOA record shows that the vlasext subdomain has not been delegated. The servers should therefore be able to offer an authoritative answer for data that does exist for vlasext.etc... but they don't. > I'm trying a few third level domains (e.g. fabric.readthedocs.org) and > I most of the time get as authority section the SOA for the second > level domain (readthedocs.org). > > Thanks! dig +trace will also (normally) show you how the tree is delegated, though it doesn't print out the SOA records. Try www.automation.ucs.ed.ac.uk. > > It's all rather horrible. > > I concur! Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Understanding cause of DNS format error (FORMERR)
In article , Sam Wilson wrote: > For a NXDOMAIN response, or NOERROR with an empty answer section, the > server should provide the SOA record in the authority section. That SOA > is the apex of the zone which doesn't contain the answer record you > asked for, if you see what I mean. The server is proving that it has > authority to tell you that the information doesn't exist. More important, the SOA record contains the TTL that should be used for the negative cache entry. > > The fact that looking for nonexistent data for > vlasext.partners.extranet.microsoft.com returns the > partners.extranet.microsoft.com SOA record shows that the vlasext > subdomain has not been delegated. The servers should therefore be able > to offer an authoritative answer for data that does exist for > vlasext.etc... but they don't. This type of inconsistency often suggests a DNS-based load balancer is involved. -- Barry Margolin Arlington, MA ___ 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: Reverse zones best practices
* David Dowdle [2012-06-25 14:20:43 -0700]: so, create zones based on how networking creates vlans eg: /24s we dont have any /8 or /16 vlan networks yet > I strongly recommend splitting on /8 /16 and /24 boundries. With > the number of zones you are talking about, doing anything else will > get very confusing very quickly. > > If a netblock is larger than a /24, put at the top and bottom of > each /24 a comment lile explaining what size it is > > For example my 10.in-addr.arpa. zone has > "; this is top of the 10/8 delegates to 10.*/16" > > > zone file for 230.16.10.in-addr.arpa has comment ; 10.16.230.0/23 > vlan : Purpose-of-vlan-here 10.16.230.0-10.16.231.255 (512) > > > In this way, whoever looks at the zone, no matter how dns savvy they > are, knows the size of the netblock > > > > On Mon, 25 Jun 2012, nex6 wrote: > > > > > > >Hi all, > > > >look for some info on best practices for reverse zones. I have, a pretty big > >IP space and alot of reverse zones are not created. > >I want to clean it up, a few people that dont really know DNS are thinking > >of "super netting" eg a top level 10.0.0.0/16 sorta thing. > > > >but we have 100s of defined mission critical reverse zones defined at the > >vlan level of 10.x.x.0/24... my thinking, would be do a > >discovery and create all the /24s, even if there is like 100s. instead of > >the bigger super net... > > > > > >what would be the best practice and the way to go? > > > > > > > >-Nex6 > > > >___ > >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
Re: Reverse zones best practices
* Brad Bendily [2012-06-25 16:35:28 -0500]: wouldn't it be more confusing, in a big IP space with servers, desktops etc all mashed together into one zone? > I don't know about best practice in this case, but I decided to put our > reverse entries into one "super netting" file as you call it. > > We had the same problem that a lot of reverse entries were missing, so I wrote > a script to parse the forward file and create the reverse. Then I incorporated > that into my "adding a new entry" process so, I never add a reverse entry > now, the script creates it. For that matter, all of our forward entries are > in one file as well. > > I don't need to look at DNS to find my network structure. I just want DNS to > do DNS. > > bb > > > -Original Message- > From: bind-users-bounces+brad.bendily=la@lists.isc.org > [mailto:bind-users-bounces+brad.bendily=la@lists.isc.org] On Behalf Of > nex6 > Sent: Monday, June 25, 2012 4:03 PM > To: bind-users@lists.isc.org > Subject: Reverse zones best practices > > > > Hi all, > > look for some info on best practices for reverse zones. I have, a pretty big > IP space and alot of reverse zones are not created. > I want to clean it up, a few people that dont really know DNS are thinking of > "super netting" eg a top level 10.0.0.0/16 sorta thing. > > but we have 100s of defined mission critical reverse zones defined at the > vlan level of 10.x.x.0/24... my thinking, would be do a discovery and create > all the /24s, even if there is like 100s. instead of the bigger super net... > > > what would be the best practice and the way to go? > > > > -Nex6 > > ___ > 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
Re: Reverse zones best practices
On 26/06/12 16:42, nex6 wrote: * Brad Bendily [2012-06-25 16:35:28 -0500]: wouldn't it be more confusing, in a big IP space with servers, desktops etc all mashed together into one zone? If you have enough hosts for this to be confusing, you have enough hosts to store the data in some master data-source and automatically generate the zone files (or dynamic updates). Don't edit zone files manually unless they're trivially small. Don't read zone files unless you're debugging. Basically: don't do this. FWIW we use one large 10.in-addr.arpa file. Likewise for our "real" /16 subnets. We don't use a different reverse zone per actual subnet - it's pointless, and limits you to byte-aligned subnets or horrible delegation tricks. ___ 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: Reverse zones best practices
Personally, I'd rather edit 1 file, than hundreds of different files. I can add the DNS entry and IP address and reload the service. No trying to figure out which file it goes in. I try to keep the file in alphabetical order which makes finding and adding entries easier. bb -Original Message- From: nex6 [mailto:b...@borg1911.com] Sent: Tuesday, June 26, 2012 10:43 AM To: Brad Bendily Cc: bind-users@lists.isc.org Subject: Re: Reverse zones best practices * Brad Bendily [2012-06-25 16:35:28 -0500]: wouldn't it be more confusing, in a big IP space with servers, desktops etc all mashed together into one zone? > I don't know about best practice in this case, but I decided to put our > reverse entries into one "super netting" file as you call it. > > We had the same problem that a lot of reverse entries were missing, so > I wrote a script to parse the forward file and create the reverse. > Then I incorporated that into my "adding a new entry" process so, I never add > a reverse entry now, the script creates it. For that matter, all of our > forward entries are in one file as well. > > I don't need to look at DNS to find my network structure. I just want DNS to > do DNS. > > bb > > > -Original Message- > From: bind-users-bounces+brad.bendily=la@lists.isc.org > [mailto:bind-users-bounces+brad.bendily=la@lists.isc.org] On > Behalf Of nex6 > Sent: Monday, June 25, 2012 4:03 PM > To: bind-users@lists.isc.org > Subject: Reverse zones best practices > > > > Hi all, > > look for some info on best practices for reverse zones. I have, a pretty big > IP space and alot of reverse zones are not created. > I want to clean it up, a few people that dont really know DNS are thinking of > "super netting" eg a top level 10.0.0.0/16 sorta thing. > > but we have 100s of defined mission critical reverse zones defined at the > vlan level of 10.x.x.0/24... my thinking, would be do a discovery and create > all the /24s, even if there is like 100s. instead of the bigger super net... > > > what would be the best practice and the way to go? > > > > -Nex6 > > ___ > 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
Re: Reverse zones best practices
* Phil Mayers [2012-06-26 16:54:55 +0100]: I am not going to be editing files by hand, we actually have a tool. I am more concerned about best practices, and how to fix the mess. eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones. from what I understand its best to just create the missing zones and fix the tools so new networks always get reverse zones created. becuase I dont think i can just create a larger /16 or /8. becuase they will overlap and create a bigger mess. -Nex6 > On 26/06/12 16:42, nex6 wrote: > >* Brad Bendily [2012-06-25 16:35:28 -0500]: > > > > > >wouldn't it be more confusing, in a big IP space with servers, > >desktops etc all mashed together into one zone? > > If you have enough hosts for this to be confusing, you have enough > hosts to store the data in some master data-source and automatically > generate the zone files (or dynamic updates). > > Don't edit zone files manually unless they're trivially small. > > Don't read zone files unless you're debugging. > > Basically: don't do this. > > FWIW we use one large 10.in-addr.arpa file. Likewise for our "real" > /16 subnets. We don't use a different reverse zone per actual subnet > - it's pointless, and limits you to byte-aligned subnets or horrible > delegation tricks. > ___ > 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
