Okay, I'm getting error messages from named/BIND. They read
That definetly doesn't look good. It is related to dnssec, so something with the DNS security does not work.
Searching the internet for the message does not find anything useful - it seems nobody else gets that error. But I get it on every machine where a named is running, no matter how it is configured.
Looking into the code - a comment in the code just says
when the error message is triggered. Well then, who wouldn't have imagined that?
Now given that
So, friendly&helpful as I am, I decided to report the matter to the developers and ask why it happens (and why it apparently happens only here).
The answer I got, was this:
Alright, far enough. I won't start by sending unsolicited bulk data to anywhere, but it's fine when requested.
So I collected these checkconfs, added the full logfile data, and sent that back.
And now I got a different reply:
So, what do we have here? I think we have the perfect scheme for 100% bugfree software:
So now, we have already seen many approaches how the Ivory-Tower-League (aka the developer elite) achieves to separate themselves from the ordinary user-plebs and to disable working communication with the inferiors.
But this one I couldn't have imagined. It is full of elegance, truly recommendable, and actually brilliant. This would indeed fit into modern-day business-consulting.
OTOH, from the user perspective, concerning support... Stop, lets clarify this: this is NOT about "support". Support is something different, and as long as you don't pay for the service, you cannot expect support. Support is also not an issue, because you have the sourcecode and could always DIY - to just make the thing somehow work.
So this is about something different: this is about the developers not allowing people to tell them where their crap is broken.
Now this is understandable: all people want to feel great, and don't like critical statements - and defect reports are in fact critical statements - even worse: critical statements from the user-plebs!
But then, covering this with a statement like "we are not able to support you" and trying to turn things around that way - well, that is simply a lie.
named[2453]: dnssec: warning: managed-keys-zone: Failed to create fetch for DNSKEY update
That definetly doesn't look good. It is related to dnssec, so something with the DNS security does not work.
Searching the internet for the message does not find anything useful - it seems nobody else gets that error. But I get it on every machine where a named is running, no matter how it is configured.
Looking into the code - a comment in the code just says
Code:
/*
* Something is broken.
*/
when the error message is triggered. Well then, who wouldn't have imagined that?
Now given that
- my nameservers work just fine, otherwise, and
- according to the docs there is no special configuration needed for DNSSEC, and basic recursing operation all should work with the defaults,
So, friendly&helpful as I am, I decided to report the matter to the developers and ask why it happens (and why it apparently happens only here).
The answer I got, was this:
We can’t really help you if you don’t share any details of your installation
and configuration (hint: You can use `named-checkconf -px` to scrub the
configuration).
So far, you shared a **single line** from the log and nothing else.
Alright, far enough. I won't start by sending unsolicited bulk data to anywhere, but it's fine when requested.
So I collected these checkconfs, added the full logfile data, and sent that back.
And now I got a different reply:
----- The following addresses had permanent fatal errors -----
<ondrej@isc.org>
(reason: 550 5.7.1 Blocked by SpamAssassin)
<bind-users@lists.isc.org>
(reason: 550 5.7.1 Blocked by SpamAssassin)
----- Transcript of session follows -----
... while talking to mx.pao1.isc.org.:
>>> DATA
<<< 550 5.7.1 Blocked by SpamAssassin
554 5.0.0 Service unavailable
So, what do we have here? I think we have the perfect scheme for 100% bugfree software:
- require your users to send defects to a mailinglist
- inform your users that defect reports will only be considered when they contain detailed configuration data
- configure the spamblocker on the mailinglist so that it rejects mails with such detailed configuration data.
So now, we have already seen many approaches how the Ivory-Tower-League (aka the developer elite) achieves to separate themselves from the ordinary user-plebs and to disable working communication with the inferiors.
But this one I couldn't have imagined. It is full of elegance, truly recommendable, and actually brilliant. This would indeed fit into modern-day business-consulting.
OTOH, from the user perspective, concerning support... Stop, lets clarify this: this is NOT about "support". Support is something different, and as long as you don't pay for the service, you cannot expect support. Support is also not an issue, because you have the sourcecode and could always DIY - to just make the thing somehow work.
So this is about something different: this is about the developers not allowing people to tell them where their crap is broken.
Now this is understandable: all people want to feel great, and don't like critical statements - and defect reports are in fact critical statements - even worse: critical statements from the user-plebs!
But then, covering this with a statement like "we are not able to support you" and trying to turn things around that way - well, that is simply a lie.