Re: .onion and dnssec

[Petr Mensik]

Hello Erich,

more below.

On 11/12/19 2:22 PM, Erich Eckner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 12 Nov 2019, Tony Finch wrote:


Erich Eckner  wrote:


I have also a hard time, generating some useful debug output
- setting `-d 9` does not give additional information in the system log.


You might find it is being written to the file named.run in named's
working directory (this is the default_debug logging channel
configuration). I generally use `rndc trace 11` to tell named to log
details of resolution and validation, including sent and received DNS
mesaages. It's very verbose but it can tell you what is happening to your
.onion queries.


Thanks! I now get the desired log. I noticed, that there were *no* 
queries sent by the dns server at all (even when asking for subdomains 
of onion.eckner.net - which were successfully resolved by tor). I 
suspected, that the slave "." zone superseeds every other zone I have, 
and confirmed that by commenting out the other (slaved opennic) tlds 
which did *not* break the resolving.


I replaced "." by a hint zone and now it works as intended:

- - opennic tlds are resolved via their slave zones (before, they were 
not: I could comment them out and still resolve)


- - normal tlds are resolved via hint root zone (I think)

- - onion. is forwarded to tor

thanks a lot!


That was because when slave, your server was authoritative to say: onion 
does not exist. Local authoritative zone is preferred over forwards, 
your server knew all top level domains.


I have another (minor) question, though:

To my understanding, the difference between "forward first;" and 
"forward only;" is, that the former caches and the latter forwards all 
queries. However, I see the same behaviour in the log for both. Where is 
my mistake?
forward only; means it will forward all queries. If it fails, report 
failure.
forward first; means forward all queries. If it fails, try iterative 
queries from root servers. To prevent leaking of onion queries outside, 
use only;


In both cases, bind would cache responses.


cheers,
Erich


Regards,
Petr

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

___
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: RHEL, Centos, Fedora rpm 9.14.6

[Petr Mensik]

Hello Jóhann,

I am packager of BIND in RHEL and Fedora. I would like everyone would 
use our BIND packages. But we have some modifications, as was already 
mentioned. Some of them are important for FreeIPA to work, some provide 
bind-sdb build to use SDB features. Also some other changes that bound 
dhcp package to bind libraries. The story short, our package is mostly 
the same, but with nontrivial differences.


On 9/30/19 1:11 PM, Jóhann B. Guðmundsson wrote:

https://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.



Bind is already package and maintained in Fedora [1] and derivatives as 
well as ISC having it's ownspecific copr repo [2] in addition to that.


Copr exist to overcome limitation in RHEL/CentOS as in RHEL/CentOS 
consumer wanting newer release then what's available in RHEL/CentOS 
while Fedora packages residing in copr repo would under normal 
circumstance only be needed to provide early testing of branches not yet 
suitable for rawhide ( read as 9.15.x branch of Bind would be made 
available in copr for Fedora while 9.14.x is what should be shipped in 
$CURRENT Fedora releases ).


Copr is used also for Fedora, usually testing rebases or preparing 
packages that would not be useful for general audience. Or not yet ready 
in good enough quality.


It is used for example for my build of 9.14 [3]. Unfortunately my build 
fails to run on both normal variant and bind-pkcs11, which FreeIPA 
requires. Until I fix it, new version would not be in Fedora. And 
bind-sdb variant is turned off as well.


Now the fact that the copr repo contains newer release of Bind compared 
to what's currently being shipped in Fedora indicates that there is some 
friction between the Fedora maintainer ( which in this case seems to be 
a Red Hat employee not an upstream ISC maintainer ) and ISC community 
about maintaining Bind in the distribution.
I hope there is no friction. I admit I had not enough time to finish 
rebase of 9.14, Fedora still contains last 9.11 release. We decided long 
ago to use bind dynamic libraries from DHCP. However, support for 
singlethread libraries was dropped in 9.13. Sharing these libraries was 
intended to save our maintenance for separate libraries. But now it 
proved opossite. That was changed in Fedora 30, where dhcp again uses 
original bind library shipped by ISC with it. Now just PKCS11 and SDB 
variants are blocking new version.


Unfortunately, I am busy with some internal tasks, so I still had not 
time to switch onto BIND 9.14 in Fedora, not even in Rawhide. Sorry for 
that. That is all my fault, ISC is not involved anyhow.


On the other hand, having vanilla ISC package available is good. I can 
test issues in vanilla ISC package and compare them to Fedora package. I 
have plans to reduce differences to necessary minimum. But have more 
important tasks for RHEL now. Sorry for keeping you waiting. It is on my 
TODO list.


That said removing patches implemented by Red Hat for Fedora or it's 
derivative ( RHEL/CentOS etc ) is usually not a smart thing to do and or 
not working with upstream community ( ISC ) to provide and help maintain 
releases for specific platform or downstream distribution in a package 
repository maintained by ISC and it's community ( be it a copr repo or 
repository hosted under the isc domain ) will only cause confusion and 
frustration of consumers of ISC components at the cost of the 
upstream/downstream community surrounding the relevant components.


That said and given that there is no rocket science involved with 
removing patches and building packages I ask...
Well, this is more on side of Red Hat adding those patches on top of ISC 
sources. I already mentioned few features that needs them. In general, 
we at Red Hat try to push as much changes upstream as possible. BIND is 
not great example, as its customization contains lot of changes. And we 
support more combinations for each build. That also complicates new builds.


What's the purpose with these builds, what problems do they solve which 
are unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS 
) and why announcing you are building it and how long are you intending 
to supporting those builds ( encase someone decides to use those builds 
instead of ISC or downstream distribution maintained ones )?
I think its purpose is to support just their own bugs, not Red Hat bugs. 
And to provide ready to use packages soon after release. It is more 
difficult for me to follow. As soon as normal variant is able to support 
both SDB and PKCS11 variant by configuration/plugin, it should be easier 
to maintain and release new version. I think we have an agreement in 
that with ISC developers.


Regards

                Jóhann B.

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=314

2. https://copr.fedorainfracloud.org/coprs/isc/


Regards,
Petr

3. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.14/

--
Petr Menšík

Re: DDNS with extra vhosts...

[Petr Mensik]

Hi John,

I came to similar example and wanted possible names also under developer
namespace. Something like dev1.user.example.org,  you could add to zone
user.example.org:

dev1.user.example.org. IN NS dev1.example.org.

Then configure dev1 like Ondřej suggested, set dev1.example.org IP from
DHCP.

Then users with local DNS server installed and enabled will be able to
add custom names, records under their own namespace. Anyone willing run
their own server can use custom records, others would still have at
least IP address internally. If routing is also fixed somehow, gives
ability to developer to give access to his virtual machines running on
his box. But that is more DHCP and routing configuration than DNS.

dnsmasq --auth-server=dev1.user.example.org might be able to serve local
developer's /etc/hosts, any better DNS server would work too.

I expect public IP addresses are used or example.org is internal only zone.

Regards,
Petr

