Discussion:
BIND, systemd-resolved, and nscd
Add Reply
f***@ofb.net
2018-09-12 20:14:40 UTC
Reply
Permalink
Raw Message
Hello Arch General,

I hope this is the right mailing list; I'm a new subscriber.

After a recent upgrade I found that DNS broke in two different ways on
my computer,

1. BIND enabled DNSSEC by default, causing hostname resolution to stop
working (for some reason my home wireless router broke the "trust
chain", which I know nothing about)

https://kb.isc.org/article/AA-01636/81/BIND-9.13.2-Release-Notes.html

The default setting for dnssec-validation is now auto, which
activates DNSSEC validation using the IANA root key.

I had to add "dnssec-validation yes;" to /etc/named.conf. I have a
forwarding BIND configuration so that Spamassassin's DNSBL queries can
be handled specially.

2. There is a bug relating to systemd-resolved and nscd. It is also
related to a decision made by systemd-resolved maintainers to never
use DNS to resolve single-label hostnames:

https://github.com/systemd/systemd/issues/2514
https://sourceware.org/bugzilla/show_bug.cgi?id=23546

This was very confusing to me because I had assumed that my computers
were still using DNS to find each other via my router, as I had not
changed anything related to that configuration.

While trying to debug these problems, I remember checking the "Arch
Linux - News" page (https://www.archlinux.org/news/) but I didn't find
anything relevant there.

I wonder it makes sense to expect that changes which break hostname
resolution on home networks, or which may require reconfiguration on
common setups to maintain existing functionality, should be announced
on this page. I would be in favor of that but I don't know how I would
phrase the announcement. For what it's worth, I was not able to find
help with these problems on #archlinux or the BBS or superuser.com.
Any thoughts?

Best wishes,

Frederick
Pallissard, Matthew
2018-09-13 13:49:45 UTC
Reply
Permalink
Raw Message
Post by f***@ofb.net
I had to add "dnssec-validation yes;" to /etc/named.conf. I have a
Are you sure you didn't want these values?

dnssec-enable no;
dnssec-validation no;

Matt Pallissard
f***@ofb.net
2018-09-13 19:31:28 UTC
Reply
Permalink
Raw Message
Post by Pallissard, Matthew
Post by f***@ofb.net
I had to add "dnssec-validation yes;" to /etc/named.conf. I have a
Are you sure you didn't want these values?
dnssec-enable no;
dnssec-validation no;
Well, prior to the recent BIND releease, the default had been "yes" -
which means "no" for me. I just wanted to make it behave the same way
as it had before. I don't know if there's a difference between that
and the options you suggested:

ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#Configuration_File_Grammar

If set to auto, DNSSEC validation is enabled, and a default trust
anchor for the DNS root zone is used. If set to yes, DNSSEC
validation is enabled, but a trust anchor must be manually
configured using a trusted-keys or managed-keys statement. The
default is yes.

Here's my SU question BTW:

https://superuser.com/questions/1349213/how-to-debug-local-named-with-broken-dnssec

Matthew, do you know more about this stuff or were you just as
confused as I was by the "yes means no" syntax? I didn't necessarily
want to get into that in this thread, although it could potentially be
something for us to complain to the BIND maintainers about. (viz.,
people thinking they had enabled dnssec-validation when in fact they
hadn't)

Frederick
Pallissard, Matthew
2018-09-19 16:31:13 UTC
Reply
Permalink
Raw Message
Post by f***@ofb.net
Post by Pallissard, Matthew
Post by f***@ofb.net
I had to add "dnssec-validation yes;" to /etc/named.conf. I have a
Are you sure you didn't want these values?
dnssec-enable no;
dnssec-validation no;
Well, prior to the recent BIND releease, the default had been "yes" -
which means "no" for me. I just wanted to make it behave the same way
as it had before. I don't know if there's a difference between that
ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#Configuration_File_Grammar
If set to auto, DNSSEC validation is enabled, and a default trust
anchor for the DNS root zone is used. If set to yes, DNSSEC
validation is enabled, but a trust anchor must be manually
configured using a trusted-keys or managed-keys statement. The
default is yes.
https://superuser.com/questions/1349213/how-to-debug-local-named-with-broken-dnssec
Matthew, do you know more about this stuff or were you just as
confused as I was by the "yes means no" syntax? I didn't necessarily
want to get into that in this thread, although it could potentially be
something for us to complain to the BIND maintainers about. (viz.,
people thinking they had enabled dnssec-validation when in fact they
hadn't)
Frederick
A few things.

1. Google's public DNS servers are DNSSEC validating forwarders, your router evidently is not.
2. I'm not sure what you mean by the yes-means-no syntax. The URL that you provided seems pretty cut and dry.
Post by f***@ofb.net
dnssec-enable yes; # returns dnssec resource records
dnssec-enable nol # does not, validation cannot be performed
dnssec-validation no; #does not validate
dnssec-validation yes; #does validate (requires a trusted-keys or managed-keys statement, which you DO NOT have in your example)
dnssec-validation autol #does validate (uses trusted/manged-keys blocks or the trust anchor compiled into named)
TL;DR If you want to 'make it behave the same way as it had before', it sounds like you need to disable DNSSEC validation.
If you want to make it honour DNSSEC set dnssec-validation to 'auto' or 'yes' with the related keys statement.


Matt Pallissard
f***@ofb.net
2018-09-19 18:22:16 UTC
Reply
Permalink
Raw Message
Post by Pallissard, Matthew
Post by f***@ofb.net
Well, prior to the recent BIND releease, the default had been "yes" -
which means "no" for me.
...
2. I'm not sure what you mean by the yes-means-no syntax. The URL that you provided seems pretty cut and dry.
...
Post by f***@ofb.net
dnssec-validation yes; #does validate (requires a trusted-keys or managed-keys statement, which you DO NOT have in your example)
I think you just answered your own question. Except perhaps that the
word "requires" is a bit misleading, because when you don't have that
statement then 'named' still starts up and responds to queries, it
just doesn't do DNSSEC validation. So 'named' itself does not
"require" it.

Your first email wondered if I didn't want "no" instead of "yes" and I
was explaining that they are the same for my configuration, which is
based on the default named.conf that ships with bind, which doesn't
have a trusted-keys or managed-keys statement. In other words, they
are also the same for the default configuration. As I explained, "yes"
was the default validation setting and I was trying to restore the old
behavior, which doesn't do validation. I was wondering why you had
asked this question, if you had some kind of expert knowledge that I
didn't have - but it looks like we are learning about this together,
since you are referring to the URL I provided.

The purpose of my original post was to ask whether this sort of change
in the defaults of an important package belongs in the Arch news page
(https://www.archlinux.org/news/), but I haven't received an answer
yet. I'm open to advice on question-asking or if this is the right
forum or whatever.

Thanks,

Frederick
Pallissard, Matthew
2018-09-20 03:37:57 UTC
Reply
Permalink
Raw Message
Post by f***@ofb.net
Post by Pallissard, Matthew
Post by f***@ofb.net
Well, prior to the recent BIND releease, the default had been "yes" -
which means "no" for me.
...
2. I'm not sure what you mean by the yes-means-no syntax. The URL that you provided seems pretty cut and dry.
...
Post by f***@ofb.net
dnssec-validation yes; #does validate (requires a trusted-keys or managed-keys statement, which you DO NOT have in your example)
I think you just answered your own question. Except perhaps that the
word "requires" is a bit misleading, because when you don't have that
statement then 'named' still starts up and responds to queries, it
just doesn't do DNSSEC validation. So 'named' itself does not
"require" it.
Fair point, maybe raise that on the ISC list.
Post by f***@ofb.net
Your first email wondered if I didn't want "no" instead of "yes" and I
was explaining that they are the same for my configuration, which is
based on the default named.conf that ships with bind, which doesn't
have a trusted-keys or managed-keys statement. In other words, they
are also the same for the default configuration. As I explained, "yes"
was the default validation setting and I was trying to restore the old
behavior, which doesn't do validation. I was wondering why you had
asked this question, if you had some kind of expert knowledge that I
didn't have - but it looks like we are learning about this together,
since you are referring to the URL I provided.
Yea I ran into this as well. I just disabled dnssec locally and relied on my forwarders to handle it. Your question prompted me to look into it a bit more.
Post by f***@ofb.net
The purpose of my original post was to ask whether this sort of change
in the defaults of an important package belongs in the Arch news page
(https://www.archlinux.org/news/), but I haven't received an answer
yet. I'm open to advice on question-asking or if this is the right
forum or whatever.
I could be wrong bit I don't think so, it's an upstream change of a default value.

Matt Pallissard

Loading...