Re: Question about visibility
On Thu, 11 Oct 2018 15:39:55 -0400 Barry Margolin wrote: > In article , > Dennis Clarke wrote: > > > On 10/11/2018 03:21 PM, Leonardo Rodrigues wrote: > > > Em 11/10/18 16:13, Barry Margolin escreveu: > > >> > > >> If you accidentally, or someone else intentionally, create a > > >> link to the site that uses the IP and put it on a web page that > > >> Google can get to, it will probably find the page. > > >> > > >> > > > > > > robots.txt, on your website root, is your friend. Simply > > > deny web crawling on it, and you're (probably) done. > > > > > > > If you believe robots.txt means anything at all. > > Google is known to obey it, and the question was about avoiding > getting your site indexed by Google. > > Of course, that doesn't mean someone won't find the site on their > own. If the link to it is on some other page that isn't blocked by > robots.txt, someone might stuble across that page and then click on > the link. > > But if you're mainly worried about someone googling the words that > are on your website and Google sending them to the development > version instead of the production version, you're pretty safe. > > Actually, DNS has very little impact on this at all. AFAIK, Google > doesn't crawl DNS, it just crawls web pages and follows links. My > company's development server is in DNS, and it's not firewalled (we > all work from our homes, there's no company network to restrict > access with), but I've never heard of anyone accidentally being > directed there by Google, because we don't publish links to this > server. > robot.txt is suppose to govern whats indexed... not sure how well its followed nowadays but thats the process for it. ___ 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: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 09:50:31 -0600
Grant Taylor via bind-users wrote:
> On 10/26/2018 08:52 AM, Kevin Darcy wrote:
> > My basic rule of thumb is: use forwarding when connectivity
> > constraints require it. Those constraints may be architectural,
> > e.g. a multi-tiered, multi-layer network for security purposes, or
> > may be the result of screwups or unintended consequences, e.g. a
> > routing blackhole. Use forwarding to get around those blockages.
>
> Agreed all around.
>
> Is there any reason to not prefer to slave the zone instead of
> forwarding? I would think that would provide better performance
> results and lessen the requirement for always on nature of the
> forwarded target.
its a netscaler load balancer, the zone name is the zone that the
netscaler "owns", so it can create LB records off of it that it owns and
can control.
so we cant slave it, it had to be a forward. i called this out years
ago when this was being built and said it was a bad idea and that we
should do proper delegation and plan it out. by the time everything was
said and done it was, said it was to late to change it... to work with
or around it doh...
>
> > Now, if one thinks one can use forwarding for
> > efficiency/performance ("forward first") as opposed to using it for
> > connectivity ("forward only"), then do so based on *documented* ,
> > *observed* evidence, not just on assumptions or conjecture. A lot
> > of folks just take for granted that forwarding to a rich cache will
> > speed up their lookups. Maybe it will, maybe it won't -- MEASURE IT.
> >
> > Also, bear in mind that while forwarding to a rich cache may help
> > your *best* case, and maybe your *average* case, it may hurt your
> > *worst* case, since in the case of a cache miss, you have your
> > wasted forwarding attempt *plus* however long it takes to fetch the
> > data yourself. Your worst case is going to be the one that causes
> > apps to time out, support calls, tickets, everyone blaming the DNS
> > infrastructure, etc. You've been warned.
>
> Duly noted. Thank you for articulating.
>
>
>
___
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: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 10:52:17 -0400
Kevin Darcy wrote:
> My basic rule of thumb is: use forwarding when connectivity
> constraints require it. Those constraints may be architectural, e.g.
> a multi-tiered, multi-layer network for security purposes, or may be
> the result of screwups or unintended consequences, e.g. a routing
> blackhole. Use forwarding to get around those blockages.
>
> Now, if one thinks one can use forwarding for efficiency/performance
> ("forward first") as opposed to using it for connectivity ("forward
> only"), then do so based on *documented* , *observed* evidence, not
> just on assumptions or conjecture. A lot of folks just take for
> granted that forwarding to a rich cache will speed up their lookups.
> Maybe it will, maybe it won't -- MEASURE IT.
>
> Also, bear in mind that while forwarding to a rich cache may help your
> *best* case, and maybe your *average* case, it may hurt your *worst*
> case, since in the case of a cache miss, you have your wasted
> forwarding attempt *plus* however long it takes to fetch the data
> yourself. Your worst case is going to be the one that causes apps to
> time out, support calls, tickets, everyone blaming the DNS
> infrastructure, etc. You've been warned.
>
>
> - Kevin
kinda my points exactly. while forwarding works, and is a useful tool.
it is not a delegation or an authoritative zone. so, building critical
name spaces with it should be avoid unless you have to. it not
something you plan upfront with. thats just silly.
>
> On Fri, Oct 26, 2018 at 10:41 AM Bob Harold
> wrote:
>
> >
> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost wrote:
> >
> >> Hi All,
> >>
> >> have two questions first, I am not a huge fan of using forwarding
> >> zones and our "load balancing" team, has there zone delegated to
> >> them in a way that needs an internal forward zone to work properly
> >> on the inside and not rely on on internet POP.
> >>
> >> I want to move a core namespace to the load balancer but i want
> >> them to let me assign them a new zone thats internally
> >> authoritative and use it as the LB domain.
> >>
> >> which would be:
> >> cname name.domain.com -> newname.newzone.domain.com
> >>
> >> they want:
> >> cname name.domain.com -> newname.oldzone.domain.com
> >>
> >> old zone is directly delagated from outside to them so we need an
> >> internal forward zone for it. i dont want to rely on that.
> >>
> >> any thoughts on this? what can i use to present to management to
> >> win this?
> >>
> >
> > The users should never see the domain that the CNAME points at, it
> > is just an internal name used by DNS. If they can change where "
> > newname.oldzone.domain.com" points more easily than "
> > newname.newzone.domain.com" then they might have a valid reason to
> > want it. Otherwise, newname.newzone.domain.com will be a faster
> > and more reliable choice.
> >
> > Definitely avoid forwarding when possible. It causes slower
> > lookups and more points of failure. (There will occasional be
> > times when it has some advantage, or requirement.)
> >
> > --
> > Bob Harold
> >
> >
> >>
> >> next, we where a bind shop but switched to infoblox for some stuff
> >> and now out grew it. and are going back to bind.
> >>
> >> but we started using the dns firewall part of it and they actually
> >> really liked it. any ideas for domain blacklisting? via some sort
> >> of feed etc? what is everyone doing for that sort of thing?
> >>
> >> thanks
> >>
> >> -N6Ghost
> >> ___
> >> 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
> >
>
___
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: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 09:46:39 -0600 Grant Taylor via bind-users wrote: > On 10/26/2018 01:08 AM, N6Ghost wrote: > > maybe its just old habits, > > Fair enough. I know that I have plenty of my own old (¿bad?) habits > too. > > > i think its a bad idea to build your infrastructure in a way the > > needs forward zones to work. not when you can build it with proper > > delegation. > > > i just think when building namespaces proper delegation should be > > used and forward zones should be avoided if you can. > > Ah. > > I see forward zones, and slaving, as tools to help enable restricted > environments work. Specifically where there is proper delegation as > seen by the larger organization and / or the Internet. I've had a > few departments where they were not allowed to access anything > outside their network. So their local DNS server (running on a > multihomed bastion) would slave or forward zones from the larger > organizational namespace. The limitation was imposed by the small > department, not an issue with the overall namespace. > > > i agree with this, forward is a use it you must, avoid if you can. but valable tool for all sorts of wacky use cases. but if your planning out critical namespaces... you should not PLAN on forward zones. unless you have to. thats just a micky mouse way of doing it. your just assuming to much with forward zones. ___ 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: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 10:40:40 -0400 Bob Harold wrote: > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost wrote: > > > Hi All, > > > > have two questions first, I am not a huge fan of using forwarding > > zones and our "load balancing" team, has there zone delegated to > > them in a way that needs an internal forward zone to work properly > > on the inside and not rely on on internet POP. > > > > I want to move a core namespace to the load balancer but i want > > them to let me assign them a new zone thats internally > > authoritative and use it as the LB domain. > > > > which would be: > > cname name.domain.com -> newname.newzone.domain.com > > > > they want: > > cname name.domain.com -> newname.oldzone.domain.com > > > > old zone is directly delagated from outside to them so we need an > > internal forward zone for it. i dont want to rely on that. > > > > any thoughts on this? what can i use to present to management to win > > this? > > > > The users should never see the domain that the CNAME points at, it is > just an internal name used by DNS. If they can change where " > newname.oldzone.domain.com" points more easily than " > newname.newzone.domain.com" then they might have a valid reason to > want it. Otherwise, newname.newzone.domain.com will be a faster and > more reliable choice. I agree with this, basically the deal is we have a parent who owns our primary DNS zone which we hang off of. there DNS NS is outside of our network. so, all of our zones are delegated to us. (we have a pretty big DNS infrastructure) and we then create our own namespaces, zones whatever we need. we have our own public and internal NS. My issue with the load balancer is they went around that and had the parent delegate to them... and had us, create forward to them. to prevent lookups from relying on need to always go to parent. if we where authoritative no outside lookup would be needed. I think thats a bad way to do it. and I want to avoid, having our critical namespaces (ldap and ldaps) use it like that. > > Definitely avoid forwarding when possible. It causes slower lookups > and more points of failure. (There will occasional be times when it > has some advantage, or requirement.) > ___ 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
2 Questions - forward zone and DNS firewalling
Hi All, have two questions first, I am not a huge fan of using forwarding zones and our "load balancing" team, has there zone delegated to them in a way that needs an internal forward zone to work properly on the inside and not rely on on internet POP. I want to move a core namespace to the load balancer but i want them to let me assign them a new zone thats internally authoritative and use it as the LB domain. which would be: cname name.domain.com -> newname.newzone.domain.com they want: cname name.domain.com -> newname.oldzone.domain.com old zone is directly delagated from outside to them so we need an internal forward zone for it. i dont want to rely on that. any thoughts on this? what can i use to present to management to win this? next, we where a bind shop but switched to infoblox for some stuff and now out grew it. and are going back to bind. but we started using the dns firewall part of it and they actually really liked it. any ideas for domain blacklisting? via some sort of feed etc? what is everyone doing for that sort of thing? thanks -N6Ghost ___ 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: 2 Questions - forward zone and DNS firewalling
On Fri, 26 Oct 2018 17:37:47 +
Joe Dahlquist wrote:
> N6Ghost,
>
> Re: DNS Firewall options on bind, a shameless plug for Threatstop.com
> and the first you should investigate.
>
> Other sources of RPZ with quality data you can look at: Farsight,
> SURBL, Spamhaus
>
> Regards,
> Joe Dahlquist
>
>
>
>
>
>
> On 10/26/18, 9:49 AM, "bind-users on behalf of N6Ghost"
>
> wrote:
>
> >On Fri, 26 Oct 2018 10:52:17 -0400
> >Kevin Darcy wrote:
> >
> >> My basic rule of thumb is: use forwarding when connectivity
> >> constraints require it. Those constraints may be architectural,
> >> e.g. a multi-tiered, multi-layer network for security purposes, or
> >> may be the result of screwups or unintended consequences, e.g. a
> >> routing blackhole. Use forwarding to get around those blockages.
> >>
> >> Now, if one thinks one can use forwarding for
> >> efficiency/performance ("forward first") as opposed to using it
> >> for connectivity ("forward only"), then do so based on
> >> *documented* , *observed* evidence, not just on assumptions or
> >> conjecture. A lot of folks just take for granted that forwarding
> >> to a rich cache will speed up their lookups. Maybe it will, maybe
> >> it won't -- MEASURE IT.
> >>
> >> Also, bear in mind that while forwarding to a rich cache may help
> >> your *best* case, and maybe your *average* case, it may hurt your
> >> *worst* case, since in the case of a cache miss, you have your
> >> wasted forwarding attempt *plus* however long it takes to fetch
> >> the data yourself. Your worst case is going to be the one that
> >> causes apps to time out, support calls, tickets, everyone blaming
> >> the DNS infrastructure, etc. You've been warned.
> >>
> >>
> >> - Kevin
> >
> >kinda my points exactly. while forwarding works, and is a useful
> >tool. it is not a delegation or an authoritative zone. so, building
> >critical name spaces with it should be avoid unless you have to. it
> >not something you plan upfront with. thats just silly.
> >
> >
> >>
> >> On Fri, Oct 26, 2018 at 10:41 AM Bob Harold
> >> wrote:
> >>
> >> >
> >> > On Thu, Oct 25, 2018 at 4:34 PM N6Ghost
> >> > wrote:
> >> >> Hi All,
> >> >>
> >> >> have two questions first, I am not a huge fan of using
> >> >> forwarding zones and our "load balancing" team, has there zone
> >> >> delegated to them in a way that needs an internal forward zone
> >> >> to work properly on the inside and not rely on on internet POP.
> >> >>
> >> >> I want to move a core namespace to the load balancer but i want
> >> >> them to let me assign them a new zone thats internally
> >> >> authoritative and use it as the LB domain.
> >> >>
> >> >> which would be:
> >> >> cname name.domain.com -> newname.newzone.domain.com
> >> >>
> >> >> they want:
> >> >> cname name.domain.com -> newname.oldzone.domain.com
> >> >>
> >> >> old zone is directly delagated from outside to them so we need
> >> >> an internal forward zone for it. i dont want to rely on that.
> >> >>
> >> >> any thoughts on this? what can i use to present to management to
> >> >> win this?
> >> >>
> >> >
> >> > The users should never see the domain that the CNAME points at,
> >> > it is just an internal name used by DNS. If they can change
> >> > where " newname.oldzone.domain.com" points more easily than "
> >> > newname.newzone.domain.com" then they might have a valid reason
> >> > to want it. Otherwise, newname.newzone.domain.com will be a
> >> > faster and more reliable choice.
> >> >
> >> > Definitely avoid forwarding when possible. It causes slower
> >> > lookups and more points of failure. (There will occasional be
> >> > times when it has some advantage, or requirement.)
> >> >
> >> > --
> >> > Bob Harold
Thanks will check it out!
> >> >
> >> >
> >> >>
> >> >> next, we where a bind shop but switched to infoblox for some
> >> >> stuff and now out grew it. and are goin
Re: 2 Questions - forward zone and DNS firewalling
On Thu, 25 Oct 2018 15:57:48 -0600 Grant Taylor via bind-users wrote: > On 10/25/18 2:34 PM, N6Ghost wrote: > > I want to move a core namespace to the load balancer but i want > > them to let me assign them a new zone thats internally > > authoritative and use it as the LB domain. > > > > which would be: > > cname name.domain.com -> newname.newzone.domain.com > > > > they want: > > cname name.domain.com -> newname.oldzone.domain.com > > > > old zone is directly delagated from outside to them so we need an > > internal forward zone for it. i dont want to rely on that. > > Can I ask why you don't like forwarded zones? > > Is it a possibility to slave the zone off of them instead of > forwarding to them? > > > any thoughts on this? what can i use to present to management to win > > this? > > I think it comes down to pros and cons of each: existing zone + > forwarders vs new zone. > > IMHO it's perfectly fine to have dislikes. You just need to be able > to explain them and / or set them aside if someone explains their > position better. > > > next, we where a bind shop but switched to infoblox for some stuff > > and now out grew it. and are going back to bind. > > > > but we started using the dns firewall part of it and they actually > > really liked it. any ideas for domain blacklisting? via some sort of > > feed etc? what is everyone doing for that sort of thing? > > Response Policy Zone(s) are what you want. I thought that's how > Infoblox did it themselves. Maybe they were using the newer Response > Policy Service. - It's my understanding that the RPS API is open > and documented. It's just that there aren't any Open Source / free what about nonfree feeds? > RPS services. > > IMHO: RPS is similar to milter for Sendmail or WCCP for caching > proxies. > > > ___ 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: 2 Questions - forward zone and DNS firewalling
On Thu, 25 Oct 2018 15:57:48 -0600 Grant Taylor via bind-users wrote: > On 10/25/18 2:34 PM, N6Ghost wrote: > > I want to move a core namespace to the load balancer but i want > > them to let me assign them a new zone thats internally > > authoritative and use it as the LB domain. > > > > which would be: > > cname name.domain.com -> newname.newzone.domain.com > > > > they want: > > cname name.domain.com -> newname.oldzone.domain.com > > > > old zone is directly delagated from outside to them so we need an > > internal forward zone for it. i dont want to rely on that. > > Can I ask why you don't like forwarded zones? maybe its just old habits, i think its a bad idea to build your infrastructure in a way the needs forward zones to work. not when you can build it with proper delegation. i just think when building namespaces proper delegation should be used and forward zones should be avoided if you can. > > Is it a possibility to slave the zone off of them instead of > forwarding to them? > > > any thoughts on this? what can i use to present to management to win > > this? > > I think it comes down to pros and cons of each: existing zone + > forwarders vs new zone. > > IMHO it's perfectly fine to have dislikes. You just need to be able > to explain them and / or set them aside if someone explains their > position better. > > > next, we where a bind shop but switched to infoblox for some stuff > > and now out grew it. and are going back to bind. > > > > but we started using the dns firewall part of it and they actually > > really liked it. any ideas for domain blacklisting? via some sort of > > feed etc? what is everyone doing for that sort of thing? > > Response Policy Zone(s) are what you want. I thought that's how > Infoblox did it themselves. Maybe they were using the newer Response > Policy Service. - It's my understanding that the RPS API is open > and documented. It's just that there aren't any Open Source / free > RPS services. > > IMHO: RPS is similar to milter for Sendmail or WCCP for caching > proxies. > > > ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On 12/30/19 1:13 PM, Grant Taylor via bind-users wrote: On 12/30/19 1:34 PM, N6Ghost wrote: 1: is the IP space delegated or not? What is delegated IP space in this context? Are you referring to a separate prefix that is routed to the customer? This ref to the IP space that you OWN. In large enterprises we own and buy very large blocks /16, to /24s. and in our DNS NS we add the reverse zones for them internal and external. depending on where they are used. -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On 12/30/19 7:26 PM, Grant Taylor via bind-users wrote: On 12/30/19 6:22 PM, N6Ghost wrote: but generally you acquire IP space in blocks not single address's. and those blocks are what you use to build your internal and external reverse zone files. Agreed. But you wouldn't be using RFC 2317 Classless IN-ADDR.ARPA delegation because the reverse DNS for the entire block containing your IPs would be delegated to you. I'm under the impression that the OP is more in the sub /24 realm. yea, probably. i have not dealt with sub /24 nets like that in many years and back then shit was very hacky the way we did it. now, we have reverse zones for all the 192.168.0.0/16, and 10 nets. and all of our public IP space thats allocated to us, divided to internal and public views. -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On Monday, December 30, 2019 1:15:48 PM PST Grant Taylor via bind-users wrote: > On 12/30/19 1:42 PM, N6Ghost wrote: > > delegations are always by block... ie /20, /24, /25 etc > > I feel like there is term conflation. > > To me: > · Delegations are DNS and are done on the dot boundary. > · Routes are done on the block boundary. > > The two can be related, but quite distinct. yes, true. but generally you acquire IP space in blocks not single address's. and those blocks are what you use to build your internal and external reverse zone files. -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On Friday, December 27, 2019 10:01:31 AM PST Reindl Harald wrote: > Am 27.12.19 um 18:58 schrieb Matus UHLAR - fantomas: > >>>> The only thing that I saw was a slip in that there is something > >>>> outside the local DNS server that needs to be configured for reverse > >>>> DNS. > >> > >> Am 27.12.19 um 18:48 schrieb Matus UHLAR - fantomas: > >>> I think that it should be either change local DNS or call ISP to > >>> change it, > >>> not both at once. Having both usually creates/hides different kinds of > >>> problems > > > > On 27.12.19 18:50, Reindl Harald wrote: > >> says who? > > > > common sense I'd say... > > > >> in our /24 range 1-99 are public servers, the rest is internal > >> infrastructure and workstations and there is no point to have that > >> mapping public > > > > Either you have DNS records or you have not. If you have them, either you > > manage them, or you fetch part of it from customer > > have you ever heard about internal and external views? I think there is a couple of things going on here. 1: is the IP space delegated or not? if it is, then there needs to be a local reverse zone. 2: if the ISP is involved then maybe they own the IP space and its not really delegated. or maybe its shared space don't know. 3: using views are great for splitting IP or fwd zones between internal hosts and ext hosts. but you still need to own the zones. i would say have a conversation with the ISP about the reverse zone, and ask specifically how its setup and why. and if you own the IP space or not and what the delegation is like. -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On Monday, December 30, 2019 11:07:36 AM PST Matus UHLAR - fantomas wrote: > >>I think that it should be either change local DNS or call ISP to > >>change it, not both at once. Having both usually creates/hides > >>different kinds of problems. > > > >Yes, ideally the configuration lives in one place. Multi-master is > >always problematic. Particularly for day to day operations. > > > >Initial configuration is another story. That will likely involve > >configuration at both ends. I.e. ISP delegating to customer and > >customer configuring their name server appropriately. > > > >On 12/27/19 10:48 AM, Matus UHLAR - fantomas wrote: > >>the ISP should the client what zone to configure, > > On 27.12.19 13:03, Grant Taylor via bind-users wrote: > >Did you mean that to be "the ISP should *tell* the client what zone to > >configure"? > > of course. > > >>e.g. pasteur-cayenne.246.2.186.in-addr.arpa and they put RFC > >>2317-like CNAME delegations to that. > > > >Maybe. Maybe not. I'd likely have stern words with an ISP if they > >tried to dictate to me how I configured my DNS zones and servers. > > I'd tell you that I want the DNS properly working on both sides :) > > >I can see the ISP informing the customer of what options they support > >and then the customer choosing from that set. > > > >About the only reason that I'll accept from an ISP for them trying to > >dictate what zone is used is them admitting that their configuration > >management system having limitations and not supporting what I want. > > Also depends on who's more knowlegeable about DNS. > > >>Yes, it can work, but I personally don't like setting up multiple > >>reverse subdomains like this. I believe configuring single domain > >>for multiple records is theway to go. > > > >As an ISP, you're only working with one domain, namely the associated > >in-addr.arpa domain. So why do you care how many domains the client > >needs to configure on their server? > > > >Your desire to slave transfer not withstanding. But even that is your > >desire. > > as long as an ISP wants to be slave for every domain on client's server, > every domain there means one zone definition at ISP. as DNS manager I > wanted to have all domains properly working. And since we had much more DNS > servers than most of our customers (one or two), I expected that > > >Your desire to have a slave copy means that you are beholden to how > >the domain owner wants to configure things. If that's one domain, > >fine. If that's multiple domains, then so be it. > > > >>in any case, if the OP needs to fixing things on the local side AND > >>to call ISP to change it, something is broken, or at least > >>inefficiently implemented. > > > >I don't know if "broken" is how I'd describe this. I think the OP is > >still in the early set up phase. Thus why it's normal that he needs > >to call the ISP to get them to do the initial configuration. > > mostly depends on the current setup and real reason why the OP needed to > configure his master AND to call the ISP... if the ISP is the delagator, then yes they need to say what and how the IP zones are delegated. thats how it works... -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On Friday, December 27, 2019 9:49:10 AM PST Reindl Harald wrote: > Am 27.12.19 um 16:58 schrieb Grant Taylor via bind-users: > > On 12/27/19 7:04 AM, Matus UHLAR - fantomas wrote: > >> they configure it for fetching from your servers. > > > > I do object to this part of the statement. > > > > This seems to imply that the ISP is a secondary DNS server and doing > > zone transfers off of their customer > > in the real world they just delegate the reverse-zone to your nameserver > like it#s done for our /24 range for years > > no need for zone transfers > > if the ISP is willing to do and if you really own a large enough range > that it makes sense is a different question, for just 3 random addresses > it is unlikely to happen yes, this. if they have some hacky thing going where they own the reverse and are forcing you to secondary it ask they why. thats very hacky if there is no reason to do it. -N6Ghost ___ 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: Problem to transfer reverse zone DNS on secondary DNS servers
On Friday, December 27, 2019 12:22:55 PM PST Reindl Harald wrote: > Am 27.12.19 um 21:06 schrieb Grant Taylor via bind-users: > >> if the ISP is willing to do and if you really own a large enough range > >> that it makes sense is a different question, for just 3 random > >> addresses it is unlikely to happen > > > > Agreed. > > > > But I will still ask the ISP to delegate the IPs to me as that's what I > > prefer > > nobody out there will delegate single /255 ip's > ___ delegations are always by block... ie /20, /24, /25 etc -N6Ghost ___ 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