On 9/29/19 7:22 PM, John Robson via bind-users wrote:
> Hi all,
> 
> I've set up both ISC dhcpd and ISC bind to provide relevant services to a
> virtualised test lab.  In the test lab obviously boxes will be brought up
> and down fairly frequently, and I'm aiming to minimise the amount of effort
> that this takes our users.
> 
> So - the machines get an IP address and dhcpd updates bind, so a specific
> internal domain gets updated - let's use example.orghere for ease of
> reading.
> 
> That all works (after a little fight with permissions).
> I set up a machine with a hostname of 'foo' and there is an automagic DNS
> entry `foo.example.org`.
> 
> BUT - what I'd like to do is have `*.foo.example.org` (or even a specific
> listing of subdomains) point to that IP as well - to enable the various
> vhost based services on the test machines to be accessed without having to
> mess with local hosts files or further mess with DNS each time.
> 
> e.g. test.foo.example.org should point to the same IP as foo.example.org 
> (heck,
> could even be a cname)
> 
> Is there some simple configuration I am missing - or is this not possible?
> Is there a better way to get to where I want to be*?
> 
> Cheers,
> 
> John
> 
> 
> * Previously we had all the test boxes in one /24, so we had `lab123` for
> the box whose IP ended in 123... but we're now in a /23, and that gets a
> lot messier to handle with fixed names (not particularly keen on the idea
> of test341 being for the top half ending in 341-256=85 - nor am I keen on 5
> digit test ids...)
> 
> 
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: search and ndots support in bind utilities

[Petr Mensik]

Thank you Paul,

this document is far better than I hoped for. I have to improve my
googling skills it seems. This is brilliant.

On 9/30/19 5:35 PM, Paul Ebersman wrote:
> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document, explaining
> pemensik> what are possible dangers. How to use it safe way or how to
> pemensik> avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   
> 
> It goes into detail on why search/suffix lists are a bad idea.
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: search and ndots support in bind utilities

[Petr Mensik]

Hi Mark,

I am aware search is a no-no in DNS community. However, is there any
public documentation to this change? Is there RFC recommending not to
use search or how it should be used, related to today's top level domains?

While I agree it is dangerous, there are still people using it. I think
we should point them at some document, explaining what are possible
dangers. How to use it safe way or how to avoid using it at all.

Most important thing is IMO, all libraries in current system should
behave the same way. When I run dig x.y, then ping x.y, I expect it is
always the same target. When search is used now (on Fedora or RHEL), it
might return DIFFERENT target IP. I think this is much more confusing.

Dig protects you, but applications using getaddrinfo() are still
searching both absolute, then relative name if absolute name does not
exist. I think it makes problem MORE dangerous, since your manual
checking using DNS tools does not show requests. But then real
applications using system resolver are more vulnerable. You have
manually verified it is ok using tools, but it is not from applications.
The problem is still there, but HIDDEN from administrator.

Obvious recommendation is to not use search at all. That would work
always the same on any version. I think until glibc resolver is fixed,
tools should behave still the same way. I would like to push change to
glibc resolver, but it seems I am missing good enough arguments.

Regards,
Petr

On 9/27/19 3:31 AM, Mark Andrews wrote:
> Partially qualified names are inherently unsafe.
> 
> Depending on applying the search list after trying the name as fully
> qualified is just plain dangerous as it depends on a NXDOMAIN response
> from a namespace not under your control to reach the service you are
> after.  TLDs get added all the time.
> 
> One could kind of get away with it back when RFC 1535 was written as
> there were only a handful TLDs to worry about colliding with and that
> was manageable.  That time has long past.  This was the time when ndots
> was invented.  Yes, this was a considered decision.
> 
> Searching with partially qualified names with non-default ndots is also
> unsafe, but slightly less so.  You reach internal information / services
> accidentally instead of leaking it to a external party.
> 
> Mark
> 
>> On 26 Sep 2019, at 9:20 pm, Petr Mensik  wrote:
>>
>> Hello,
>>
>> I got bug report [1] about different behavior of nslookup in 9.11
>> version compared to old 9.9 version. At first I thought this issue
>> should be closed right away. But when I digged into changes in BIND, I
>> could not find any reason for given change. It seems to me the effect
>> was not desired. Or not well documented.
>>
>> What changed since 9.10? In 9.9, bind utilities behaved the same way as
>> internal glibc implementation. When there is dots >= ndots in searched
>> name, absolute name is tried first. If it does not exist, domains from
>> search clause are appended and searched as well. Current nslookup
>> behavior is to use ONLY absolute name when dots >= ndots. While I
>> personally consider it better practice, some people still expect
>> original behavior.
>>
>> What is worse, it makes it inconsistent with evaulation by the system
>> (glibc) dns resolver. This way, host some.service can give different
>> results than getent hosts some.service with search openstacklocal.
>>
>> I would like to find evidence or at least opinions, whether this
>> change[2] was intentional and/or what was the reason for it. It seems
>> either bind utils should revert to use search domains after absolute
>> name or system resolver should be fixed to behave the same way as bind
>> utils. But either change requires decision what is the correct way and
>> how it should behave.
>>
>> In case my description of the problem is unclear, let's have an example:
>>
>> $ nslookup -debug -domain="vm" rhel6.8
>> Server:  127.0.0.1
>> Address: 127.0.0.1#53
>>
>> ** server can't find rhel6.8: NXDOMAIN
>>
>> But on BIND 9.9 or with [2] reverted, it gets:
>> $ ./nslookup -debug -domain="vm" rhel6.8
>> Server:  127.0.0.1
>> Address: 127.0.0.1#53
>>
>> Non-authoritative answer:
>> Name:rhel6.8.vm
>> Address: 192.168.122.109
>>
>> Is it bug or feature?
>>
>> Glibc has the same behavior even on new enough versions.
>> Both glibc-2.28-72.el8 and glibc-2.30.9000-7.fc32 can resolve name with
>> dot inside which host or nslookup cannot resolve. I am aware referenced
>> BIND version is quite archaic.
>>
>> Best regards,
>> Petr
>>
>> 1. https://bugzi

search and ndots support in bind utilities

[Petr Mensik]

Hello,

I got bug report [1] about different behavior of nslookup in 9.11
version compared to old 9.9 version. At first I thought this issue
should be closed right away. But when I digged into changes in BIND, I
could not find any reason for given change. It seems to me the effect
was not desired. Or not well documented.

What changed since 9.10? In 9.9, bind utilities behaved the same way as
internal glibc implementation. When there is dots >= ndots in searched
name, absolute name is tried first. If it does not exist, domains from
search clause are appended and searched as well. Current nslookup
behavior is to use ONLY absolute name when dots >= ndots. While I
personally consider it better practice, some people still expect
original behavior.

What is worse, it makes it inconsistent with evaulation by the system
(glibc) dns resolver. This way, host some.service can give different
results than getent hosts some.service with search openstacklocal.

I would like to find evidence or at least opinions, whether this
change[2] was intentional and/or what was the reason for it. It seems
either bind utils should revert to use search domains after absolute
name or system resolver should be fixed to behave the same way as bind
utils. But either change requires decision what is the correct way and
how it should behave.

In case my description of the problem is unclear, let's have an example:

$ nslookup -debug -domain="vm" rhel6.8
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find rhel6.8: NXDOMAIN

But on BIND 9.9 or with [2] reverted, it gets:
$ ./nslookup -debug -domain="vm" rhel6.8
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
Name:   rhel6.8.vm
Address: 192.168.122.109

Is it bug or feature?

