Re: BIND through COPR after CentOS

2021-01-04 Thread Petr Menšík 
Hello Bruce.

Since this version is exactly the same piece what I am working on for
RHEL, what would be advantage of using Oracle Linux for it?

The same version would land to CentOS Stream and into Red Hat Enterprise
Linux later. We try hard to make no regressions on any update. ISC's
maintained tests help us a lot, but we have also bunch of our own tests.
I would like to thank ISC for their great test coverage support, it is
outstanding in my opinion. All tests apply to any version released even
to CentOS Stream, just like for RHEL. The only difference for RHEL would
be, such changes would be parked in our repository for several months
until minor update release.

Anyway, Oracle seems to be only recompilation of package I prepare for
RHEL and then falls to CentOS. Is there any advantage receiving it from
them, where no feedback to actual maintainers can be provided? Would it
make it more stable in any way? I admit I don't understand motivation
for it. It seems more misunderstanding what CentOS 8 Stream is supposed
to be. Can I clarify it somehow?

Best Regards,
Petr

On 12/18/20 8:12 PM, Bruce Johnson wrote:
> I’m evaluating Oracle Linux to replace CentOS right now for other uses, which 
> Oracle pinky-swears will always be free (beer and speech); it’s essentially 
> another RHEL clone, with some additional stuff for oracle in the repo. I 
> think it’ll end up replacing our CentOS 8 upgrade of ours.
> 
> Available Packages
> Name : bind
> Epoch: 32
> Version  : 9.11.20
> Release  : 5.el8
> Architecture : src
> Size : 8.1 M
> Source   : None
> Repository   : ol8_baseos_latest
> Summary  : The Berkeley Internet Name Domain (BIND) DNS (Domain Name 
> System) server
> URL  : http://www.isc.org/products/BIND/
> License  : MPLv2.0
> Description  : BIND (Berkeley Internet Name Domain) is an implementation of 
> the DNS
>  : (Domain Name System) protocols. BIND includes a DNS server 
> (named),
>  : which resolves host names to IP addresses; a resolver library
>  : (routines for applications to use when interfacing with DNS); 
> and
>  : tools for verifying that the DNS server is operating properly.
> 
> 
> On Dec 18, 2020, at 11:15 AM, John Thurston 
> mailto:john.thurs...@alaska.gov>> wrote:
> 
> We have been using the ISC COPR packages for BIND on CentOS. With the demise 
> of CentOS, we (along with a few other people on the planet) need to consider 
> where we will move our applications.
> 
> We have been completely happy with the packages provided by ISC through COPR. 
> Does anyone want to offer up other linux distributions on which they have had 
> unqualified success with these same packages?
> 
> 
> --
> --
> Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: check-names conflicts with SPF macro definition

2021-01-04 Thread Daniel Stirnimann 
Hello Mark,

the "exists" [1] macro results in A queries and the zone contains A
records. That's why the check-names processing applied.

Thanks for the hint regarding the nameserver hostnames.

Daniel

[1] https://tools.ietf.org/html/rfc7208#section-5.7

On 04.01.21 10:33, Mark Andrews wrote:
> SPF records are TXT record which are NOT subject to check-names processing.
> 
> If you created a seperate zone use nameservers that DO NOT live within the 
> zone.
> ns1._spf.switch.ch is NOT a legal hostname as it is not LDH.
> 
>> On 4 Jan 2021, at 20:01, Daniel Stirnimann  
>> wrote:
>>
>> Hello all,
>>
>> I changed SPF for switch.ch to use SPF macros (RFC 7208). I wanted to
>> use the "_spf" label but bind9 check-names complained with a "bad owner
>> name (check-names)" message.
>>
>> I have now used "spf" instead of "_spf", e.g. exists:%{ir}.spf.switch.ch
>>
>> I didn't want to disable check-names for switch.ch because of this
>> conflict. However, SPF record publishing is generally recommended to use
>> the "_spf" subdomain which is not possible in this case.
>>
>> I guess, the only alternative would have been to make "_spf.switch.ch"
>> its own zone and set check-names for this zone statement to "ignore". Or
>> would this be a good reasons to loosen the check-names rules in bind9?
>>
>> Thanks,
>> Daniel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: check-names conflicts with SPF macro definition

2021-01-04 Thread Mark Andrews 
SPF records are TXT record which are NOT subject to check-names processing.

If you created a seperate zone use nameservers that DO NOT live within the zone.
ns1._spf.switch.ch is NOT a legal hostname as it is not LDH.

> On 4 Jan 2021, at 20:01, Daniel Stirnimann  
> wrote:
> 
> Hello all,
> 
> I changed SPF for switch.ch to use SPF macros (RFC 7208). I wanted to
> use the "_spf" label but bind9 check-names complained with a "bad owner
> name (check-names)" message.
> 
> I have now used "spf" instead of "_spf", e.g. exists:%{ir}.spf.switch.ch
> 
> I didn't want to disable check-names for switch.ch because of this
> conflict. However, SPF record publishing is generally recommended to use
> the "_spf" subdomain which is not possible in this case.
> 
> I guess, the only alternative would have been to make "_spf.switch.ch"
> its own zone and set check-names for this zone statement to "ignore". Or
> would this be a good reasons to loosen the check-names rules in bind9?
> 
> Thanks,
> Daniel
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

check-names conflicts with SPF macro definition

2021-01-04 Thread Daniel Stirnimann 
Hello all,

I changed SPF for switch.ch to use SPF macros (RFC 7208). I wanted to
use the "_spf" label but bind9 check-names complained with a "bad owner
name (check-names)" message.

I have now used "spf" instead of "_spf", e.g. exists:%{ir}.spf.switch.ch

I didn't want to disable check-names for switch.ch because of this
conflict. However, SPF record publishing is generally recommended to use
the "_spf" subdomain which is not possible in this case.

I guess, the only alternative would have been to make "_spf.switch.ch"
its own zone and set check-names for this zone statement to "ignore". Or
would this be a good reasons to loosen the check-names rules in bind9?

Thanks,
Daniel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users