Re: Enable systemd hardening options for named

[Petr Menšík]

Hi, More below

Dne 1.2.2018 v 01:36 Ludovic Gasc napsal(a):
> 2018-01-31 21:47 GMT+01:00 Petr Menšík  >:
> 
> Hi Ludovic,
> 
> 
> Hi Petr,
> 
> I didn't expect to discuss directly with the Fedora maintainer :-)
> Just in case you are at DNS devroom of FOSDEM this
> Sunday: https://fosdem.org/2018/schedule/track/dns/
> 
> I'm interested in to meet you.

Unfortunately I were not at FOSDEM, so that was not possible. I hope
next time I will be there. I will have to watch the recorded videos.

> 
> Anyway, about SELinux discussion, I'm convinced that SELinux proposes
> better security features than systemd before it exists.
> However, in Debian universe, no MAC is enabled by default: Some extra
> default config in systemd will be easier to integrate in the mainstream
> distribution than a MAC enabled by default :-)
> Moreover, from my small experience of CentOS, I already seen several
> times in setup documentation of several proprietary software for CentOS
> that the first step is to disable SELinux first before the installation.
There is clear reason why we support our packages and not the third
party ones. This is the best reason for that. I admit maintaining
working SELinux labels is difficult for a person who has minimal
experience with it. I am not quite good myself in fact. However
disabling SELinux at all is the worst practice possible.

I hope there is nothing like that on any Fedora or Red Hat Enterprise
Linux guides. Switch to permissive mode, use audit2allow, create local
exceptions (semanage), switch back to enforcing. That is what we recommend.
> 
> It's up to you to decide what you want to integrate in systemd config
> file by default.
> For me, it might be complementary: In fact, it might be interesting to
> know the pourcentage of CentOS on production without SELinux.
Interesting question. I have no idea myself, but I would like to get
such answer as well. I will ask if there are such statistics.
>  
> 
> 
> On Fedora, CAP_DAC_OVERRIDE is not granted to bind, because it might be
> dangerous feature. CAP_DAC_READ_SEARCH is a little bit safer, but still
> might be unnecessary. It should be possible to run even without it with
> careful permission configuration of keys and config files.
> 
> I think CAP_SYS_RESOURCE is required to automatically adjust maximum
> number of file descriptors/sockets from configuration. But I am not 100%
> about that.
> 
> 
> For this part, you can define values in systemd config file: LimitNOFILE
Sure, thanks for looking this up. There are 4 limit options in
named.conf for this. files, datasize, coresize, stacksize. I guess all
these values can be configured from systemd instead. In fact, according
to ns_os_adjustnofile of named/main.c, this is always set to
LimitNOFILE=infinity after named starts. At least on my Fedora build of
9.11.2, it is always logged:
"adjusted limit on open files from 2048 to 1048576"
Increasing limit from the service unit will prevent logging this. I
think I want increased limit more obvious.

