Backwards incompatible change: PowerDNS (2.9.x to 3.1.x)

[Gary T. Giesen]

Fancy record support (ie URL) records are also no longer supported in
3.x. Some people's businesses depend on these features, and if they
inadvertently upgrade it will cause downtime for zones using those
records. Now they've been forced to exclude pdns in their yum configs
so they can run a yum update without breaking their systems...

This completely defeats the purpose of having an enterprise OS with a
stable set of packages...

You could have always made the new package available as "pdns3" so
that people who want to upgrade can...

GTG

Sent from my iPhone

On 2012-11-27, at 3:15 PM, "James Findley" <james.findley at gmx.com> wrote:

>
>  > On 27.11.2012 12:50, James Findley wrote:
>  >
>  > > That is untrue. If your configuration contains the 'wildcards' parameter, powerdns 3.0+ will not start, but it's a supported and valid option for powerdns 2.9. And as it doesn't check the config when restarting, this will cause downtime for unwary users who upgrade.
>  >
>  > Hi James,
>  >
>  > please note:
>  >
>  > http://doc.powerdns.com/changelog.html
>  >
>  > The pdns.conf 'wildcards'-setting did not do anything in 3.0, so it was
>  > removed.
>
>
> I'm afraid you've rather missed the point.  The previous version was 2.9,
> where the wildcards setting *DID* do something, and something important at that.
> You pushed a direct upgrade from 2.9 to 3.1 that meant that anyone with
> this setting in theit pdns.conf would have found their server broken by this change.
>
> There has never been a pdns-3.0 in EPEL so this changelog is not relevent.
>
>  >
>  > > That's again not true. If you have customers with zones without SOAs, these work in 2.9 - they do not work at all in 3.0+.
>  >
>  > This is a non-RFC-compliant setup. Zones without SOA record is something
>  > that you should never do!
>  >
>  > RFC 1035:
>  > [...] 2. Exactly one SOA RR should be present at the top of the zone.
>
>
> The RFC says "should" not "must" - but this is irrellevent.
> Customers can't always be relied upon to produce perfectly RFC
> compliant zones, and a zone that worked fine in 2.9 and doesn't
> work at all in 3.1 is another very important reason why you should
> not have pushed this change.
>
>
>  >
>  > > I appreciate the work you do to maintain this package in EPEL, but particularly with packages like DNS servers extreme care needs to be taken when deciding to upgrade to a different major version.
>  > >
>  > > The powerdns documentation contains numerous warnings that it's not a trivial upgrade - these warnings should have been heeded, especially as the number of bugfixes are fairly small - it's mostly a feature upgrade which should not be a priority for EPEL.
>  >
>  > I agree with you fully that we need to be careful with such upgrades.
>  >
>  > It isn't really a feature upgrade. The main reason for this decision was
>  > the security aspect to make sure that we get security patches for
>  > PowerDNS until 2020.
>  >
>  > I can't justify using an old version excluding future security patches.
>  > The upgrade effort is minimal in relation to the security aspect for the
>  > next 8 years. For example, the bind version shipped with RHEL 6.0 was
>  > 9.7.0-P2 and the latest 6.3 release contains bind 9.8.2 RC1. (Yes, I
>  > know this is only a minor upgrade)
>
>
> Had there been a critical security vulerability that this change fixed,
> you'd have had a better argument.  There currently isn't one to the
> best of my knowledge.
>
> There may be a pressing security vulnerability that's not trivially
> backported to 2.9... or there might not.  As of this moment this seems
> to me like a gratuitous incompatible change that has been pushed without
> proper consideration.
>
> I don't really want to argue this back and forth - I don't think there's
> a huge amount that can be done to fix it at this point, so creating a flame-
> fest isn't productive.
> I would like maintainers to realise that while your efforts are really appreicated
> that doing things like this massively reduces the value of EPEL - if everyone
> has to do this much diligence checking every update we may as well all roll
> our own RPMs.
>
> Thanks for listening,
>
> James
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list