Re: A record of domain name must be name server ?
On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: > No, what I'm saying is that if > > example.com owns an A record 203.0.113.48, and > www.example.com owns an A record 203.0.113.48, then > > where does 48.113.0.203.in-addr.arpa point? > > Some people will point it at example.com, some will point it at > www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) > If, on the other hand, www.example.com is a CNAME to example.com, then > it's crystal clear where the reverse record will point -- example.com. > There is no ambiguity or option for inconsistency. > > - Kevin > > On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: > > Hey Kevin, > > > > This is not an issue at all. > > A PTR is different then a "A" record and can be used by two reverse > > domain names and only the owner of the IP addresses space can define > > them. > > I am not sure if two PTR records for two domains will be applied to > > one IP but it is possible for two IP addresses to have the same PTR. > > > > Can we even use a CNAME as a PTR??? > > > > Eliezer > > > > On 09/11/2014 12:37 AM, Kevin Darcy wrote: > >> Also, have you considered the forward/reverse ambiguity that arises when > >> multiple owner names resolve to the same address? To which of those > >> names does the PTR point? > >> > >> - Kevin > > > > ___ > > 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 -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za smime.p7s Description: S/MIME cryptographic signature ___ 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: A record of domain name must be name server ?
On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. The same applies for all other RRs for exmaple.com Alan named crap. And that's why I also think it's better to define 'www' as A record, not as CNAME -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller ___ 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: A record of domain name must be name server ?
On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote: If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. Actually no. All other RRs are supposed to be ignored (except for RRSIG, etc) once the CNAME exists. Ie. the MX and NS RRs exist only for example.com, but not www.example.com. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com ___ 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
Promoting slave to master DNS server with dynamic updates
Hello DNS gurus, New on the list, I’ve been tasked by my manager to revamp our dns infrastructure. I think this list is the best place to get answers. Bind 9.3.6-16 running on RHEL5.7 Right now everything run’s on manually editing zone files but we have recently integrated vmware orchestrator (automatic deployment of linux vm’s) in the mix and that complicates things for automated processes. Add Autosys to this and you have one big messy DNS infrastructure and of course no team wants to change their work flows (classic). So I’ve written a basic script that would allow everyone (admin’s, vmware, autosys) to use dynamic updates with nsupdate for all tasks. Everything works dandy but a simple question remains: If the primary goes down for whatever reason, how can we quickly continue to update our DNS records on the secondary? What are the options? - Classic slave/master change manually editing the named.conf? What happens to everything in the jnl file on the master if it crashes before the dump and zone transfer? Lost? - Nsupdate special ninja trick? Read something about updating the SOA through dynamic update but didn’t fully understand that process. - Pray that we get the primary up? The last option would normally be the logical choice but like I said our DNS infrastructure is a mess and those autosys process control DNS records for their “failover” feature (yeah I know) so we need a super-lightning-fast switch if we do not want production to stop. Of course the best solution would be something automatic but I haven’t seen anything anywhere. If it’s manual so be it maybe I would be able to write a script that could be used by support and minimize human errors. I’m already at least pushing for a more recent bind version and of course if a special feature exist (maybe I’ve missed it) that provides an easier solution that would be a super argument to push for something with more features. Thanks in advance. Eric ** Ce courrier électronique, y compris les pièces jointes, est à l'attention exclusive des destinataires désignés et revêt un caractère confidentiel. Si vous recevez ce courrier électronique par erreur, merci d'en informer sans délai l'expéditeur et de supprimer son contenu et ses pièces jointes. Le contenu de ce courrier électronique ne pourrait engager la responsabilité de la Banque de France que s'il a été émis par une personne dûment habilitée agissant dans le strict cadre des fonctions auxquelles elle est employée et à des fins non étrangères à ses attributions. L'expéditeur de ce courrier électronique ne peut pas garantir la sécurité de l'acheminement par voie électronique et ne saurait dès lors encourir une quelconque responsabilité en cas d'altération de son contenu. ** This e-mail, attachments included, is intended solely for the addressees and should be considered as confidential. Should you receive this message by error, please notify the sender immediately and destroy this e-mail and its attachments. Banque de France cannot be considered as liable for the content of this message unless the sender has been duly authorized and has acted strictly in the course of his/her tasks as an employee. The sender of this e-mail cannot ensure the security of its electronic transmission and consequently will not be liable should its content be altered. ** ___ 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: A record of domain name must be name server ?
In article , Alan Clegg wrote: > On 9/10/14, 8:42 AM, Sam Wilson wrote: > > > And you could reduce maintenance very slightly by replacing > > > > www in A 75.100.245.133 > > > > with > > > > www in CNAME @ > > And now you have an MX record, 3 NS records and a bunch of other crap > associated with the WWW address. Keeping track of one extra A record > (and associated record if you go in that direction) isn't a bad thing. And the discussion went on from there. Sorry, I really didn't mean to poke a hornets' nest. > (Personal preferences, of course) Personal preference and dependent on the exact needs of the users of the data, of course. 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: A record of domain name must be name server ?
In article , Antonio Querubin wrote: > On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote: > > > If you point www CNAME @, the 'www' will have both MX and NS records same as > > example.com. Which may e.g. cause rejectd on backup MX hosts, apparently > > not designed to receive mail for www.example.com. > > Actually no. All other RRs are supposed to be ignored (except for RRSIG, > etc) once the CNAME exists. Ie. the MX and NS RRs exist only for > example.com, but not www.example.com. I think that's a misunderstanding of what Matus wrote. With separate A records then www.example.com will only have an A record. If you alias www to @ then looking up MX and NS records for www will return the ones for example.com. 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: Promoting slave to master DNS server with dynamic updates
Hi Eric, Depends on how long you can live without dynamic updates, and how many dynamic updates it's acceptable to lose in the event of a master failure. Journal files are synced every 15 minutes, so in the event of a master failure (in a single-master situation), you've lost at most 15 minutes' worth of updates. Stand up a new master (with config management software, doable in a few minutes), and you're good to go. But why have just a single master? If you're worried about the primary going down, just have a warm standby ready to go. To keep zone data in sync, you could use shared storage, a replicated database (BIND does support a database backend), or perhaps some sort of also-notify configuration. To do the failover itself, you could use something like Pacemaker/Corosync, ucarp, or similar. Just pass a VIP back/forth between the two -- your NS records would only use the VIP. The big issue I see with converting a slave to a master is that you'd have to change all of your zone definitions, change your named.conf, and do so under time pressure. Then, when the master came back online, you'd have to change your zone definitions again. With config management software, not that hard to do, but servers are cheap these days -- easier just to create a failover pair (or group) for your master, then stand up as many slaves (doing update forwarding) as you need. If you purchase a DNS appliance (Infoblox, SolidServer, Bluecat, etc.), this is how they handle things. Separate issue: you might think about trying out RHEL 6 -- it's using a much newer version of BIND which has some updated tools (particularly rndc freeze/thaw, HTTP stats interface). John On Thu, Sep 11, 2014 at 4:48 AM, wrote: > Hello DNS gurus, > > > > New on the list, I’ve been tasked by my manager to revamp our dns > infrastructure. I think this list is the best place to get answers. > > > > Bind 9.3.6-16 running on RHEL5.7 > > > > Right now everything run’s on manually editing zone files but we have > recently integrated vmware orchestrator (automatic deployment of linux > vm’s) in the mix and that complicates things for automated processes. Add > Autosys to this and you have one big messy DNS infrastructure and of course > no team wants to change their work flows (classic). > > > > So I’ve written a basic script that would allow everyone (admin’s, vmware, > autosys) to use dynamic updates with nsupdate for all tasks. Everything > works dandy but a simple question remains: > > > > If the primary goes down for whatever reason, how can we quickly continue > to update our DNS records on the secondary? What are the options? > > > > - Classic slave/master change manually editing the named.conf? > What happens to everything in the jnl file on the master if it crashes > before the dump and zone transfer? Lost? > > - Nsupdate special ninja trick? Read something about updating > the SOA through dynamic update but didn’t fully understand that process. > > - Pray that we get the primary up? > > > > The last option would normally be the logical choice but like I said our > DNS infrastructure is a mess and those autosys process control DNS records > for their “failover” feature (yeah I know) so we need a > super-lightning-fast switch if we do not want production to stop. > > > > Of course the best solution would be something automatic but I haven’t > seen anything anywhere. If it’s manual so be it maybe I would be able to > write a script that could be used by support and minimize human errors. > > I’m already at least pushing for a more recent bind version and of course > if a special feature exist (maybe I’ve missed it) that provides an easier > solution that would be a super argument to push for something with more > features. > > > > Thanks in advance. > > > > Eric > > > > ** > Ce courrier électronique, y compris les pièces jointes, est à l'attention > exclusive des destinataires désignés et revêt un caractère confidentiel. > Si vous recevez ce courrier électronique par erreur, merci d'en informer > sans délai l'expéditeur et de supprimer son contenu et ses pièces jointes. > > Le contenu de ce courrier électronique ne pourrait engager la > responsabilité de la Banque de France que s'il a été émis par une personne > dûment habilitée agissant dans le strict cadre des fonctions auxquelles > elle est employée et à des fins non étrangères à ses attributions. > > L'expéditeur de ce courrier électronique ne peut pas garantir la sécurité > de l'acheminement par voie électronique et ne saurait dès lors encourir une > quelconque responsabilité en cas d'altération de son contenu. > > ** > > This e-mail, attachments included, is intended solely for the addressees > and should be considered as confidential. > Should you receive this message by error, please notify the sender > immediately and destroy this
Re: A record of domain name must be name server ?
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. If you make "www" a CNAME to apex, then the RFCs are clear that you can't point the PTR to the "www" name. The *only*legal*choice* is to point the PTR at the apex name. You're going to get *much*more* consistent results. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what "best practices" are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. So, is it better that mail sent erroneously to www.example.com fall through the RFC 5321 algorithm and attempt to be delivered to the A record? That host is almost certainly is a *web* server and quite likely to not even be listening on port 25. After some period of time, the user ultimately gets a "connection timed out, still retrying" NDR and scratches their head trying to figure out what went wrong. Meanwhile, the sending MTA keeps on retrying, web server sees "garbage" traffic on an off-port and generates ICMP packets back to the source. In the "CNAME to @" scenario, at least the mail gets rejected promptly by a *mail* server, you have a nice clear audit trail on the server side and a meaningful error message (e.g. "I don't accept mail for the www.example.com domain") back to the user. (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote "no mail service offered here". That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the "no service" MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). Obviously, if one wants mail for example.com and www.example.com to be delivered to *different* MX targets, then "CNAME to @" isn't an option. But in the general case, where you don't want mail to www.example.com to be deliverable *at*all*, "CNAME to @" is quite a viable option; arguably, a *better* option, since the failure mode is faster and cleaner than directing MTAs to try to deliver mail, as per RFC 5321, to a web server. The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? What other RR types do you have in mind? SRV records? They have their own defined naming structure, which effectively precludes apex naming. TXT records used for SPF purposes? Worst case for that is that the same hosts trusted to send mail for example.com are also trusted to send mail for www.example.com -- but *sending* mail servers are presumably under the control (directly or indirectly) of the domain owner, so the potential for negative fallout seems rather minimal. Something else? Are you thinking that a LOC record should be differentiated between "www" and apex, if the web server is physically in a different datacenter than the corporate headquarters of the domain owner? - Kevin ___ 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: A record of domain name must be name server ?
Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the "first" record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a "A" record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ 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 ___ 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: A record of domain name must be name server ?
On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: > Mark, > Depending on implementation, a PTR RRset with multiple > records either > > -- only ever gets answered with the "first" record of the set (in > which case the second and subsequent records of the set are just a > waste of space), or > -- answers in a random, cyclic and/or round-robin fashion (in which > case, the results are non-deterministic from the standpoint of a > client, and this can cause problems and/or confusion) Last time I checked, ALL matching records are returned as a single Resource Record Set - (and in the case of DNSSEC - covered with a single signature). What the receiver does with it is up to that receiver... as you say - some of the information may be discarded. > So, although the standards allow multiple RRs, in practical terms, it > only makes sense for a PTR RRset to contain a *single* RR. I would still disagree. When there is forward<-->reverse checking, one may need the complete answer. I certainly have some processes that do an exhaustive check. - Kevin > > On 9/11/2014 3:45 AM, Mark Elkins wrote: > > > On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: > > > No, what I'm saying is that if > > > > > > example.com owns an A record 203.0.113.48, and > > > www.example.com owns an A record 203.0.113.48, then > > > > > > where does 48.113.0.203.in-addr.arpa point? > > > > > > Some people will point it at example.com, some will point it at > > > www.example.com. What you get is a mish-mosh. No consistency. > > Although I prefer the use of a CNAME solution (CNAME www.example.com to > > example.com), in the case of separate A (and ) records, one could > > point the reverse to both names. Nothing wrong with a PTR record having > > more than one answer. There is then no inconsistency, just choice. After > > all, pretty much every NS record has at least two Right-Hand-Sides > > (Answers) > > > > > > > If, on the other hand, www.example.com is a CNAME to example.com, then > > > it's crystal clear where the reverse record will point -- example.com. > > > There is no ambiguity or option for inconsistency. > > > > > > - Kevin > > > > > > On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: > > > > Hey Kevin, > > > > > > > > This is not an issue at all. > > > > A PTR is different then a "A" record and can be used by two reverse > > > > domain names and only the owner of the IP addresses space can define > > > > them. > > > > I am not sure if two PTR records for two domains will be applied to > > > > one IP but it is possible for two IP addresses to have the same PTR. > > > > > > > > Can we even use a CNAME as a PTR??? > > > > > > > > Eliezer > > > > > > > > On 09/11/2014 12:37 AM, Kevin Darcy wrote: > > > > > Also, have you considered the forward/reverse ambiguity that arises > > > > > when > > > > > multiple owner names resolve to the same address? To which of those > > > > > names does the PTR point? > > > > > > > > > > - Kevin > > > > ___ > > > > 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 > > ___ > 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 -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za smime.p7s Description: S/MIME cryptographic signature ___ 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: Promoting slave to master DNS server with dynamic updates
Hello John, Thanks for taking the time to respond. For the journal files could i force the dump every time i do an update ? nsupdate… rndc freeze/thaw boom everything in sync. I know that normaly you wait 15 minutes and that bind does that for you but we do not have that much load and it would provide us with a safety net regarding a crash? But then again I’m pretty confident a 15 minutes lost of update data is acceptable for production. For your main solution let me get this… My master with VIP gets the dynamic updates and since I have an also-notify configured he pushes the updates to my warm-stand-by server running a named in what mode? Master also? But since no one has this server configured as a resolver he doesn’t get requested until I flip the VRRP VIP and restart bind? That could very well work for us BUT what if I want to push an update to this “warm stand-by server”? Since he’s also a master it should work no? And resyncing back to first master……. This is not an easy one if we do not use shared storage. To be able to use a backend database I would have to upgrade my bind version no? It’s why people use the new map format? I’m pushing for it (want named-journalprint from 9.8 tools) and it would be nice but I’m afraid the support team will have an heart attack from too many changes at the same time (it’s a government organization so it’ss w sooo). That is also why we are running on RHEL5.7 and not 6 even if every new server deployed is on RHEL6.3. They are planning Infoblox appliances (I’m actually using those on another project) but since it’s the production servers it might take at least a year before they start the project. Dynamic updates prepares this so their world will not fall apart in one shot. Puppet is used but only on non-system related config… so I would have a tough time for them to accept this but at least I’m advancing towards my goals ☺ Thanks. Eric De : John Miller [mailto:johnm...@brandeis.edu] Envoyé : jeudi 11 septembre 2014 17:02 À : BERTHIAUME Eric (UA 2148) Objet : Re: Promoting slave to master DNS server with dynamic updates Hi Eric, Depends on how long you can live without dynamic updates, and how many dynamic updates it's acceptable to lose in the event of a master failure. Journal files are synced every 15 minutes, so in the event of a master failure (in a single-master situation), you've lost at most 15 minutes' worth of updates. Stand up a new master (with config management software, doable in a few minutes), and you're good to go. But why have just a single master? If you're worried about the primary going down, just have a warm standby ready to go. To keep zone data in sync, you could use shared storage, a replicated database (BIND does support a database backend), or perhaps some sort of also-notify configuration. To do the failover itself, you could use something like Pacemaker/Corosync, ucarp, or similar. Just pass a VIP back/forth between the two -- your NS records would only use the VIP. The big issue I see with converting a slave to a master is that you'd have to change all of your zone definitions, change your named.conf, and do so under time pressure. Then, when the master came back online, you'd have to change your zone definitions again. With config management software, not that hard to do, but servers are cheap these days -- easier just to create a failover pair (or group) for your master, then stand up as many slaves (doing update forwarding) as you need. If you purchase a DNS appliance (Infoblox, SolidServer, Bluecat, etc.), this is how they handle things. Separate issue: you might think about trying out RHEL 6 -- it's using a much newer version of BIND which has some updated tools (particularly rndc freeze/thaw, HTTP stats interface). John On Thu, Sep 11, 2014 at 4:48 AM, mailto:eric.berthiaume.exter...@banque-france.fr>> wrote: Hello DNS gurus, New on the list, I’ve been tasked by my manager to revamp our dns infrastructure. I think this list is the best place to get answers. Bind 9.3.6-16 running on RHEL5.7 Right now everything run’s on manually editing zone files but we have recently integrated vmware orchestrator (automatic deployment of linux vm’s) in the mix and that complicates things for automated processes. Add Autosys to this and you have one big messy DNS infrastructure and of course no team wants to change their work flows (classic). So I’ve written a basic script that would allow everyone (admin’s, vmware, autosys) to use dynamic updates with nsupdate for all tasks. Everything works dandy but a simple question remains: If the primary goes down for whatever reason, how can we quickly continue to update our DNS records on the secondary? What are the options? - Classic slave/master change manually editing the named.conf? What happens to everything in the jnl file on the master if it crashes before the dump and zon
Re: A record of domain name must be name server ?
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. On 11.09.14 11:20, Kevin Darcy wrote: The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. sorry, but again - you are searching for consistency somewhere, where no consistency (nor a PTR) is required. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what "best practices" are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. I haven't met a case where this level of "consistency" would be needed. I have met a case where the "only one A should point to an IP" caused troubles. your argument fails immediately when there's need for more than just A on www.example.com (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote "no mail service offered here". That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the "no service" MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). ... and this is just example of it. The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? well, me and Alan have shown examples why "www CNAME @" is not a good idea. we both also said it's personal preference. What other RR types do you have in mind? Does it matter at all? It _may_ happen, and it's the case where CNAME is not usable. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ 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: A record of domain name must be name server ?
On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote: On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. On 11.09.14 11:20, Kevin Darcy wrote: The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. sorry, but again - you are searching for consistency somewhere, where no consistency (nor a PTR) is required. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what "best practices" are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. I haven't met a case where this level of "consistency" would be needed. Needed? Is that where you're setting the bar here? A little too high, I'd say. My point is that consistency is a good thing, and the "CNAME to @" practice helps to foster that. Whether it's *needed* would be a whole other question. Somewhere between "necessary" and (what Alan called) "preferences" are these things called recommendations or best practices. I have met a case where the "only one A should point to an IP" caused troubles. Well, sure. Some names, such as zone-apex names, *cannot* own CNAME records. If example1.com and example2.com need to resolve to the same IP, then, and assuming they are both zone-apex names, you're going to have multiple As with the same RDATA, and a reverse-record ambiguity. That's unavoidable. All I'm saying, is that in the normal case, where you have an option, "CNAME to @" makes a lot of sense and should be followed. your argument fails immediately when there's need for more than just A on www.example.com If the RDATA needs to be *different* between "www" and apex, or the application/subsystem which accesses the resource makes a distinction between canonical names and aliases, sure. I'm not laying down a hard-and-fast rule. Of course there will be exceptions, where the higher-level protocols or the user requirements demand it. (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote "no mail service offered here". That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the "no service" MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). ... and this is just example of it. An example of what? Of what bad things can happen when (semi-)important things are left to mere "preference"? The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? well, me and Alan have shown examples why "www CNAME @" is not a good idea. Alan's concern was that the "www" name could get associated with record types that the DNS admin might not have expected. This is not a problem for a competent admin, who will have realistic expectations and an understanding of CNAME mechanics. You raised the possibility that a mail server might reject messages sent erroneously to "www" and I responded that if it's going to fail anyway, at least that failure mode is better than a mail server trying to deliver mail to a web server (which is what happens in the same scenario when "www" is an independent A record). You got anything else? we both also said it's personal preference. And I'm saying that's a cop-out. It should be a recommended practice -- except where there are special mitigating circumstances which make it inappropriate or unworkable -- not merely a "preference". Hair styles and musical genres are "preferences"; encouraging consistent forward/reverse mappings is something that all DNS admins have a stake in, whether they realize it or not. What other RR types do you have in mind? Does it matter at all? It _ma
Re: A record of domain name must be name server ?
On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote: we both also said it's personal preference. On 11.09.14 12:53, Kevin Darcy wrote: And I'm saying that's a cop-out. It should be a recommended practice encouraging consistent forward/reverse mappings is something that all DNS admins have a stake in, whether they realize it or not. correct reverse-forward mappings - yes. correct forward-reverse mappings - no. In zones apexes it's sometimes just impossible and I have already met people uselessly insisting on such (pardon me) shit without understanding real (and potentially much bigger) problem. It's not usable where it's not usable, of course. But, where it *is* usable, I'm just saying it's recommended, It's definitely not recommended by me. You are of course free to recommend what you choose, but I think I should warn you I'll oppose that... Did you seriously think I'd recommend something that *doesn't*work*? Please, give me a little more credit than that. I remember you from your postings here, so I really don't think you are incompetent, especially not an idiot :-) I just don't agree with this point, because I have already met people not getting this properly and insisting on something that was likely to get them into troubles bigger than with having multiple A's... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck & Porky Pig ___ 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: A record of domain name must be name server ?
In reference to the question of using a CNAME or A record for " www.example.com", it seems to me that the best solution, if we could ever get there, would be to create a new record type that means "redirect an A or lookup to this other name". Like this: example.com. IN SOA example.com. IN ANAME my.webhosting.com. www.example.com. IN CNAME my.webhosting.com. I use "ANAME" to mean "like a CNAME, but only for A and lookups", with no restrictions on other names with the same left side (except perhaps other A and records if that is necessary for technical reasons). Several DNS and hosting providers provide similar functionality, but is there any chance of widespread DNS support for something like this? Is there already and RFC for this? I find these interesting sites: http://www.dnsmadeeasy.com/services/aname-records/ http://aws.amazon.com/route53/faqs/#Supported_DNS_record_types http://blog.andrewallen.co.uk/2012/06/27/cname-is-out-hello-aname/ (This last one points out a problem with the current implementations - I think proper support in the DNS protocol would solve this.) -- Bob Harold DNS and DHCP University of Michigan ___ 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: A record of domain name must be name server ?
On 9/11/2014 11:51 AM, Mark Elkins wrote: On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the "first" record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) Last time I checked, ALL matching records are returned as a single Resource Record Set - (and in the case of DNSSEC - covered with a single signature). What the receiver does with it is up to that receiver... as you say - some of the information may be discarded. If the invoker is using the classic gethostbyaddr() interface, then it'll only see the RDATA from the "first" PTR RR, where "first" is determined by the local nameserver implementation and/or the local Operating System interface for name resolution. So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. I would still disagree. When there is forward<-->reverse checking, one may need the complete answer. I certainly have some processes that do an exhaustive check. Certainly if one gets down to the resolver-library level and grovels through all of the RRs in the Answer Section of the response packet, one could certainly care more than the typical reverse-resolving app/subsystem would. And any software that builds up certain heightened expectations is likely to complain if those expectations are not met. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a "A" record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ 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 ___ 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: A record of domain name must be name server ?
> On 9/11/2014 11:51 AM, Mark Elkins wrote: >> On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: >>> Mark, >>> Depending on implementation, a PTR RRset with multiple >>> records either >>> >>> -- only ever gets answered with the "first" record of the set (in >>> which case the second and subsequent records of the set are just a >>> waste of space), or >>> -- answers in a random, cyclic and/or round-robin fashion (in which >>> case, the results are non-deterministic from the standpoint of a >>> client, and this can cause problems and/or confusion) >> >> Last time I checked, ALL matching records are returned as a single >> Resource Record Set - (and in the case of DNSSEC - covered with a single >> signature). >> >> What the receiver does with it is up to that receiver... as you say - >> some of the information may be discarded. > If the invoker is using the classic gethostbyaddr() interface, then > it'll only see the RDATA from the "first" PTR RR, where "first" is > determined by the local nameserver implementation and/or the local > Operating System interface for name resolution. >> >>> So, although the standards allow multiple RRs, in practical terms, it >>> only makes sense for a PTR RRset to contain a *single* RR. >> I would still disagree. When there is forward<-->reverse checking, one >> may need the complete answer. I certainly have some processes that do an >> exhaustive check. > Certainly if one gets down to the resolver-library level and grovels > through all of the RRs in the Answer Section of the response packet, one > could certainly care more than the typical reverse-resolving > app/subsystem would. And any software that builds up certain heightened > expectations is likely to complain if those expectations are not met. > > - Kevin >>> On 9/11/2014 3:45 AM, Mark Elkins wrote: >>> On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: > No, what I'm saying is that if > > example.com owns an A record 203.0.113.48, and > www.example.com owns an A record 203.0.113.48, then > > where does 48.113.0.203.in-addr.arpa point? > > Some people will point it at example.com, some will point it at > www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) > If, on the other hand, www.example.com is a CNAME to example.com, then > it's crystal clear where the reverse record will point -- example.com. > There is no ambiguity or option for inconsistency. > > - Kevin > > On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: >> Hey Kevin, >> >> This is not an issue at all. >> A PTR is different then a "A" record and can be used by two reverse >> domain names and only the owner of the IP addresses space can define >> them. >> I am not sure if two PTR records for two domains will be applied to >> one IP but it is possible for two IP addresses to have the same PTR. >> >> Can we even use a CNAME as a PTR??? >> >> Eliezer >> >> On 09/11/2014 12:37 AM, Kevin Darcy wrote: >>> Also, have you considered the forward/reverse ambiguity that arises when >>> multiple owner names resolve to the same address? To which of those >>> names does the PTR point? >>> >>> - Kevin Well, this is certainly getting far away from an answer to the original qustion! Originally our web server was only available as www.adi.com. Later I noticed that a lot of sites were available without the www. So I decided to allow our web server to be available as adi.com. But I still consider www.adi.com to be the real name of the server. And I certainly can not alias adi.com to www.adi.com! Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ 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: A record of domain name must be name server ?
In message <5411bdd6.4010...@chrysler.com>, Kevin Darcy writes: > (Yes, I'm aware that there was a proposal recently discussed on the > DNSOP list for an MX-target convention to denote "no mail service > offered here". That would presumably solve the problem I cited in the > previous paragraph. But AFAIK that proposal is many years away from > widespread adoption, and even if adopted, it puts an extra burden on the > DNS admins to populate the "no service" MX record, which, again, is > going to produce inconsistent results -- some admins will remember to do > it; many won't). No, it's more like formalising existing practice. Universal adoption would be a long time off but there is a large existing base of MTA's that will do the right thing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Promoting slave to master DNS server with dynamic updates
In message , John Miller writes: > > Hi Eric, > > Depends on how long you can live without dynamic updates, and how many > dynamic updates it's acceptable to lose in the event of a master failure. > Journal files are synced every 15 minutes, so in the event of a master > failure (in a single-master situation), you've lost at most 15 minutes' > worth of updates. Stand up a new master (with config management software, > doable in a few minutes), and you're good to go. Journals are consolidated into the master file every 15 minutes. The journal exists to recover from the master dying unexpectedly. It is also used as the source of IXFR data. Additionaly notify messages are scheduled to be sent out after 3 seconds so slaves should only be a couple of seconds behind and they also write journals. With UPDATE, NOTIFY and IXFR a set of DNS servers should only loose up to a couple of seconds of transactions in the event of a master dying in such a way that the disks are unreadable. > But why have just a single master? If you're worried about the primary > going down, just have a warm standby ready to go. To keep zone data in > sync, you could use shared storage, a replicated database (BIND does > support a database backend), or perhaps some sort of also-notify > configuration. To do the failover itself, you could use something like > Pacemaker/Corosync, ucarp, or similar. Just pass a VIP back/forth between > the two -- your NS records would only use the VIP. > > The big issue I see with converting a slave to a master is that you'd have > to change all of your zone definitions, change your named.conf, and do so > under time pressure. Then, when the master came back online, you'd have to > change your zone definitions again. With config management software, not > that hard to do, but servers are cheap these days -- easier just to create > a failover pair (or group) for your master, then stand up as many slaves > (doing update forwarding) as you need. If you purchase a DNS appliance > (Infoblox, SolidServer, Bluecat, etc.), this is how they handle things. > > Separate issue: you might think about trying out RHEL 6 -- it's using a > much newer version of BIND which has some updated tools (particularly rndc > freeze/thaw, HTTP stats interface). > > John > > On Thu, Sep 11, 2014 at 4:48 AM, > > wrote: > > > Hello DNS gurus, > > > > > > > > New on the list, I=E2=80=99ve been tasked by my manager to revamp our dns > > infrastructure. I think this list is the best place to get answers. > > > > > > > > Bind 9.3.6-16 running on RHEL5.7 > > > > > > > > Right now everything run=E2=80=99s on manually editing zone files but we = > have > > recently integrated vmware orchestrator (automatic deployment of linux > > vm=E2=80=99s) in the mix and that complicates things for automated proces= > ses. Add > > Autosys to this and you have one big messy DNS infrastructure and of cour= > se > > no team wants to change their work flows (classic). > > > > > > > > So I=E2=80=99ve written a basic script that would allow everyone (admin= > =E2=80=99s, vmware, > > autosys) to use dynamic updates with nsupdate for all tasks. Everything > > works dandy but a simple question remains: > > > > > > > > If the primary goes down for whatever reason, how can we quickly continue > > to update our DNS records on the secondary? What are the options? > > > > > > > > - Classic slave/master change manually editing the named.conf? > > What happens to everything in the jnl file on the master if it crashes > > before the dump and zone transfer? Lost? > > > > - Nsupdate special ninja trick? Read something about updating > > the SOA through dynamic update but didn=E2=80=99t fully understand that p= > rocess. > > > > - Pray that we get the primary up? > > > > > > > > The last option would normally be the logical choice but like I said our > > DNS infrastructure is a mess and those autosys process control DNS record= > s > > for their =E2=80=9Cfailover=E2=80=9D feature (yeah I know) so we need a > > super-lightning-fast switch if we do not want production to stop. > > > > > > > > Of course the best solution would be something automatic but I haven=E2= > =80=99t > > seen anything anywhere. If it=E2=80=99s manual so be it maybe I would be= > able to > > write a script that could be used by support and minimize human errors. > > > > I=E2=80=99m already at least pushing for a more recent bind version and o= > f course > > if a special feature exist (maybe I=E2=80=99ve missed it) that provides a= > n easier > > solution that would be a super argument to push for something with more > > features. > > > > > > > > Thanks in advance. > > > > > > > > Eric > > > > > > > > ** > > Ce courrier =C3=A9lectronique, y compris les pi=C3=A8ces jointes, est =C3= > =A0 l'attention > > exclusive des destinataires d=C3=A9sign=C3=A9s et rev=C3=AAt un caract=C3= > =A8re confident
RE: Promoting slave to master DNS server with dynamic updates
> -Original Message- > From: bind-users-boun...@lists.isc.org [mailto:bind-users- > boun...@lists.isc.org] On Behalf Of Mark Andrews > Sent: Friday, 12 September 2014 8:58 AM > To: John Miller > Cc: Bind Users Mailing List > Subject: Re: Promoting slave to master DNS server with dynamic updates > > Journals are consolidated into the master file every 15 minutes. > The journal exists to recover from the master dying unexpectedly. > It is also used as the source of IXFR data. Additionaly notify > messages are scheduled to be sent out after 3 seconds so slaves > should only be a couple of seconds behind and they also write > journals. > > With UPDATE, NOTIFY and IXFR a set of DNS servers should only loose > up to a couple of seconds of transactions in the event of a master > dying in such a way that the disks are unreadable. Also worth noting that there is a configuration item that can change the notify delay down from 3 seconds if it is so desired. If you have a low volume of updates, you may be able to get away with making it '0', but if you have any volume, you really want it to be a few seconds. Stuart ___ 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
BIND 9.10.1rc2 won't build on FreeBSD 10-STABLE
I can't build BIND 9.10.1rc2 on recent FreeBSD 10-STABLE. I have tried on both i386 and amd64 variants of the operating system. BIND 9.10.1rc1 builds fine, as did the beta releases. Failure looks like this: making all in /build/bind/bind-9.10.1rc2/bin/python make[3]: don't know how to make dnssec-checkds. Stop make[3]: stopped in /build/bind/bind-9.10.1rc2/bin/python *** Error code 1 Stop. make[2]: stopped in /build/bind/bind-9.10.1rc2/bin *** Error code 1 Stop. make[1]: stopped in /build/bind/bind-9.10.1rc2 *** Error code 1 Tested on: FreeBSD 10.1-PRERELEASE #0 r271181: Sat Sep 6 14:12:21 AEST 2014 i386 FreeBSD 10.1-PRERELEASE #0 r271289: Tue Sep 9 15:20:15 AEST 2014 amd64 Note: BIND 9.10.1rc1 builds happily on the above. Note: BIND 9.10.1rc2 builds happily on FreeBSD 9.3-RELEASE amd64 Perhaps rc2 introduced something that upsets bmake (the make(1) used in FreeBSD 10)? -- John Marshall pgpLMA5yg5m_j.pgp Description: PGP signature ___ 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: BIND 9.10.1rc2 won't build on FreeBSD 10-STABLE
On Fri, Sep 12, 2014 at 09:11:08AM +1000, John Marshall wrote: > I can't build BIND 9.10.1rc2 on recent FreeBSD 10-STABLE. > I have tried on both i386 and amd64 variants of the operating system. > BIND 9.10.1rc1 builds fine, as did the beta releases. Based on the failure being in bin/python, I suppose it was this: 3946. [cleanup] Improved "configure" search for a python interpreter. [RT #36992] I'm guessing your system doesn't have a python interpreter, but configure got confused into thinking it does. If I'm right, then installing python ought to make the build work, for the time being. We'll address the problem before final release. Do you still have your config.log? May I see it? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