Unless you want to disable options from named.conf, CAP_SYS_RESOURCE
should be provided.
>  
> 
> I recently rejected request to change from Type=forking. Has anyone got
> a patch for bind to support Type=notice systemd service? I would like to
> get rid of pid file handling, but Type=simple will not work for me.
> 
> 
> Type=notify you mean ? Yes, it would be interesting.
Sure, sorry for the typo.
>  
> 
> 
> I am not sure if PrivateDevices=yes can be used by default on Fedora. We
> package also named-pkcs11 version, which should be able to access
> hardware tokens and accelerators. I doubt it would work with that. I
> want them to still work if they worked until now. Normal variant might
> use that, chroot already has its own empty /dev.
> 
> There is some nice page about this on Fedora wiki:
> https://fedoraproject.org/wiki/Packaging:Systemd#Fields_to_avoid
> 
> 
> 
> Thanks for the link, it's interesting.
>  
> 
> Dne 15.1.2018 v 18:58 Ludovic Gasc napsal(a):
> > Hi,
> >
> > (Not sure it's the right mailing-list to discuss about this, tell
> me if
> > it's another one)
> >
> > For your information, systemd offers several options to increase the
> > security of each daemon based on cgroups, like Docker or rkt.
> > For
> >
> example: 
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Capabilities
> 
> 
> >
> > This approach permits to keep the classical Linux distribution daemons
> > with simple maintenance actions via apt or yum + the same container
> > security as a Docker image.
> >
> > A discussion has already started on Debian tracker:
>

Re: disable dnssec for particular domain

[Michelle Konzack]

Am DATE hackte AUTHOR in die Tasten: Ray Bellis
> Perhaps, although I'm not sure why given that .eu is signed with NSEC3
> and opt-out.> On 06/02/2018 16:31, Matus UHLAR - fantomas wrote:
>
>> what's the difference, when the domain doesn't exist?
>>
>> is it because .eu is signed?
>
> Are you *sure* that the domain doesn't now actually exist in the DNS?

Can it be, that when they have registered the domain and entered no DNS
in the form, so that the registrar has assigned the obligatory 3 NS?

> Ray

Thanks in advance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

___
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: disable dnssec for particular domain

[Michelle Konzack]

Hello Matus,

Am 2018-02-06 hackte Matus UHLAR - fantomas in die Tasten:
>>Am 2018-02-06 hackte Matus UHLAR - fantomas in die Tasten:
>>> our customer uses a domain that is registered, but hidden
>>> (doesn't exist in DNS).
>
> On 06.02.18 18:24, Michelle Konzack wrote:
>>I hope you know what are you doing, because the DNS MUST exist!
>>Please read the general conditions for the EU Domain Registry!
>
> if the domain gets delisted, it's their problem.
> for now it exists in internal network.

OK, however, the .eu Registry is very picky...
I know several domains which where registered trough WHOIS annonymiser
and the .eu Registry has unregistered them.

I have several .eu Domains on my name in behalf of my customers which
was the only possibility for the customers not being known in public, but
is officially not legal...

Maybe you should inform your customers about it.

But what about puting

example.eu
www.example.eu

into the DNS and then use another hostname or a subdomain for the
communication?

To prevent, beeing captured/spidered by some bots, I use at my ISP
per server only one IP and associate it with a fqdn like
 and the bots can get the server ony by IP
which default to a big middle-finger.  The realdomain is a CNAME to the
FQDN of the server and can not more be found.

If you now use a random TLD with nice SLD and have this in your
"private" NS, nobody will get the domain and spider it against your
will.

I have this setup now which a buch of domains and since last year,
I got now access I do not like...

> don't ask me, it's the customer...

Hmmm.

> what's the difference, when the domain doesn't exist?

You can avoid anything and can do everything of you manage your own NS

> is it because .eu is signed?

Yes.

Thanks in advance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

___
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: disable dnssec for particular domain

[Ray Bellis]

On 06/02/2018 16:31, Matus UHLAR - fantomas wrote:

> what's the difference, when the domain doesn't exist?
> 
> is it because .eu is signed?

Perhaps, although I'm not sure why given that .eu is signed with NSEC3
and opt-out.

Are you *sure* that the domain doesn't now actually exist in the DNS?

Ray

___
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: disable dnssec for particular domain

[Matus UHLAR - fantomas]

Am 2018-02-06 hackte Matus UHLAR - fantomas in die Tasten:

our customer uses a domain that is registered, but hidden
(doesn't exist in DNS).


On 06.02.18 18:24, Michelle Konzack wrote:

I hope you know what are you doing, because the DNS MUST exist!
Please read the general conditions for the EU Domain Registry!


if the domain gets delisted, it's their problem.
for now it exists in internal network.


The domain is used by multiple organizations and we are required to
forward
lookups for the domain to foreign internal servers.


WHY register an .eu Domain at all?


don't ask me, it's the customer...


The problem is, that parent domain (.eu) indicates that the domain is to
be
signed and since default bind installation validates DNSSEC, lookups are
refused:


Forget about this and use your own private TLD


what's the difference, when the domain doesn't exist?

is it because .eu is signed?

--
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.
I intend to live forever - so far so good. 
___

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: disable dnssec for particular domain

[Reindl Harald]

Am 06.02.2018 um 17:24 schrieb Michelle Konzack:

Good evening,

Am 2018-02-06 hackte Matus UHLAR - fantomas in die Tasten:

Hello,

our customer uses a domain that is registered, but hidden
(doesn't exist in DNS).


I hope you know what are you doing, because the DNS MUST exist!
Please read the general conditions for the EU Domain Registry!


The domain is used by multiple organizations and we are required to
forward
lookups for the domain to foreign internal servers.


WHY register an .eu Domain at all?

If it is for internal use, setup your bind9 to serv the TLD .uhlar
and config all your clients to use your bin9 as there NS.

I do this with a bunch of TLDs which are only known to me and not a
singel bot is aware of it...


because the days that you can be sure that tomorrow not some idiot 
registry starts with .uhlar as world-wide available TLD are gone and 
then you have a problem if your need to access a real-world domain in 
that TLD

___
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: disable dnssec for particular domain

[Michelle Konzack]

Good evening,

Am 2018-02-06 hackte Matus UHLAR - fantomas in die Tasten:
> Hello,
>
> our customer uses a domain that is registered, but hidden
> (doesn't exist in DNS).

I hope you know what are you doing, because the DNS MUST exist!
Please read the general conditions for the EU Domain Registry!

> The domain is used by multiple organizations and we are required to
> forward
> lookups for the domain to foreign internal servers.

WHY register an .eu Domain at all?

If it is for internal use, setup your bind9 to serv the TLD .uhlar
and config all your clients to use your bin9 as there NS.

I do this with a bunch of TLDs which are only known to me and not a
singel bot is aware of it...

> The problem is, that parent domain (.eu) indicates that the domain is to
> be
> signed and since default bind installation validates DNSSEC, lookups are
> refused:

Forget about this and use your own private TLD

Thanks in advance

-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

___
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: disable dnssec for particular domain

[Matus UHLAR - fantomas]

On 06/02/2018 16:00, Matus UHLAR - fantomas wrote:

our customer uses a domain that is registered, but hidden
(doesn't exist in DNS).

The domain is used by multiple organizations and we are required to forward
lookups for the domain to foreign internal servers.

The problem is, that parent domain (.eu) indicates that the domain is to be
signed and since default bind installation validates DNSSEC, lookups are
refused:


On 06.02.18 16:08, Ray Bellis wrote:

The statements above are mutually contradictory.

If the domain is in use by multiple organisations, which of them put the
DS record in the .eu zone?  If it doesn't exist in the DNS then there
can be no DS record.

Or is it the case that perhaps that the parent .eu zone is actually
denying the existence of that zone?


yes - as I stated above, it's hidden from the world.

I was apparently wrong with saying about it to be signed.


--
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.
I drive way too fast to worry about cholesterol. 
___

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: disable dnssec for particular domain

[Tony Finch]

Matus UHLAR - fantomas  wrote:
>
> Is it currently possible to avoid validating this particular domain?

BIND 9.11 has support for negative trust anchors, but they are supposed to
be used as a temporary workaround to allow time for breakage to be fixed -
you'll probably find that the NTA support is a bit awkward for a permament
exclusion.

Since this is a multi-organization private zone, it would be easier to get
the DS record removed from the .eu parent so that you don't have to
implement a workaround. The other blessed option is to distribute a trust
anchor for the private zone, but that's even more faff than NTAs.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Northerly 4 or 5 at first in southeast, otherwise 6 to gale 8,
occasionally severe gale 9 in south, backing westerly or northwesterly 4 or 5
later in northwest. Moderate or rough at first in southeast, otherwise very
rough or high. Squally showers. Good, occasionally poor.
___
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: disable dnssec for particular domain

[Ray Bellis]

On 06/02/2018 16:00, Matus UHLAR - fantomas wrote:
> Hello,
> 
> our customer uses a domain that is registered, but hidden
> (doesn't exist in DNS).
> 
> The domain is used by multiple organizations and we are required to forward
> lookups for the domain to foreign internal servers.
> 
> The problem is, that parent domain (.eu) indicates that the domain is to be
> signed and since default bind installation validates DNSSEC, lookups are
> refused:

The statements above are mutually contradictory.

If the domain is in use by multiple organisations, which of them put the
DS record in the .eu zone?  If it doesn't exist in the DNS then there
can be no DS record.

Or is it the case that perhaps that the parent .eu zone is actually
denying the existence of that zone?

Ray

___
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: disable dnssec for particular domain

[Reindl Harald]

Am 06.02.2018 um 17:00 schrieb Matus UHLAR - fantomas:

our customer uses a domain that is registered, but hidden
(doesn't exist in DNS).

The domain is used by multiple organizations and we are required to forward
lookups for the domain to foreign internal servers.

The problem is, that parent domain (.eu) indicates that the domain is to be
signed and since default bind installation validates DNSSEC, lookups are
refused:


why does the parent domain indicate that?
DNSSEC is per domain and not per TLD

Feb  6 15:49:36 mon named[30183]: validating @0xf4806910: testa.eu MX: 
got insecure response; parent indicates it should be secure


Is it currently possible to avoid validating this particular domain?

can I do anything other on my side than disabling DNSSEC validation at all?

I have bind9.8, going to upgrade to 9.9.5
(could probably go to 9.11 if needed)

___
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

disable dnssec for particular domain

[Matus UHLAR - fantomas]

Hello,

our customer uses a domain that is registered, but hidden
(doesn't exist in DNS).

The domain is used by multiple organizations and we are required to forward
lookups for the domain to foreign internal servers.

The problem is, that parent domain (.eu) indicates that the domain is to be
signed and since default bind installation validates DNSSEC, lookups are
refused:

Feb  6 15:49:36 mon named[30183]: validating @0xf4806910: testa.eu MX: got 
insecure response; parent indicates it should be secure

Is it currently possible to avoid validating this particular domain?

can I do anything other on my side than disabling DNSSEC validation at all?

I have bind9.8, going to upgrade to 9.9.5
(could probably go to 9.11 if needed)

--
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.
Eagles may soar, but weasels don't get sucked into jet engines. 
___

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: Issue running "dig txt rs.dns-oarc.net" on 9.12

[NNEX Support]

[…]
If you want to understand why your resolver is failing, again I'd have a look 
at the 'resolver' log channel.  It should have some detail about what's 
resulting in the SERVFAIL message.
[…]

I took a look at the ‘resolver’ log channel.  I didn’t find any useful 
information there, just:

fetch: rs.dns-oarc.net/TXT
fetch: sns-pb.isc.org/A
fetch: ns.isc.afilias-nst.info/A
fetch: net/DS
fetch: dns-oarc.net/DS
fetch: net/DNSKEY

I started trying different releases and found this query works consistently for 
me all the way up to bind-9.12.0rc1. As soon as I try bind-9.12.0rc3 the 
queries start failing. I’m using the exact same config and server for both the 
working rc1 and not working rc3 (both complied from source). Any thoughts on 
any differences between RC1 and RC3 that might explain this or any other logs I 
should be checking?

The ‘resolver’ log channel on rc1 (which works) shows:

fetch: rs.dns-oarc.net/TXT
fetch: sns-pb.isc.org/A
fetch: ns.isc.afilias-nst.info/A
fetch: net/DS
fetch: dns-oarc.net/DS
fetch: net/DNSKEY
fetch: rs.dns-oarc.net/DS
fetch: dns-oarc.net/DNSKEY
fetch: rst.x487.rs.dns-oarc.net/TXT
fetch: rst.x461.x487.rs.dns-oarc.net/TXT
fetch: rst.x466.x461.x487.rs.dns-oarc.net/TXT

Looking at the ‘dnssec’ log channel I see this on RC1:

validating rs.dns-oarc.net/CNAME: starting
validating rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating net/DS: starting
validating net/DS: attempting positive response validation
validating net/DS: keyset with trust secure
validating net/DS: verify rdataset (keyid=41824): success
validating net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net'
validating dns-oarc.net/DS: starting
validating dns-oarc.net/DS: attempting positive response validation
validating net/DNSKEY: starting
validating net/DNSKEY: attempting positive response validation
validating net/DNSKEY: verify rdataset (keyid=35886): success
validating net/DNSKEY: marking as secure (DS)
validating dns-oarc.net/DS: in fetch_callback_validator
validating dns-oarc.net/DS: keyset with trust secure
validating dns-oarc.net/DS: resuming validate
validating dns-oarc.net/DS: verify rdataset (keyid=25733): success
validating dns-oarc.net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/DS: starting
validating rs.dns-oarc.net/DS: attempting negative response validation
  validating dns-oarc.net/SOA: starting
  validating dns-oarc.net/SOA: attempting positive response validation
validating dns-oarc.net/DNSKEY: starting
validating dns-oarc.net/DNSKEY: attempting positive response validation
validating dns-oarc.net/DNSKEY: verify rdataset (keyid=20899): success
validating dns-oarc.net/DNSKEY: marking as secure (DS)
  validating dns-oarc.net/SOA: in fetch_callback_validator
  validating dns-oarc.net/SOA: keyset with trust secure
  validating dns-oarc.net/SOA: resuming validate
  validating dns-oarc.net/SOA: verify rdataset (keyid=12093): success
  validating dns-oarc.net/SOA: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/DS: in authvalidated
validating rs.dns-oarc.net/DS: resuming nsecvalidate
  validating rs.dns-oarc.net/NSEC: starting
  validating rs.dns-oarc.net/NSEC: attempting positive response validation
  validating rs.dns-oarc.net/NSEC: keyset with trust secure
  validating rs.dns-oarc.net/NSEC: verify rdataset (keyid=12093): success
  validating rs.dns-oarc.net/NSEC: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/DS: in authvalidated
validating rs.dns-oarc.net/DS: looking for relevant NSEC
validating rs.dns-oarc.net/DS: nsec proves name exists (owner) data=0
validating rs.dns-oarc.net/DS: resuming nsecvalidate
validating rs.dns-oarc.net/DS: nonexistence proof(s) found
validating rs.dns-oarc.net/CNAME: in dsfetched2: ncache nxrrset
validating rs.dns-oarc.net/CNAME: marking as answer (dsfetched2)
validating rst.x476.rs.dns-oarc.net/CNAME: starting
validating rst.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'dns-oarc.net'
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'rs.dns-oarc.net'
validating rst.x476.rs.dns-oarc.net/CNAME: marking as answer (proveunsecure (4))
validating rst.x461.x476.rs.dns-oarc.net/CNAME: starting
validating rst.x461.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'net'
validating