Discussion:
DNSEC and Bin 9.12
(too old to reply)
@lbutlr
2019-01-21 19:32:19 UTC
Permalink
A couple of questions

First, guides on setting up DNSSEC say to add dnssec-lookaside auto; in the options, but bind repots an error:

/usr/local/etc/namedb/named.conf:35: dnssec-lookaside 'auto' is no longer supported

Does this mean the entire declaration is not supported, or that auto should be changed to something else?

Second, I’ve seen recommendations for " dnssec-validation auto;” and " dnssec-validation yes;” but no clear explanation on which should be used.

Third, what does “not at top of zone” mean in dnssec-verify?
--
Heisenberg's only uncertainty was what pub to vomit in next and Jung
fancied Freud's mother too. -- Jared Earle
Mark Andrews
2019-01-21 20:49:03 UTC
Permalink
Post by @lbutlr
A couple of questions
/usr/local/etc/namedb/named.conf:35: dnssec-lookaside 'auto' is no longer supported
Does this mean the entire declaration is not supported, or that auto should be changed to something else?
The DLV registry “dlv.isc.org” has been shutdown. It is now a empty zone answer which answers with NXDOMAIN
for anyone that still has a dnssec-lookaside clause that pointed to in named.conf or the equivalent in other
name servers. "dnssec-lookaside auto;” and “dnssec-lookaside . dlv.isc.org;” are both rejected by modern
versions of BIND.
Post by @lbutlr
Second, I’ve seen recommendations for "dnssec-validation auto;” and " dnssec-validation yes;”but no clear explanation on which should be used.
Use 'dnssec-validation auto;’ if you are on the Internet. Use ‘dnssec-validation yes;’ if you
are on a disconnected network.
Post by @lbutlr
Third, what does “not at top of zone” mean in dnssec-verify?
Some record that should have been at the zone’s apex (name) wasn’t. Either you passed the wrong
zone name to dnssec-verify or you have put records in the wrong place in the zone.

e.g.

DNSKEY, SOA and NSEC3PARAM records should only be at the top of a zone.
NS records exist at top and they define the bottom of a zone.
DS records should only exist at the NS records that define bottom of zone and
never at the zone’s apex nor in the middle of a zone.
Post by @lbutlr
--
Heisenberg's only uncertainty was what pub to vomit in next and Jung
fancied Freud's mother too. -- Jared Earle
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
@lbutlr
2019-01-26 19:20:49 UTC
Permalink
On 21 Jan 2019, at 13:49, Mark Andrews <***@isc.org> wrote:

Thanks for the info on the first two questions.
Post by Mark Andrews
Post by @lbutlr
Third, what does “not at top of zone” mean in dnssec-verify?
Some record that should have been at the zone’s apex (name) wasn’t. Either you passed the wrong
zone name to dnssec-verify or you have put records in the wrong place in the zone.
OK, named-checkzone returns "OK" but the dnssec-verify complains about not at top of zone.

Ah, wait, no, I was doing it wrong.

Now both commands return success, but after reloading bind and trying to query localhost for the DNSEC information it returns nothing.

I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone record in name.conf and now everything is behaving as expected when I query localhost for the DNSSEC info. (I know this is not complete until I update the records at the registrar, but I am not ready to do that).

Which brings up one more question, what sort of maintenance/renewal process do I need to implement, if any? Once the zone is signed I assume that signature expires at some point. when I edit the conf file, I will have to manually regenerate the sonf.signed file since I had to remove "auto-dnssec maintain", yes?
--
'You know the worst of it?' said Rincewind.
'Oook?'
'I don't even remember walking under a mirror.' --Mort
@lbutlr
2019-01-26 19:30:06 UTC
Permalink
Post by @lbutlr
I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone record in name.conf and now everything is behaving as expected when I query localhost for the DNSSEC info.
I should have said, I have update-policy local; in the zone record, but if I add "inline-signing yes;" and/or "auto-dnssec allow;" then the query fails.
--
Rick: And remember, this gun is pointed right at your heart. Captain Renault: That is my *least* vulnerable spot
Alan Clegg
2019-01-26 19:55:18 UTC
Permalink
Post by @lbutlr
Post by @lbutlr
I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone record in name.conf and now everything is behaving as expected when I query localhost for the DNSSEC info.
I should have said, I have update-policy local; in the zone record, but if I add "inline-signing yes;" and/or "auto-dnssec allow;" then the query fails.
I have the following snippet in my named.conf and it works great:

zone "boat" {
type master;
file "zone/boat";
update-policy local;
auto-dnssec maintain;
notify no;
};

This is a "fake TLD" for "boat" that I maintain locally (on my boat).

It is DNSSEC signed, updates signatures automatically (as needed) and is
able to be updated locally (nsupdate -l).

I created the keys using something along the lines of:

***@svlg-gateway:~# dnssec-keygen -a rsasha256 boat
Generating key pair...........+++++ ......+++++
Kboat.+008+41586
***@svlg-gateway:~# dnssec-keygen -f k -a rsasha256 boat
Generating key
pair........................................................+++++
.............................................+++++

then, making sure that the keys were in the directory specified by
key-directory option, I did an "rndc loadkeys".

With the appropriate trust anchors in place, data in the zone validates.

Does this help at all? If not, can you be a bit more detailed in the
problem you are trying to solve?

AlanC
@lbutlr
2019-01-26 23:03:59 UTC
Permalink
Post by Alan Clegg
With the appropriate trust anchors in place, data in the zone validates.
Everything appears to be working locally at this point, including with "auto-dnssec maintain;" which I swear was not working a few hours ago. Perhaps I tyoped.
Post by Alan Clegg
Does this help at all? If not, can you be a bit more detailed in the problem you are trying to solve?
Just trying to get the configuration right before I go add the DNSSEC to the registrar, and also trying to understand how it is all supposed to work so I don't run into any surprises in a week or a month or a year (especially the latter, when I will have forgotten everything).
--
"His mother should have thrown him away and kept the stork." - Mae West
@lbutlr
2019-01-29 13:53:17 UTC
Permalink
Post by @lbutlr
A couple of questions
I’d like to thank everyone who helped out on this, got it all sorted, added to the registrar, and it is all working, Now to do it for all the other domains. :)
--
The most perfidious way of harming a cause consists of defending it
deliberately with faulty arguments.
Loading...