Glibc has the same behavior even on new enough versions.
Both glibc-2.28-72.el8 and glibc-2.30.9000-7.fc32 can resolve name with
dot inside which host or nslookup cannot resolve. I am aware referenced
BIND version is quite archaic.

Best regards,
Petr

1. https://bugzilla.redhat.com/show_bug.cgi?id=1743572
2.
https://gitlab.isc.org/isc-projects/bind9/commit/8afea636ab0c07399aa3e2410b2cfbd41099df98
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: Problem with zone delegation with private gTLD

[Petr Mensik]

On 4/8/19 1:05 PM, Matus UHLAR - fantomas wrote:
>> Karl Lovink via bind-users  wrote:
>>> I am trying to set up a private gTLD with BIND9 and underneath that gTLD
>>> a subdomain.
> 
> On 08.04.19 12:00, Tony Finch wrote:
>> Why a TLD?
>>
>> You will have fewer problems if you get a properly registered domain and
>> set up a subdomain of that for private use.
> 
> many users/organizations use private TLDsm, just like they often use
> private
> IP ranges instead of public.
> 
> I believe there should be reserved gTLD for such usage.
> 
I believe there is test domain reserved for similar usage. Or home.arpa
domain.

Organizations should use their own (sub)domain, especially if they use
DNSSEC. Individuals usually lack domain they can control. Organization
often lack good practices to limit some subdomain for private usage.
Complicated setup of secure delegation on some DNS providers might be
responsible.

I think dns search suffix might help with longer domains usage. But it
is also considered insecure.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: DynDB - handling arbitrary zones

[Petr Mensik]

Sounds like something RPZ might able to do on the first glance.
Note there is also rndc addzone method, which may allow runtime
reconfiguration of some sort without generation of config files. May or
may be not what you need. Might be handy for simple empty zones.

Expect some assumptions, dyndb is new enough and not used in similar cases.

On 4/1/19 12:17 PM, Klaus Malorny wrote:
> On 01.04.19 11:18, Petr Mensik wrote:
>> Hi Klaus,
>>
>> [...]
>>
> 
> 
> Thanks for the response. I have seen the LDAP implementation, but
> haven't looked deeper into it. Maybe I will.
> 
> The main problem is that I don't know which zones I will have to serve
> beforehand, and they may be many and may change over time, i.e. simply
> the typical pattern of an ISP. I want to avoid to dynamically create the
> configuration file and trigger the reloading process. One idea I will
> examine further is whether it would be possible to register the root
> domain (".") and so to become responsible for any possible name.
> However, there might be some assumptions on the side of BIND that might
> spoil the idea.
> 
> Regards,
> 
> Klaus

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: DynDB - handling arbitrary zones

[Petr Mensik]

Hi Klaus,

I would recommend taking a look at bind-dyndb-ldap documentation [1], as
I think it still is the only one plugin in active use. Unfortunately not
under active development, but should be able to answer many of your
questions. Some questions could be asked in FreeIPA mailing list, but it
depends on what you intend to do. No new features are planned for it,
but it is still maintained.

1.  https://pagure.io/docs/bind-dyndb-ldap/

On 3/12/19 6:16 PM, Klaus Malorny wrote:
> 
> 
> Hi all,
> 
> first of all, if this is not the right list for such questions, please
> redirect me.
> 
> I am exploring the DynDB API of BIND whether it could help us to solve
> our needs. As I have played around with DLZ quite a few years ago, I was
> pleased to see a new interface seemingly resolving the problems of the
> first (mostly the lack of DNSSEC support). However, one thing I am
> missing, and looking at the demo driver, I did not get a real answer on
> that. That's why I am asking here.
> 
> The DLZ driver had to provide a function to find a zone. This allowed it
> to generate responses for any zone that happened to be in the driver's
> repository (database or else). There was no need keep a list of known
> zones and easily scales up to thousands of zones. I did not find a
> corresponding function in the DynDB API. The whole dbmethods interface
> seems to handle only a single, specific zone with dns_db_t as an
> abstract handle to it. I expected somewhere a customizable function that
> gets a query name and returns the respective (driver specific) zone
> instance (or an indication if it is not available). Instead, it looks
> like that one has to enumerate all zones that shall be handled by the
> driver and register them at a provided "view" instance beforehand. Is
> this perception correct or do I misunderstand something completely?
> Thanks in advance for any hints.

I have no deep knowledge of bind-dyndb-ldap, but I think you understand
it correctly. DynDB API is more or less replacement for built-in
database parsing and zone file reading, but has to register each handled
zone in similar manner to static configured zones. I am sure they can be
fetched by plugin somehow, because that is what bind-dyndb-ldap plugin
does. But I doubt there is one single function that you can pass a list
of zones to handle. Or that you can make some sort of wildcard for any
zone in pure dynamic way. I admit I never tried similar thing ever.

Because there is not ongoing development of any other plugin I know
about, I think it may miss user-friendly API to work with it. That could
be definitely improved, if there is demand and specific use-cases to solve.
> 
> Regards,
> 
> Klaus

Regards,
Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: convert Knot DNS sigantures certs to BIND format.

[Petr Mensik]

Hi Tony and Milan,

softhsm2 contains useful tool that converts bind private key file into
PKCS#8 format: softhsm2-keyconv.

Or modify dnssec-keyfromlabel to be able read files from different file
formats as well?

Maybe, just maybe it would be easier to modify that tool to be able
producing also the other direction.

