From Leo.Baltus at omroep.nl  Thu Feb  6 13:56:02 2014
From: Leo.Baltus at omroep.nl (Leo Baltus)
Date: Thu, 6 Feb 2014 14:56:02 +0100
Subject: [ldns-users] drill -I
Message-ID: <20140206135602.GC25117@omroep.nl>

Hi,

ldns-1.6.17 now supports -I (thanks!), however it seems it does not
resolve the argument:

$ host qry2bns
qry2bns.omroep.nl has address 145.58.31.52
qry2bns.omroep.nl has IPv6 address 2a02:458:101:31::34

$ drill -D -T -I qry2bns -k root.key  foo.bar.com
;; Number of trusted keys: 1
-I must be (or resolve) to a valid IP[v6] address.

Also, it seems when given an IPv6 address, it tries to bind to an
IPv4 socket:

$ strace -f drill -D -T -I 2a02:458:101:31::34 -k root.key foo.bar.com
<snip>
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 47
bind(47, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "2a02:458:101:31::34", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT (Address family not supported by protocol)

I guess PF_INET should be PF_INET6?

-- 
Leo Baltus, internetbeheerder
NPO ICT Internet Services
Bart de Graaffweg 2, 1217 ZL Hilversum
servicedesk at omroep.nl, 035-6773555


From bduff at ecessa.com  Thu Feb  6 16:04:00 2014
From: bduff at ecessa.com (Bryan Duff)
Date: Thu, 06 Feb 2014 10:04:00 -0600
Subject: [ldns-users] drill -I
In-Reply-To: <20140206135602.GC25117@omroep.nl>
References: <20140206135602.GC25117@omroep.nl>
Message-ID: <52F3B270.2020503@ecessa.com>

Looks like even being more explicit fails as well:
# drill -6 @2001:4860:4860::8888 -I 2001:X:..:X::2 ipv6.google.com

This works - forcing IPv6.

-Bryan

On 02/06/2014 07:56 AM, Leo Baltus wrote:
> Hi,
>
> ldns-1.6.17 now supports -I (thanks!), however it seems it does not
> resolve the argument:
>
> $ host qry2bns
> qry2bns.omroep.nl has address 145.58.31.52
> qry2bns.omroep.nl has IPv6 address 2a02:458:101:31::34
>
> $ drill -D -T -I qry2bns -k root.key  foo.bar.com
> ;; Number of trusted keys: 1
> -I must be (or resolve) to a valid IP[v6] address.
>
> Also, it seems when given an IPv6 address, it tries to bind to an
> IPv4 socket:
>
> $ strace -f drill -D -T -I 2a02:458:101:31::34 -k root.key foo.bar.com
> <snip>
> socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 47
> bind(47, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "2a02:458:101:31::34", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT (Address family not supported by protocol)
>
> I guess PF_INET should be PF_INET6?
>



From paul at nohats.ca  Tue Feb 25 16:46:34 2014
From: paul at nohats.ca (Paul Wouters)
Date: Tue, 25 Feb 2014 11:46:34 -0500 (EST)
Subject: [ldns-users] [validns-users] just started with validns - few
	problems
In-Reply-To: <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
Message-ID: <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>

On Mon, 24 Feb 2014, Emil Natan wrote:

> When I ran validns on the zone with missing SOA record:
> 
> validns -z test.org test.org.zone.bad?
> test.org.zone.bad:6: the first record in the zone must be an SOA record

> When I have bigger zone, at some point it Seg faults.
> 
> Running on the signed zone:
> 
> ?validns -s -z test.org test.org.zone.signed.bad?
> records found: ? ? ? 43
> skipped dups: ? ? ? ?0
> record sets found: ? 33
> unique names found: ?15
> delegations found: ? 0
> ? ? nsec3 records: ? 7
> not authoritative names, not counting delegation points:
> ? ? ? ? ? ? ? ? ? ? ?0
> validation errors: ? 0
> signatures verified: 19
> time taken: ? ? ? ? ?0.004s

Note that the signing process _added_ a SOA record, so while the
unsigned zone was broken, the signed zone was not.

Although validns should probably also warn about nameservers being
within the zone but not have an A/AAAA record. In this case, it is
even true for _all_ nameservers so the zone is basically dead.

ldns-verify-zone also does not complain about that. It should.

named-checkzone handles that properly:

$ named-checkzone test.org  /tmp/test.org.zone.signed.bad 
zone test.org/IN: NS 'ns.test.org' has no address records (A or AAAA)
zone test.org/IN: NS 'ns2.test.org' has no address records (A or AAAA)
zone test.org/IN: NS 'ns3.test.org' has no address records (A or AAAA)
zone test.org/IN: not loaded due to errors.

> Running ldns-verify-zone on the same zone:
> 
> ldns-verify-zone test.org.zone.signed.bad
> Error: no signatures for test.org. ? ? ?NSEC3PARAM
> There were errors in the zone

I guess one could argue about whether NSEC3PARAM should be signed or
not. IMHO, it should not even be in the zone at all, its a bind/isc hack
that made it into an RFC :P Perhaps ldns-verify-zone should not give
an error for that? Although I wonder which signers actually skip signing
the NSEC3PARAM record. That a bind signer thing as isc.org's nsec3param
also seems to miss the RRSIG record for NSEC3PARAM.

opendnssec does sign it.

However, ldns-verify-zone does give a bad error when running on the
SOA-less zone:

~> ldns-verify-zone /tmp/test.org.zone.bad 
General memory error at 19

So I've CC:ed the ldns list on this :)

Paul


From willem at nlnetlabs.nl  Wed Feb 26 09:45:44 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 26 Feb 2014 10:45:44 +0100
Subject: [ldns-users] [validns-users] just started with validns - few
 problems
In-Reply-To: <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
Message-ID: <530DB7C8.2050506@nlnetlabs.nl>

op 25-02-14 17:46, Paul Wouters schreef:
> Although validns should probably also warn about nameservers being
> within the zone but not have an A/AAAA record. In this case, it is
> even true for _all_ nameservers so the zone is basically dead.
> 
> ldns-verify-zone also does not complain about that. It should.

Roger.

>> Running ldns-verify-zone on the same zone:
>>
>> ldns-verify-zone test.org.zone.signed.bad
>> Error: no signatures for test.org.      NSEC3PARAM
>> There were errors in the zone
> 
> I guess one could argue about whether NSEC3PARAM should be signed or
> not. IMHO, it should not even be in the zone at all, its a bind/isc hack
> that made it into an RFC :P Perhaps ldns-verify-zone should not give
> an error for that? Although I wonder which signers actually skip signing
> the NSEC3PARAM record. That a bind signer thing as isc.org's nsec3param
> also seems to miss the RRSIG record for NSEC3PARAM.

Hmmm... food for thought.  I'll discuss/look into it.

> However, ldns-verify-zone does give a bad error when running on the
> SOA-less zone:
> 
> ~> ldns-verify-zone /tmp/test.org.zone.bad General memory error at 19

Ouch! That I've fixed immediately:
http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=8c25800e

> So I've CC:ed the ldns list on this :)

Merci!

-- Willem



From jelte.jansen at sidn.nl  Wed Feb 26 10:51:43 2014
From: jelte.jansen at sidn.nl (Jelte Jansen)
Date: Wed, 26 Feb 2014 11:51:43 +0100
Subject: [ldns-users] [validns-users] just started with validns - few
 problems
In-Reply-To: <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
Message-ID: <530DC73F.4030906@sidn.nl>

On 02/25/2014 05:46 PM, Paul Wouters wrote:
> 
> I guess one could argue about whether NSEC3PARAM should be signed or
> not. IMHO, it should not even be in the zone at all, its a bind/isc hack
> that made it into an RFC :P Perhaps ldns-verify-zone should not give
> an error for that? Although I wonder which signers actually skip signing
> the NSEC3PARAM record. That a bind signer thing as isc.org's nsec3param
> also seems to miss the RRSIG record for NSEC3PARAM.
> 

While you could argue the rationale of the NSEC3PARAM record versus
other ways to signal to auths which nsec3 chain to use, calling it a
bind hack that got copied into an rfc is misrepresenting history, IIRC
this came out of a WG workshop where other implementors (hi!) were just
as present as those from ISC :p

As it is right now, you certainly can't just leave it out of the zone. I
don't personally see why you would then special case it further and skip
it during signing (it is indeed not necessary in the validation
process), but hey. Bind's signers certainly do sign it.

Jelte




From paul at nohats.ca  Wed Feb 26 15:38:11 2014
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 26 Feb 2014 10:38:11 -0500 (EST)
Subject: [ldns-users] offtopic - was Re: [validns-users] just started with
 validns - few problems
In-Reply-To: <530DC73F.4030906@sidn.nl>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
 <530DC73F.4030906@sidn.nl>
Message-ID: <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>

On Wed, 26 Feb 2014, Jelte Jansen wrote:

> While you could argue the rationale of the NSEC3PARAM record versus
> other ways to signal to auths which nsec3 chain to use, calling it a
> bind hack that got copied into an rfc is misrepresenting history, IIRC
> this came out of a WG workshop where other implementors (hi!) were just
> as present as those from ISC :p

Fait enough

> As it is right now, you certainly can't just leave it out of the zone.

Why not? When is it served as authoritative data? When does a validator
require that record?

>From what I understand, it's a postit note for signers, and signers that
are also authoritative servers in the same process (like bind :) need
it?

Paul


From matthijs at nlnetlabs.nl  Wed Feb 26 15:40:17 2014
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 26 Feb 2014 16:40:17 +0100
Subject: [ldns-users] [validns-users] offtopic - was Re: just started
 with validns - few problems
In-Reply-To: <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>	<20140223171745.GA52408@macbook.bluepipe.net>	<CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>	<alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>	<530DC73F.4030906@sidn.nl>
 <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
Message-ID: <530E0AE1.5070706@nlnetlabs.nl>

On 02/26/2014 04:38 PM, Paul Wouters wrote:
> On Wed, 26 Feb 2014, Jelte Jansen wrote:
> 
>> While you could argue the rationale of the NSEC3PARAM record versus
>> other ways to signal to auths which nsec3 chain to use, calling it a
>> bind hack that got copied into an rfc is misrepresenting history, IIRC
>> this came out of a WG workshop where other implementors (hi!) were just
>> as present as those from ISC :p
> 
> Fait enough
> 
>> As it is right now, you certainly can't just leave it out of the zone.
> 
> Why not? When is it served as authoritative data? When does a validator
> require that record?

It is required for the secondaries. Otherwise it would be a hell to know
which NSEC3 chain is used.

Best regards,
  Matthijs


> 
>> From what I understand, it's a postit note for signers, and signers that
> are also authoritative servers in the same process (like bind :) need
> it?
> 
> Paul
> _______________________________________________
> validns-users mailing list
> validns-users at x0.dk
> http://x0.dk/mailman/listinfo/validns-users



From jelte.jansen at sidn.nl  Wed Feb 26 15:44:02 2014
From: jelte.jansen at sidn.nl (Jelte Jansen)
Date: Wed, 26 Feb 2014 16:44:02 +0100
Subject: [ldns-users] offtopic - was Re: [validns-users] just started
 with validns - few problems
In-Reply-To: <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
 <530DC73F.4030906@sidn.nl>
 <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
Message-ID: <530E0BC2.4040209@sidn.nl>

On 02/26/2014 04:38 PM, Paul Wouters wrote:
> 
>> As it is right now, you certainly can't just leave it out of the zone.
> 
> Why not? When is it served as authoritative data? When does a validator
> require that record?
> 
> From what I understand, it's a postit note for signers, and signers that
> are also authoritative servers in the same process (like bind :) need
> it?
> 

Nono, the signer is actually the one that wouldn't need it :)

In theory (and in some re-salt rollover scenario's), you can have
multiple nsec3 chains in your zone, some of which may not actually be
complete at all (so you can gradually update to your new chain). The
NSEC3PARAM records signals to the *serving* auths which chain is the
complete-and-active one to pick the NSEC3 records from when building a
response (and barring any NSEC3PARAM record it should probably be
looking for normal NSECs, even if there are some NSEC3 records there).

A validator indeed does not need it.

Jelte


From paul at nohats.ca  Wed Feb 26 15:45:12 2014
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 26 Feb 2014 10:45:12 -0500 (EST)
Subject: [ldns-users] [validns-users] offtopic - was Re: just started
 with validns - few problems
In-Reply-To: <530E0AE1.5070706@nlnetlabs.nl>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
 <530DC73F.4030906@sidn.nl> <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
 <530E0AE1.5070706@nlnetlabs.nl>
Message-ID: <alpine.LFD.2.10.1402261044500.3528@bofh.nohats.ca>

On Wed, 26 Feb 2014, Matthijs Mekking wrote:

>> Why not? When is it served as authoritative data? When does a validator
>> require that record?
>
> It is required for the secondaries. Otherwise it would be a hell to know
> which NSEC3 chain is used.

Ahhh. I see. That makes sense. I stand corrected!

Paul


From dot at dotat.at  Wed Feb 26 16:28:44 2014
From: dot at dotat.at (Tony Finch)
Date: Wed, 26 Feb 2014 16:28:44 +0000
Subject: [ldns-users] offtopic - was Re: [validns-users] just started
 with validns - few problems
In-Reply-To: <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
References: <CAG=4S2CQhnGcyETEroK09=XtTxc5FrWSep1WYfsO33yEnpzH6Q@mail.gmail.com>
 <20140223171745.GA52408@macbook.bluepipe.net>
 <CAG=4S2D-F+U+_fTHCBsCP+nA+DeYsZv-s2XUzMmMLbq-L2ZnGw@mail.gmail.com>
 <alpine.LFD.2.10.1402251137060.12577@bofh.nohats.ca>
 <530DC73F.4030906@sidn.nl> <alpine.LFD.2.10.1402261036130.3528@bofh.nohats.ca>
Message-ID: <alpine.LSU.2.00.1402261627200.18502@hermes-1.csi.cam.ac.uk>

Paul Wouters <paul at nohats.ca> wrote:
>
> From what I understand, it's a postit note for signers, and signers that
> are also authoritative servers in the same process (like bind :) need
> it?

That is a fair description of BIND's private TYPE65534 records.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Hebrides, Bailey: Cyclonic 4 or 5, becoming southeast, then veering southwest
later, 6 to gale 8. Rough or very rough, occasionally high in south. Rain or
showers. Good, occasionally poor.


From klaus.mailinglists at pernau.at  Fri Feb 28 13:56:54 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Fri, 28 Feb 2014 14:56:54 +0100
Subject: [ldns-users] drill difference between chasing and tracing
Message-ID: <531095A6.1010606@pernau.at>

Hi!

        -T     Trace name from the root down. When using this option the 
@server and the type arguments are not used.

        -S     Chase the signature(s) of 'name' to a known key or as 
high up in the tree as possible.


Can someone please describe the difference between tracing and chasing?

E.g. when chasing (-S), does drill only verify that the DS record in the 
parent matches a DNSKEY in the child zone, or does it also verify the 
the signatures of the recors? (I use it with the -k option).


Further, -T states that the type argument is not used, but it is as far 
as I see

# drill -T -D -k anchors-fake-root -r db.root www.subdomain.brussels A
...
[S] www.subdomain.brussels.     300     IN      A       127.0.0.1
;;[S] self sig OK; [B] bogus; [T] trusted


# drill -T -D -k anchors-fake-root -r db.root www.subdomain.brussels AAAA
...
[S] Existence denied: www.subdomain.brussels. AAAA
;;[S] self sig OK; [B] bogus; [T] trusted


Thanks
Klaus


From willem at nlnetlabs.nl  Fri Feb 28 14:20:54 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 28 Feb 2014 15:20:54 +0100
Subject: [ldns-users] drill difference between chasing and tracing
In-Reply-To: <531095A6.1010606@pernau.at>
References: <531095A6.1010606@pernau.at>
Message-ID: <53109B46.7060608@nlnetlabs.nl>

Hi Klaus,

When chasing, drill acts as a stub resolver, and follows the DNSSEC
chain against the provided nameserver (or nameservers from
/etc/resolv.conf) from the name up to the root (or earlier if your
trust-anchor is below the root).

When tracing, drill acts as a recursive resolver and starts by asking
the root for the name, and together with processing the received
references query for the links in the DNSSEC chain leading down to the name.

op 28-02-14 14:56, Klaus Darilion schreef:
> Further, -T states that the type argument is not used, but it is as far
> as I see

I know.  This "statement" is removed in the development branch of the
git repository.

Hope this helps,

-- Willem


From klaus.mailinglists at pernau.at  Fri Feb 28 15:03:37 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Fri, 28 Feb 2014 16:03:37 +0100
Subject: [ldns-users] drill for zone monitoring
Message-ID: <5310A549.5010800@pernau.at>

Hi!

I thought about using drill for the monitoring of my signed zone.

AFAIS for "tracing", the exit code can not be used as indication, as 
also [S] self-signed and [U] unsigned may trigger an exit code of 0.

For "chasing" it seems that if 'name' is unsigned or can not be 
validated, the exit code !=0. Is this always the case - can I use 
"chasing" and check the exit code to reliable detect errors in my DNSSEC 
setup?

Thanks
Klaus


From klaus.mailinglists at pernau.at  Fri Feb 28 15:04:26 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Fri, 28 Feb 2014 16:04:26 +0100
Subject: [ldns-users] drill difference between chasing and tracing
In-Reply-To: <531095A6.1010606@pernau.at>
References: <531095A6.1010606@pernau.at>
Message-ID: <5310A57A.4090804@pernau.at>



On 28.02.2014 14:56, Klaus Darilion wrote:
> Hi!
>
>         -T     Trace name from the root down. When using this option the
> @server and the type arguments are not used.
>
>         -S     Chase the signature(s) of 'name' to a known key or as
> high up in the tree as possible.
>
>
> Can someone please describe the difference between tracing and chasing?
>
> E.g. when chasing (-S), does drill only verify that the DS record in the
> parent matches a DNSKEY in the child zone, or does it also verify the
> the signatures of the recors? (I use it with the -k option).

Answering myself:
-T goes from root (or root hint) up to 'name'
-S goes from 'name' down to root

But is there a difference in the quality of the result? Is one 
recommended if I want to check the proper signing of my zone?

Thanks
Klaus