On 3/12/19 5:11 PM, Tony Finch wrote:
> Milan Jeskynka Kazatel  wrote:
>>
>> I received a hint for a tool which allows converting .pem format used in
>> Knot to .key and .private used in BIND, but it, unfortunately, does not
>> support ECDSAP256SHA256 algorithm which I used.
> 
> Ah, sounds like Knot uses a relatively familiar key format, so we can hack
> around with OpenSSL command line tools.
> 
> Unless I have missed something, BIND doesn't have any support for non-BIND
> key files: it has its own code for reading and writing keys, which knows
> about OpenSSL's in-memory key format. (I think this is related to support
> for multiple crypto providers, and the fact that supporting PEM implies
> supporting ASN.1 which is not a task any wise programmer would take on.)
> 
> So I think you'll have to get dirty with the key internals; fortunately
> the modern key types handle the private material as a blob so you don't
> have to fiddle around with half a dozen parameters.
> 
> If you have an ECDSA key in PEM format, you can break it open like
> this. The short blob is the private key and the long one is the public
> key.
> 
> $ openssl ec 
>openssl asn1parse -dump
> read EC key
> writing EC key
> 0:d=0  hl=2 l= 119 cons: SEQUENCE
> 2:d=1  hl=2 l=   1 prim: INTEGER   :01
> 5:d=1  hl=2 l=  32 prim: OCTET STRING
>    - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37   
> .`...oI:.2..!,.7
>   0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de   
> F...Oq..q.s.
>39:d=1  hl=2 l=  10 cons: cont [ 0 ]
>41:d=2  hl=2 l=   8 prim: OBJECT:prime256v1
>51:d=1  hl=2 l=  68 cons: cont [ 1 ]
>53:d=2  hl=2 l=  66 prim: BIT STRING
>    - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b   
> 66.I...{
>   0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8   
> -0d:
>   0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28   
> 0q..b`.(
>   0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e   
> .]...U..4...
>   0040 - d2 ac ..
> 
> BIND wants these in base64. A not completely impossible way to do this is
> to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
> encoded DER.) This involves some magic numbers for the offsets of the
> blobs derived from the asn1 dump above.
> 
> $ openssl ec -outform der 
>perl -Mv5.10 -MMIME::Base64 -e '
> undef $/; my $k = ;
> print encode_base64 substr $k, 7, 32;
> print encode_base64 substr $k, -64;'
> read EC key
> writing EC key
> 9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
> h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
> 5TQSHQ7SrA==
> 
> The first line is the private key; the second and third lines are the
> public key. We can check it matches:
> 
> $ cat /var/lib/knot/keys/zone_example.com.json
> {
>   "policy": "\u0006policy",
>   "nsec3_salt": null,
>   "nsec3_salt_created": null,
>   "keys": [
> {
>   "id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
>   "keytag": 19633,
>   "algorithm": 13,
>   "public_key": 
> "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
>   "ksk": false,
>   "created": "2019-03-12T15:44:02+"
> }
>   ]
> }
> 
> Probably the easiest way to turn this into BIND key files is to run
> `dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
> short private and long public base64 blobs emitted by the perl. You will
> also need to rename the files to match the keytag in knot's zone_*.json
> file.
> 
> Tony.
> 
> 
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: broken trust chain

[Petr Mensik]

Hi Cody,

please check contents of managed-keys.bind or viewname.mkeys files in
bind working directory. It can be redirected somewhere else by
managed-keys-directory option.

These files contains state of managed keys of BIND. Its contents can be
analysed by manually or by perl script in contrib/scripts/check5011.pl.

Path to file depends on distribution. Default path on Fedora without
views would be:
perl contrib/scripts/check5011.pl /var/named/dynamic/managed-keys.bind
  . tag 19036 RSASHA256 trusted
  . tag 20326 RSASHA256 trusted

Maybe simpler validation would be rndc secroots, then find
named.secroots in the working directory of bind. It should contain:
   Secure roots:

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed

BIND will initialize managed-keys first time it is able to reach root
servers to validate it. Once it does, it will use RFC 5011 mechanism to
update the key. It has to use dnssec enabled forwarder or have direct
root access to maintain the keys. If neither of that is available,
dnssec keys are no longer automatically managed but no warning is
emitted. If managed-keys.bind and its jnl files are deleted and bind is
restarted, it will recreate it from managed-keys found in configuration.

File bind.keys is used only the zone is initialized in managed-keys.bind
for the first time. It requires 30 days after that to trust new key.

On 10/14/2018 02:17 PM, Cody Allen wrote:
> issue just started on 10/13/2018 both servers impacted at same time, clocks 
> are correct, version of bind is 9.11.1 impacting recursion on internal view, 
> authoritative zones work fine, servers have been running for couple of years 
> or longer with zero problems.  most recent version of bind.keys installed. 
> only solution has been to set dnssec-validation to no
> 
> 
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: [BIND] RE: KSK Rollover

[Petr Mensik]

Hi Mark,

Dne 7.9.2018 v 10:49 Mark Elkins napsal(a):
> It would probably have been more helpful (speeded up finding the
> problem) if the error message "file 'named.secroots': permission denied"
> also gave the directory name that it was trying to write to? Just a thought.
> Sometimes we don't see the obvious.
It is sort of obvious, if you know the details. Bind changes current
directory to the directory listed in directory option. It actually tries
to open file path "named.secroots", in that directory. In that regard,
it is precise. It is documented, but not very obvious on the first
glance, what it really means.
> 
> 
> On 09/06/2018 10:58 PM, Brent Swingle wrote:
>> I moved the file from /etc to /var/named and now I get an additional error 
>> line printed in /var/log/messages.
>>
>> Sep  6 15:44:40 ns3 named[15443]: received control channel command 'secroots'
>> Sep  6 15:44:40 ns3 named[15443]: could not open secroots dump file 
>> 'named.secroots': permission denied
>> Sep  6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied
>> Sep  6 15:44:40 ns3 audit:  { write } for  pid=15447 
>> comm="named" name="named.secroots" dev="dm-0" ino=135707451 
>> scontext=system_u:system_r:named_t:s0 
>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
>>
>>
>> This error also appears in the audit.log file and a search is pointing to 
>> SELinux as the hangup.  Any pointers on dealing with SELinux would be 
>> appreciated.
>>
>> type=AVC msg=audit(1536266680.663:75671): avc:  denied  { write } for  
>> pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 
>> scontext=system_u:system_r:named_t:s0 
>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
>>
>>
>> I left all of the permissions the same and I think they should be lenient 
>> enough:
>> [root@ns3 named]# ls -lh named.secroots
>> -rw-rw-rw-. 1 named named 0 Sep  6 13:52 named.secroots
>>
>>
>>
>>
>> -Original Message-
>> From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl] 
>> Sent: Thursday, September 06, 2018 3:39 PM
>> To: Brent Swingle 
>> Cc: Evan Hunt ; bind-users@lists.isc.org
>> Subject: Re: [BIND] RE: KSK Rollover
>>
>> Hi Brent.
>> In out CentOS box, the named.secroots file is written on
>>   /var/named/
>>
>> You should check permissions there too.
>>
>> Hugo
>>
>> On 20:32 06/09, Brent Swingle wrote:
>>> Evan,
>>>
>>> I ran the command and followed the directions to build out rndc as you have 
>>> suggested.  However, I am not sure that it made much of a difference.  I 
>>> should have been a little clearer from the beginning.  I had worked with 
>>> rndc to issue other commands and had received what appeared to be valid 
>>> responses as if rndc was functional.  I had somewhat assumed that rndc was 
>>> baked in behind the scenes and ready to go.  Either way I it has a 
>>> rndc.conf and is specified in named.conf at this point.
>>>
>>> I have two of these servers that are identical from an SW perspective.  As 
>>> a test, I issued "rndc secroots" on the server that I have modified to 
>>> configure rndc and observed the following lines appear in the 
>>> /var/log/messages file.  When I issued "rndc secroots" from the 
>>> non-modified file I get the same 3 lines.  It acts like the process is 
>>> running but it is unable to write output to the named.secroots file.
>>>
>>> Sep  6 14:33:13 ns2 named[31189]: received control channel command 
>>> 'secroots'
>>> Sep  6 14:33:13 ns2 named[31189]: could not open secroots dump file 
>>> 'named.secroots': permission denied Sep  6 14:33:13 ns2 named[31189]: 
>>> dumpsecroots failed: permission denied
>>>
>>>
>>> As a test, I manually created named.secroots with weakened permissions to 
>>> see if that made a difference but it still won't print output to it.
>>> [root@ns3 etc]# ls -lh named.secroots
>>> -rw-rw-rw-. 1 named named 0 Sep  6 13:52 named.secroots
>>>
>>>
>>>
>>> -Original Message-
>>> From: Evan Hunt [mailto:e...@isc.org]
>>> Sent: Thursday, September 06, 2018 1:22 PM
>>> To: Brent Swingle 
>>> Cc: bind-users@lists.isc.org
>>> Subject: Re: KSK Rollover
>>>
>>> On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote:
 This is the command that does not work and the output received:
 [root@ns2 ~]# rndc secroots
 rndc: 'secroots' failed: permission denied
 [root@ns2 ~]#
>>> Have you set up your server to accept rndc commands?
>>>
>>> If not, run "rndc-confgen" and follow the directions.
>>>
>>> --
>>> Evan Hunt -- e...@isc.org
>>> Internet Systems Consortium, Inc.
>>>
>>> ___
>>> 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
>>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> 

Re: [BIND] RE: KSK Rollover

[Petr Mensik]

Hi,

also a few notes to it.

Dne 7.9.2018 v 04:05 Brent Swingle napsal(a):
> This matter has been resolved with input from Evan.  I was able to add a file 
> path for secroots to the named.conf file and push the output file to a temp 
> directory that was not permission restricted.
> 
> secroots-file "/tmp/named.secroots" ;
Instead, "/var/named/data/named.secroots" or maybe
"/run/named/named.secroots" should be used.

In Fedora, it should already have write access to /var/named directory
itself also from daemon. Should be already for update on supported releases.
> 
> 
> Ultimately when I ran "rndc secroots" it created the output file here:
> 
> /tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots
> 
> 
> The data in the file seems to be as desired if I understand the KSK Rollover 
> test correctly, I should see 20326 which pertains to the new key:
> 
> [root@ns3 tmp]# cat named.secroots
> 06-Sep-2018 18:47:16.190
> 
> Start view internal-in
> 
> ./RSASHA256/20326 ; managed
> ./RSASHA256/19036 ; managed
> dlv.isc.org/RSASHA1/19297 ; managed
> 
> Start view external-in
> 
> ./RSASHA256/20326 ; managed
> ./RSASHA256/19036 ; managed
> dlv.isc.org/RSASHA1/19297 ; managed
> 
> Start view external-chaos
> 
> dumpsecroots failed: not found
> 
> 
> 
> 
> I did not fully try Carl's input below but I believe it would have worked as 
> well.  I had performed a "chmod 770 /var/named" but I did not follow it up 
> with the SELinux modification.  The last error I had was SELinux barking so 
> I'd anticipate his suggestion was the correct one.
> 
> Does the 'named' user have write access to /var/named? The default
> redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
> the default redhat selinux config prevents named writing to /var/named.
> 
> chmod 770 /var/named
> setsebool -P named_write_master_zones=true
> rndc secroots

It should not be required on upcoming RHEL 7 versions.
named_write_master_zones would be turned on by default in next minor
release. Also permissions would be fixed to allow writing by default. It
would save us to replace all paths in config file to write into
/var/named/data subdirectory. I hope also to reduce the confusion.
> 
> 
> 
> 
> Thanks everyone for assisting with this matter.
> 
> 
> 
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: bind-chroot, runs, works, dies

[Petr Mensik]

Hi Reindl,

I have tested it and it has undesired side-effects. It would be great if pid 
files did not have to match systemd unit files. But presence of pid files also 
work as notification of completed initialization (which is done BEFORE forking 
and finishing ExecStart command).

Service type=simple is not good replacement of forking, because it does not let 
you know when service failed to start at all. If you already have something 
listening on your port and start named with
$ systemctl start named

It prints nothing, error code 0 - success. But you have to look at 
$ systemctl status named

to see there is actually failure. I would not expect that. It works better now.

Forking does allow you to first read basic configuration, initialize first. 
When that is successfully done, continue with daemonizing. Systemd will wait 
until it finds pid file created by daemonizing. Any initialization errors, even 
those that named-checkconf cannot find, are reported and you are told it did 
NOT start. Before "systemd start named" returns. I consider it important 
feature, worth still playing with pid files.

I think type=notify would be good replacement. It would requires support 
implemented in bind however, so it can tell you when it finished initialization 
and started handling requests. I think nothing such is implemented yet. At 
least I do not know about option for that.

While I agree pid files are strange relicts of old days, the way systemd 
handles them has some advantages over simple services. Unless bind supports 
sd_notify of systemd, I think default configuration has to stay playing with 
pid files. Of course if you want automatically restarted service, simple 
service may suit you. Not for default configuration however.

Regards,
Petr

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


- Original Message -
From: "Reindl Harald" <h.rei...@thelounge.net>
To: bind-users@lists.isc.org
Sent: Friday, August 11, 2017 4:04:12 PM
Subject: Re: bind-chroot, runs, works, dies



Am 11.08.2017 um 15:57 schrieb Petr Mensik:
> Hi Todd.
> 
> I think much better than Ask Fedora would be filling a bug in 
> bugzilla.redhat.com. I would see it straight away.
> I am Fedora bind maintainer. If there is bug preventing correct start of 
> named-chroot, I would like to fix it.
> 
> You would see SElinux errors in command "ausearch -i -ts recent -m avc -m 
> user_avc -m selinux_err" if that errors were SElinux related.
> 
> I think your config file is missing pid-file "/run/named/named.pid"; It has 
> to match pid file used by your named-chroot.service. If systemd does not find 
> the pid file of forking service, it will cancel the service.
> PIDFile in named-chroot service includes chroot path, but configuration file 
> has to point to path inside chroot only.
> It should work with default configuration even when pid-file directive is 
> commented out. There is symlink from /var/run to /run also in 
> /var/named/chroot

and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade 
and removed all that pid-file-stuff excatly becuse it causes only 
troubles long before most package maintainers provided systemd-units 
while as we deloyed F15 we overrided every single service with a unit in 
/etc/systemd/system

after 6 years running systemd nobody was able to show me a single 
service which needs a pid-file these days because the whole concept is 
broken by design when we have a system manager which can track services 
and processes proper

the pid-file stuff in systemd is last ressort for heavily broken software
___
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
___
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: Confused about SELinux error

[Petr Mensik]

Hi Todd,

that means you are trying to save session.key into directory where SELinux is 
forbidding write access to named.
Session.key is file created once per start and removed before shutdown. I think 
you have something wrong with link /var/run/named -> /run/named link.
Default built-in value is /var/run/named/session.key. Default Fedora 
configuration uses /run/named/session.key. Both paths should work without 
difference.

Correct selinux type for files in /run/named is named_var_run_t. I think you 
should run instead:
$ restorecon -rv /run/named /var/run/named 

Then restart named service. Context of a new file should be already correct.

Do you have this option in you configuration file? What is its value?
# options { ...
session-keyfile "/run/named/session.key";

It would be helpful if you include you configuration in readable form, please.

Listed types are more likely types named is allowed to touch. I admit SELinux 
errors are often confusing. What you written here are hints to you how to solve 
the error, not the error itself.
More helpful errors would be printed by:
$ ausearch -i -ts today -m avc -m user_avc -m selinux_err

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

- Original Message -
From: "ToddAndMargo" 
To: bind-users@lists.isc.org
Sent: Friday, August 11, 2017 10:39:11 PM
Subject: Confused about SELinux error

Hi All,

What does this SELinux error mean when I start bin-chroot?

  # semanage fcontext -a -t FILE_TYPE 'session.key'

  where FILE_TYPE is one of the following: dnssec_trigger_var_run_t,
  ipa_var_lib_t, krb5_host_rcache_t, krb5_keytab_t, named_cache_t,
  named_log_t, named_tmp_t, named_var_run_t.

 # semanage fcontext -a -t named_var_run_t 'session.key'
 # restorecon -v 'session.key'


How am I suppose to know what "FILE_TYPE" they are talking about?

-T


___
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
___
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: bind-chroot, runs, works, dies

[Petr Mensik]

Hi Todd.

I think much better than Ask Fedora would be filling a bug in 
bugzilla.redhat.com. I would see it straight away.
I am Fedora bind maintainer. If there is bug preventing correct start of 
named-chroot, I would like to fix it.

You would see SElinux errors in command "ausearch -i -ts recent -m avc -m 
user_avc -m selinux_err" if that errors were SElinux related.

I think your config file is missing pid-file "/run/named/named.pid"; It has to 
match pid file used by your named-chroot.service. If systemd does not find the 
pid file of forking service, it will cancel the service.
PIDFile in named-chroot service includes chroot path, but configuration file 
has to point to path inside chroot only.
It should work with default configuration even when pid-file directive is 
commented out. There is symlink from /var/run to /run also in /var/named/chroot.

Can you check rights and selinux context of chroot run directories?

These are on my Fedora 26.

$ ls -ldZ /var/named/chroot/{,var/}run{,/named}
drwxr-x---. 3 root  named system_u:object_r:named_conf_t:s04096 Aug 11 
13:01 /var/named/chroot/run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 
18:45 /var/named/chroot/run/named
lrwxrwxrwx. 1 named named system_u:object_r:named_conf_t:s0   6 Jun 30 
18:45 /var/named/chroot/var/run -> ../run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 
18:45 /var/named/chroot/var/run/named

Is it possible you do not have the /var/run symlink there? It would not find 
pid file and cancel the service then.
Did you upgrade to Fedora 26 from previous version?

I would be grateful If you could fill a bug. You may not be the only one 
affected and I would like to fix it for everyone.

I would test whether Type=service proposed by Reindl can be used in new Fedora 
release. I like it.

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

- Original Message -
From: "toddandmargo" 
To: bind-users@lists.isc.org
Sent: Thursday, August 10, 2017 12:14:00 AM
Subject: bind-chroot, runs, works, dies


Hi All, 

Help! 

Fedora 26 x64 
Xfce 4.12 

# rpm -qa \bind\* 
bind-libs-lite-9.11.1-2.P2.fc26.x86_64 
bind99-libs-9.9.10-1.P2.fc26.x86_64 
bind-chroot-9.11.1-2.P2.fc26.x86_64 
bind-license-9.11.1-2.P2.fc26.noarch 
bind-9.11.1-2.P2.fc26.x86_64 
bind-libs-9.11.1-2.P2.fc26.x86_64 
bind99-license-9.9.10-1.P2.fc26.noarch 
bind-utils-9.11.1-2.P2.fc26.x86_64 


I have a weird one. I am trying to set up bind-chroot. When I run it, it works 

for about 30 seconds, then dies. And for the entire 30 seconds, it works 

beautifully. I can go anywhere with Firefox and look up anything with "host". 
Then it breaks my heart. 
# systemctl start named-chroot Job for named-chroot.service canceled. 


This is my error logs: 
Aug  8 15:58:49 FedoraServer named[10120]: all zones loaded Aug  8 15:58:49 
FedoraServer named[10120]: running Aug  8 15:58:49 FedoraServer named[10120]: 
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug  8 15:58:49 
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
Aug  8 15:58:49 FedoraServer systemd: named-chroot.service: PID file 
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such 
file or directory  Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: 
Start operation timed out. Terminating. Aug  8 16:00:19 FedoraServer 
named[10120]: shutting down Aug  8 16:00:19 FedoraServer named[10120]: stopping 
command channel on 127.0.0.1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
stopping command channel on ::1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
no longer listening on ::#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 127.0.0.1#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 50.124.80.106#53 Aug  8 16:00:19 FedoraServer named[10120]: 
exiting Aug  8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name 
Domain (DNS). Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: Unit 
entered failed state. Aug  8 16:00:19 FedoraServer systemd: 
named-chroot.service: Failed with result 'timeout'. Aug  8 16:00:19 
FedoraServer systemd: Stopping Set-up/destroy chroot environment for named 
(DNS)... Aug  8 16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=named-chroot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=failed' Aug  8 16:00:20 FedoraServer systemd: Stopped 
Set-up/destroy chroot environment for named (DNS). Aug  8 16:00:20 FedoraServer 
audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='unit=named-chroot-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 


I find the 
PID file /var/named/chroot/run/named/named.pid not readable (yet?) 

Re: Automatic RRSIG Refresh in BIND 9.8.2

[Petr Mensik]

Hi,

I think you should use file "dynamic/db..signed"; instead. On Red 
Hat /var/named is by default read only to named. It is enforced both by unix 
permissions and SELinux policy. I think you are being blocked by selinux.

Try sudo ausearch -i -ts recent -m avc -m user_avc -m selinux_err
It may show you some errors that are named related.

For dynamic updates, directory /var/named/dynamic is prepared. Signature 
maintaining is processed like dynamic updates to the zone, so write access to 
the zone file and its .jnl is required. You can enable write there, check 
https://bugzilla.redhat.com/show_bug.cgi?id=545128

Regards,
Petr

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


- Original Message -
From: "Latitude" 
To: bind-users@lists.isc.org
Sent: Wednesday, June 14, 2017 11:11:05 PM
Subject: Re: Automatic RRSIG Refresh in BIND 9.8.2

Thanks for your reply Tony. Great references. I've got the ARM for 9.8.2
handy but thank you for sending the link to your article and pointing me out
to Section 4.9.3 Fully Automatic Signing. It's been helpful to confirm zone
RRSIGs can refresh automatically. 

A zone that was signed with a sigvalidity period to be refreshed every 7
days is not being refreshed and I'm trying to troubleshoot. I've given the
zone statement the *auto-dnssec maintain;* and *update-policy local;*
statements as described, and I'm getting the error below repeatedly in my
/var/log/message feed:

*info: zone /IN: reconfiguring zone keys
.jnl: create: permission denied
named[5952]: 14-Jun-2017 20:38:08.640 general: error: zone /IN:
zone_rekey:dns_journal_open -> unexpected error*

The user *named* has the rwx permissions on the directory containing the
source zone file and the DNSSEC-signed zone file .signed. This
installation is BIND chrooted so the absolute path is
*/var/named/chroot/var/named/*. Is BIND trying to create the .jnl file in
this directory (*/var/named/chroot/var/named/*) and failing to due so? If
so, I don't see why it's having an issue because user:group ownership of the
/var/named/chroot/var/named directory is named:named and permissions are set
to 750 on it. I believe this could be the clue to why my zone RRSIG isn't
being refreshed. A lot of Google searching for this error hasn't yielded
anything to help my situation either. Thank you in advance for any input.

Below are my named.conf and zone statement file excerpts for reference:

named.conf file DNSSEC options:

// DNSSEC options
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
sig-validity-interval 7 2; //RRSIG validity period, BIND 9 ARM,
Chapter 6
key-directory "/etc/keys/dnssec"; //Directory containing all DNSSEC
keys

//Zone statement
zone "" { 
type master;
update-policy local; 
file "db..signed"; 
auto-dnssec maintain;
allow-query { any; }; 
allow-transfer { xfers; }; 
};




--
View this message in context: 
http://bind-users-forum.2342410.n4.nabble.com/Automatic-RRSIG-Refresh-in-BIND-9-8-2-tp3946p3948.html
Sent from the Bind-Users forum mailing list archive at Nabble.com.
___
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
___
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: Bind 9.9.4 DLZ LDAP , error in config file named.conf

[Petr Mensik]

Dear Enrico,

I have never configured DLZ zone myself.
There is clear error: all nodes query must specify a search base
I think it did not parse some query uri well. Could you add at least -d 1 to 
OPTIONS in /etc/sysconfig/named and retry?
It will provide more details about query before it fails.

Just to be sure, do you really want ou=dns,dc=priv for lines 1 and 2, but 
ou=dns,o=bind-dlz for lines 3 and 4? Are your data split between them?

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

- Original Message -
From: "Enrico Becchetti Gmail" 
To: bind-users@lists.isc.org
Sent: Wednesday, May 3, 2017 10:16:47 AM
Subject: Bind 9.9.4 DLZ LDAP , error in config file named.conf

Dear All, let me explain my issue. 
I've CentOS 5.5 with Bind version 9.6.1 and the most important item for this 
setup 
is the integration with Ldap throught DLZ. So as you can imagine I've 
named.conf 
with ldap servers but I haven't any zone file because all informations 
about hostname and IP are inside Ldap. 
In the following my named.conf file: 

options { 
directory "/var/named"; 

listen-on-v6 { none; }; 
listen-on { 127.0.0.1; .. 
omissis 
 
pid-file "/var/run/named/named.pid"; 
}; 
. 
dlz "ldap zone" { 
database "ldap 1 v3 simple {cn=Sync,dc=priv} {PASSWORD} {10.0.0.1} 
ldap:///dlzZoneName=%zone%,ou=dns,dc=priv???objectClass=dlzZone 
ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,dc=priv?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr?sub?(&(objectClass=dlzAbstractRecord)(!(dlzType=soa)))
 
ldap:///dlzHostName=@,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzData,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(dlzType=soa))
 
ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa)))
 "; 
}; 

Ldap server is OpenLdap 2.4.11 with DLZ schema, with this setup name resolution 
for zones "*.PRIV" works fine. 

This server is up and running from many years but now I need to update to 
Centos 7, but 
with this OS update I also migrate to Bind 9.9.4 included in the last Centos 
and this is my problem ! 

Bind 9.9.4 with named.conf describe above failed during startup. When I make 
"systemctl start named.sdb" 
I've this error: 

Job for named-sdb.service failed because the control process exited with error 
code. See "systemctl status named-sdb.service" and "journalctl -xe" for 
details. 

/var/log/messages: 

May 3 10:11:53 privgw systemd: Starting Generate rndc key for BIND (DNS)... 
May 3 10:11:53 privgw systemd: Started Generate rndc key for BIND (DNS). 
May 3 10:11:53 privgw systemd: Starting Berkeley Internet Name Domain (DNS)... 
May 3 10:11:53 privgw bash: zone localhost/IN: loaded serial 2002081601 
May 3 10:11:53 privgw bash: zone 127.in-addr.arpa/IN: loaded serial 2002081601 
May 3 10:11:53 privgw named-sdb[5307]: starting BIND 
9.9.4-RedHat-9.9.4-38.el7_3.3 -u named 
May 3 10:11:53 privgw named-sdb[5307]: built with 
'--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' 
'--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' 
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' 
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' 
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' 
'--localstatedir=/var' '--enable-threads' '--with-geoip' '--enable-ipv6' 
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static' 
'--disable-openssl-version-check' '--enable-exportlib' 
'--with-export-libdir=/usr/lib64' '--with-export-includedir=/usr/include' 
'--includedir=/usr/include/bind9' '--enable-native-pkcs11' 
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' 
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' 
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' 
'--disable-isc-spnego' '--enable-fixed-rrset' 
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' 
'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 
'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
-mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE' 
May 3 10:11:53 privgw named-sdb[5307]: 
 
May 3 10:11:53 privgw named-sdb[5307]: BIND 9 is maintained by Internet Systems 
Consortium, 
May 3 10:11:53 privgw named-sdb[5307]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit 
May 3 10:11:53 privgw named-sdb[5307]: corporation. Support and training for 
BIND 9 are 
May 3 

Re: Bind9 and PostgreSQL

[Petr Mensik]

Hello Michelle,

There is some documentation on 
http://bind-dlz.sourceforge.net/postgresql_driver.html. It seems old, but DLZ 
driver did not get major changes in last years. There is also example at 
http://bind-dlz.sourceforge.net/postgresql_example.html. Of course there is 
source code in bind source package in 
contrib/dlz/drivers/dlz_postgres_driver.c. Is that all you need?

I have to say I have never used DLZ myself, this is what I just googled.

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


- Original Message -
From: "Michelle Konzack" 
To: bind-users@lists.isc.org
Sent: Wednesday, February 1, 2017 10:52:59 AM
Subject: Bind9 and PostgreSQL

Hello *,

I wan to move back to Bind9 with DLZ and PostgreSQL support, but I  need
the infos for Debian 7 (Wheeze).  However, I find only instructions  for
LDAP support and MySQL, which do not work for me.

Is there a HowTo how to do this?

Thanks in avance

-- 
Michelle KonzackITSystems
GNU/Linux Developer 0033-6-61925193

___
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
___
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: BIND - Continuous NS ROOT queries to root servers

[Petr Mensik]

I think you might have problem with DNSSEC validation. Bind in rhel6 validates 
root by default and have got built-in root key compiled in. Have you tried 
dnssec-validation no; option in your config?

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


- Original Message -
From: "Antonio Medina" 
To: "bind-users@lists.isc.org" 
Cc: "Kairon Morillo" , "William Jackson" 

Sent: Thursday, December 22, 2016 9:22:14 AM
Subject: RE: BIND - Continuous NS ROOT queries to root servers



Hi all, 



we are running BIND in Red Hat servers. We are using release BIND 
9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6. 



We are not using BIND in an standard Internet environment. Instead, we are 
using BIND in a mobile network environment, in which DNS Root service is 
provided by service providers. Therefore, we are no using built-in root 
servers. So, we have customized the content of db.root file to include IP 
addresses of DNS servers belonging to our service provider. In our case we have 
configuration similar to the following one (we have omitted real server names 
and IP addresses): 





. 360 IN NS SERVER1.grx. 

SERVER1.grx. 360 IN A 10.10.10.1 



. 360 IN NS SERVER2.grx. 

SERVER2.grx. 360 IN A 10.10.20.1 



. 360 IN NS SERVER3.grx. 

SERVER3.grx. 360 IN A 10.10.30.1 



. 360 IN NS SERVER4.grx. 

SERVER4.grx. 360 IN A 10.10.40.1 



. 360 IN NS SERVER5.grx. 

SERVER5.grx. 360 IN A 10.10.50.1 



. 360 IN NS SERVER6.grx. 

SERVER6.grx. 360 IN A 10.10.60.1 



We have noticed that each query forwarded towards root servers creates an extra 
NS ROOT query. We have been reading about “root priming”, so were expecting 
this NS ROOT query upon server restart. However, we are seeing this kind of 
query for each query that has to be resolved with root servers assistance. We 
believed that “root priming” was supposed to happen once a day or upon ROOT 
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with 
TTL 3600 to NS ROOT queries. 



How can we stop/limit these massive NS ROOT queries? 



In addition, we are going to configure a second provider that has warned us on 
they do not reply to NS ROOT queries. Could this pose a problem for our DNS 
servers? Is it possible to instruct our DNS servers not to perform root 
priming? 



Thanks for your help. 



Kind regards, 

Antonio. 



P.S. Below you can find the structure of our named.conf file 





acl "ExternalACL" {any;}; 



acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; }; 



options { 



allow-recursion {10.10.100.1/32;10.10.200.1/32;}; 

directory "/var/named"; 





}; 





view "InternalView" IN { 



match-clients {InternalACL;}; 



allow-recursion {10.10.100.1/32;10.10.200.1/32;}; 



zone "." IN { 

type hint; 

file "db.root"; 

}; 



# Master Zone(s): 



MASTER ZONES 



}; 



view "ExternalView" IN { 

allow-recursion {127.0.0.1;}; 

allow-transfer {none;}; 

match-clients {key 
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};
 

zone "." IN { 

type hint; 

file "db.root"; 

}; 

# Master Zone(s): 

MASTER ZONES 

}; 











___
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
___
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: Need of 2 $ORIGIN Directives

[Petr Mensik]

A) $ORIGIN changes appended suffix to all hostnames without trailing . for all 
following records. You can change it more than one time.
Unless I am mistaken, NS records of first section would expand to
. NS local.atlanta.com.
. NS kabulvm8.atlanta.com.

That seems wrong to me.

B) Yes, it is almost equal. NS records are correct this time. I would prefer 
this variant myself.

However if those zones are output of some tool or script, you should try to 
support multiple usage of $ORIGIN directive in any tools you use.

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

- Original Message -
From: "Harshith Mulky" 
To: bind-users@lists.isc.org
Sent: Wednesday, December 21, 2016 1:57:35 PM
Subject: Need of 2 $ORIGIN Directives



Hello, 




We have bind running bind-9.9.4-29.el7.x86_64 




We have a domain file with these configurations and we have to build our A 
records on top of this 






$ORIGIN . 
$TTL 86400 ; 1 day 
atlanta.com IN SOA local.atlanta.com. master.atlanta.com. ( 
2001062522 ; serial 
21600 ; refresh (6 hours) 
3600 ; retry (1 hour) 
604800 ; expire (1 week) 
86400 ; minimum (1 day) 
) 
NS local.atlanta.com. 
NS kabulvm8.atlanta.com. 
$ORIGIN atlanta.com. 
$TTL 300 ; 5 minutes 
local A 127.0.0.1 
kabulvm8 A 10.54.49.43 



So I wanted to understand some things about this Domain 




A. Why are there 2 $ORIGIN directives? 


B. Can the above be replaced as below 





$ORIGIN atlanta.com. 
$TTL 86400 ; 1 day 
@ IN SOA local.atlanta.com. master.atlanta.com. ( 
2001062522 ; serial 
21600 ; refresh (6 hours) 
3600 ; retry (1 hour) 
604800 ; expire (1 week) 
86400 ; minimum (1 day) 
) 
NS local.atlanta.com. 
NS kabulvm8.atlanta.com. 
;A Records 
local A 127.0.0.1 
kabulvm8 A 10.54.49.43 








Thanks 

Harshith 

___
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
___
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: ISC Bind 9.11 and dyndb-ldap

[Petr Mensik]

Hello Kishore,

It is not so simple. What was merged into BIND 9.11 is only dynamic database 
API, that is bind-dyndb-ldap using. That dynamic database does not store any 
permanent data, it is only interface other plugins can use.
That means dynamic_db provided by custom patch for RHEL and Fedora was merged 
upstream WITH changes. It changed name and syntax of configuration, so you have 
to modify it. 

But you still have to use bind-dyndb-ldap plugin to use LDAP backend in BIND. 
And that plugin is not supported by ISC, see 
https://fedorahosted.org/bind-dyndb-ldap/. 

Unfortunately there is plugin in rawhide with support for new API of BIND 9.11, 
but it requires OpenSSL 1.1 as well. There is not yet bind-dyndb-ldap that 
supports both current dyndb and older OpenSSL. I suggest to use older BIND 
server now with custom patches for dynamic_db. You would have to backport some 
code to run last release.

Correct path on Fedora is /usr/lib64/bind/ldap.so (bind-dyndb-ldap package). 
/usr/lib64/libldap.so is something completely different, that will never work 
in BIND.

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

- Original Message -
From: "ramkishore b" 
To: comp-protocols-dns-b...@isc.org
Sent: Tuesday, December 13, 2016 6:22:09 PM
Subject: Re: ISC Bind 9.11 and dyndb-ldap

On Monday, October 17, 2016 at 7:23:34 AM UTC+5:30, Pallissard, Matt wrote:
> Has anyone successfully used LDAP as a dynamic back-end for bind 9.11?
> 
> 
> 
> Unless I'm reading the release notes/new features pages incorrectly the 
> bind-dyndb-ldap plugin has been rolled into ISC's official release and I 
> shouldn't have to mess around with patching/building it from source.
> 
> 
> 
> 
> Yet I get the following errors upon startup;
> 
> 
> 
> named[9937]: loading configuration from '/etc/named.conf'
> named[9937]: /etc/named.conf:23: unknown option 'dynamic-db'
> named[9937]: loading configuration: failure
> named[9937]: exiting (due to fatal error)
> systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
> 
> 
> 
> 
> I'm using the package provided by Arch Linux and can provide the flags the 
> bind package was compiled with if those are relevant.
> 
> 
> 
> Any advice would be greatly appreciated.
> 
> 
> 
> 
> 
> Matt Pallissard

Hello Matt Pallissard , 
Have you succeeded in using LDAP as a dynamic back-end for bind 9.11? 

We are getting below errors while trying to make bind initialization with 
dyndb. 

loading DynDB instance 'ldap_dyndb' driver '/usr/lib64/libldap.so'
failed to lookup symbol dyndb_version in dyndb module '/usr/lib64/libldap.so': 
/usr/lib64/libldap.so: undefined symbol: dyndb_version
failed to dynamically load instance 'ldap_dyndb' driver 
'/usr/lib64/libldap.so': (null) (failure)
dynamic database 'ldap_dyndb' configuration failed: failure
loading configuration: failure
exiting (due to fatal error)

The configuration details related to bind in named.conf file is as below. 

dyndb ldap_dyndb "/usr/lib64/libldap.so" {
uri "ldap://10.12.42.113;;
base "cn=dns, dc=example, dc=com";
};

We are using bind 9.11 version package in RHEL 7.2 and have few queries as 
below. 
- We used the default RHEL "/usr/lib64/libldap.so" shared library in the above 
configuration. Is this correct? Is there any customized ldap.so file to be used 
for bind 9.11. 
- Are there any specific configure options to be enabled while compiling bind ?

Any inputs are highly appreciated and Thanks in advance. 

Thanks, 
Kishore.
___
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
___
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