DLV dnssec setup

[Wolfgang Rosenauer]

Hi,

I'm pretty much new to DNSSEC and try to deploy my first bind to
support it correctly.
My bind version is 9.9.4P2 and what I did is the following just to
allow DNSSEC verification (no zone management yet):

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside . trust-anchor dlv.isc.org.;
managed-keys-directory "/var/lib/named/dyn/";

managed-keys {
# ISC DLV: See https://www.isc.org/solutions/dlv for details.
# NOTE: This key is activated by setting "dnssec-lookaside auto;"
# in named.conf.
dlv.isc.org. initial-key 257 3 5
"BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
TDN0YUuWrBNh";

# ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
# NOTE: This key is activated by setting "dnssec-validation auto;"
# in named.conf.
. initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};

I get strange behaviour which I cannot explain though:

bind startup shows
2014-07-10T12:43:52.621536+02:00 s15418965 named[29093]: using
built-in root key for view _default
2014-07-10T12:43:52.622344+02:00 s15418965 named[29093]: set up
managed keys zone for view _default, file
'/var/lib/named/dyn//managed-keys.bind'
[...]
2014-07-10T12:43:52.684928+02:00 s15418965 named[29093]:
managed-keys-zone: journal file is out of date: removing journal file
2014-07-10T12:43:52.685668+02:00 s15418965 named[29093]:
managed-keys-zone: loaded serial 31

Afterwards I see:
s15418965:/var/lib/named/log # dig @127.0.0.1 www.isc.org

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> @127.0.0.1 www.isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59813
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org. IN A

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 10 12:48:57 CEST 2014
;; MSG SIZE rcvd: 40

10-Jul-2014 12:48:47.466 dnssec: debug 3: validating @0x7f48140012e0:
. NS: starting
10-Jul-2014 12:48:47.466 dnssec: debug 3: validating @0x7f48140012e0:
. NS: attempting positive response validation
10-Jul-2014 12:48:47.483 dnssec: debug 3: validating @0x7f480c00c920:
. DNSKEY: starting
10-Jul-2014 12:48:47.483 dnssec: debug 3: validating @0x7f480c00c920:
. DNSKEY: attempting positive response validation
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f480c00c920:
. DNSKEY: verify rdataset (keyid=19036): success
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f480c00c920:
. DNSKEY: signed by trusted key; marking as secure
10-Jul-2014 12:48:47.484 dnssec: debug 3: validator @0x7f480c00c920:
dns_validator_destroy
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f48140012e0:
. NS: in fetch_callback_validator
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f48140012e0:
. NS: keyset with trust secure
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f48140012e0:
. NS: resuming validate
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f48140012e0:
. NS: verify rdataset (keyid=8230): success
10-Jul-2014 12:48:47.484 dnssec: debug 3: validating @0x7f48140012e0:
. NS: marking as secure, noqname proof not needed
10-Jul-2014 12:48:47.484 dnssec: debug 3: validator @0x7f48140012e0:
dns_validator_destroy

but also some working ones:

s15418965:/var/lib/named/log # dig @127.0.0.1 www.mailbox.org

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> @127.0.0.1 www.mailbox.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40561
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.mailbox.org. IN A

;; ANSWER SECTION:
www.mailbox.org. 900 IN A 80.241.60.194

;; AUTHORITY SECTION:
mailbox.org. 900 IN NS ns2.jpberlin.de.
mailbox.org. 900 IN NS ns.jpberlin.de.

;; ADDITIONAL SECTION:
ns.jpberlin.de. 86400 IN A 213.203.238.4
ns.jpberlin.de. 1800 IN AAAA 2001:67c:2050:1::53:1
ns2.jpberlin.de. 86400 IN A 194.150.191.56
ns2.jpberlin.de. 1800 IN AAAA 2001:67c:14c:12f::56:2

;; Query time: 487 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 10 12:52:17 CEST 2014
;; MSG SIZE rcvd: 194


Probably I miss some basic understanding but I'm confused about the
above behaviour.

Any explanations?


Thanks,
Wolfgang

[Tony Finch]

Wolfgang Rosenauer <wrose...@gmail.com> wrote:
>
> dnssec-validation auto;
> dnssec-lookaside . trust-anchor dlv.isc.org.;

Why not use dnssec-lookaside auto; ?

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
West Forties, Cromarty, Forth, Tyne, Dogger: Northerly or northwesterly 5 or
6, decreasing 4. Moderate becoming slight. Occasional rain, fog patches
developing. Good becoming moderate, occasionally very poor.

[Wolfgang Rosenauer]

On Thu, Jul 10, 2014 at 1:38 PM, Tony Finch <d...@dotat.at> wrote:
> Wolfgang Rosenauer <wrose...@gmail.com> wrote:
>>
>> dnssec-validation auto;
>> dnssec-lookaside . trust-anchor dlv.isc.org.;
>
> Why not use dnssec-lookaside auto; ?

No strong reason. I found many examples how to set it up during the
last two days.
Changed it now to dnssec-lookaside auto and it still behaves exactly
the same way.


Wolfgang

[Tony Finch]

Wolfgang Rosenauer <wrose...@gmail.com> wrote:

> Changed it now to dnssec-lookaside auto and it still behaves exactly
> the same way.

What happens if you delete the managed-keys files and restart?

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

North Utsire, South Utsire, East Forties: Variable, mainly northeasterly,
veering southeasterly, 3 or 4. Slight. Fog patches. Moderate or good,
occasionally very poor.

[Wolfgang Rosenauer]

On Thu, Jul 10, 2014 at 4:00 PM, Tony Finch <d...@dotat.at> wrote:
> Wolfgang Rosenauer <wrose...@gmail.com> wrote:
>
>> Changed it now to dnssec-lookaside auto and it still behaves exactly
>> the same way.
>
> What happens if you delete the managed-keys files and restart?

first thing:
2014-07-10T16:04:56.862405+02:00 s15418965 named[29815]:
managed-keys-zone: Unable to fetch DNSKEY set 'dlv.isc.org': timed out

Eventually the file appeared a bit later with the dlv.isc.org key.

For the rest: Exactly the same issue as before :-(


Thanks,
Wolfgang

[Tony Finch]

Wolfgang Rosenauer <wrose...@gmail.com> wrote:
>
> first thing:
> 2014-07-10T16:04:56.862405+02:00 s15418965 named[29815]:
> managed-keys-zone: Unable to fetch DNSKEY set 'dlv.isc.org': timed out
>
> Eventually the file appeared a bit later with the dlv.isc.org key.

Suspicious. What do you get if you run
dig +short rs.dns-oarc.net txt

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

Humber, Thames, Dover: North or northwest 4 or 5, occasionally 6 until later.
Moderate, occasionally rough at first, becoming slight. Rain or thundery
showers, fog patches developing. Moderate, occasionally very poor.

[Wolfgang Rosenauer]

On Thu, Jul 10, 2014 at 4:16 PM, Tony Finch <d...@dotat.at> wrote:
>
> Suspicious. What do you get if you run
> dig +short rs.dns-oarc.net txt

s15418965:~ # dig +short rs.dns-oarc.net txt
rst.x479.rs.dns-oarc.net.
rst.x488.x479.rs.dns-oarc.net.
rst.x493.x488.x479.rs.dns-oarc.net.
"2001:8d8:870:1200::53 DNS reply size limit is at least 493 bytes"
"2001:8d8:870:1200::53 lacks EDNS, defaults to 512"


Wolfgang

[Mark Andrews]

Firstly upgrade. You are out of date.

Secondly fix your firewall. You need to allow through 4K DNS UDP
messages. You need to turn off whatever is blocking the bigger
packets and you also need to allow through fragmented UDP packets.

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> 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: ma...@isc.org

[Wolfgang Rosenauer]

On Thu, Jul 10, 2014 at 4:54 PM, Mark Andrews <ma...@isc.org> wrote:
>
> Firstly upgrade. You are out of date.

I currently run a distribution provided version which is pretty new
compared with most published Linux distributions but if it helps I
would do that as well.

> Secondly fix your firewall. You need to allow through 4K DNS UDP
> messages. You need to turn off whatever is blocking the bigger
> packets and you also need to allow through fragmented UDP packets.

ok, now this is probably tough.
There is no firewall involved which I could control. I'll see what can
be done. This server runs on virtuozzo/openvz at a hosting provider.


Thanks,
Wolfgang

[Wolfgang Rosenauer]

btw, don't know what that means exactly.
In addition the output above to test the UDP sizes when I do that on
the correct/my bind:

s15418965:~ # dig @127.0.0.1 +short rs.dns-oarc.net txt

there is no output at all. Is that also expected and the reason is the
UDP limitation?


Thanks,
Wolfgang

[Tony Finch]

Wolfgang Rosenauer <wrose...@gmail.com> wrote:
>
> s15418965:~ # dig @127.0.0.1 +short rs.dns-oarc.net txt
>
> there is no output at all. Is that also expected and the reason is the
> UDP limitation?

Yes.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

Trafalgar: Easterly or northeasterly 5 to 7, decreasing 4 in southeast.
Moderate or rough. Fair. Good.

[Wolfgang Rosenauer]

ok, sorry for the confusion but I think what's more relevant is that

s15418965:~ # dig @127.0.0.1 +short rs.dns-oarc.net txt

rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"87.106.30.170 DNS reply size limit is at least 3843 bytes"
"87.106.30.170 sent EDNS buffer size 4096"

This is what I get when I turn off DNSSEC and ask the server I'm
trying to set up.
When I enable DNSSEC again there is no response at all. So please tell
me if that still is is a problem.


Thanks,
Wolfgang

[Mark Andrews]

In message <CALm7FAcLUvwF5Jq1JCXxqw6L...@mail.gmail.com>

Then all of the following should succeed. Please let the
list know how you go.

dig soa . @198.41.0.4 +norec
dig soa . @198.41.0.4 +dnssec +norec
dig dnskey . @198.41.0.4 +dnssec +norec
dig ds com @198.41.0.4 +dnssec +norec
dig com @198.41.0.4 +dnssec +norec

dig soa . @198.41.0.4 +tcp +norec
dig soa . @198.41.0.4 +dnssec +tcp +norec
dig dnskey . @198.41.0.4 +dnssec +tcp +norec
dig ds com @198.41.0.4 +dnssec +tcp +norec
dig com @198.41.0.4 +dnssec +tcp +norec

dig dnskey org +dnssec @199.19.56.1 +ignore +norec
dig dnskey org +dnssec @199.19.56.1 +tcp +norec

[Wolfgang Rosenauer]

On Fri, Jul 11, 2014 at 1:32 AM, Mark Andrews <ma...@isc.org> wrote:
>
> Then all of the following should succeed. Please let the
> list know how you go.
>
> dig soa . @198.41.0.4 +norec
> dig soa . @198.41.0.4 +dnssec +norec
> dig dnskey . @198.41.0.4 +dnssec +norec
> dig ds com @198.41.0.4 +dnssec +norec
> dig com @198.41.0.4 +dnssec +norec
>
> dig soa . @198.41.0.4 +tcp +norec
> dig soa . @198.41.0.4 +dnssec +tcp +norec
> dig dnskey . @198.41.0.4 +dnssec +tcp +norec
> dig ds com @198.41.0.4 +dnssec +tcp +norec
> dig com @198.41.0.4 +dnssec +tcp +norec
>
> dig dnskey org +dnssec @199.19.56.1 +ignore +norec
> dig dnskey org +dnssec @199.19.56.1 +tcp +norec

All but one request succeeded:
s15418965:~ # dig dnskey org +dnssec @199.19.56.1 +ignore +norec

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> dnskey org +dnssec @199.19.56.1
+ignore +norec
;; global options: +cmd
;; connection timed out; no servers could be reached

I've captured with tcpdump (filter on port 53) and there were 3
queries but no single reply packet.
IP is reachable though.
s15418965:~ # ping 199.19.56.1
PING 199.19.56.1 (199.19.56.1) 56(84) bytes of data.
64 bytes from 199.19.56.1: icmp_seq=1 ttl=55 time=130 ms


Wolfgang

[Mark Andrews]

In message <CALm7FAdeV4eqiAZc2vP=mnPKv4dO3C9YZu2...@mail.gmail.com>

, Wolfgang Rosenauer writes:
> On Fri, Jul 11, 2014 at 1:32 AM, Mark Andrews <ma...@isc.org> wrote:
> >
> > Then all of the following should succeed. Please let the
> > list know how you go.
> >
> > dig soa . @198.41.0.4 +norec
> > dig soa . @198.41.0.4 +dnssec +norec
> > dig dnskey . @198.41.0.4 +dnssec +norec
> > dig ds com @198.41.0.4 +dnssec +norec
> > dig com @198.41.0.4 +dnssec +norec
> >
> > dig soa . @198.41.0.4 +tcp +norec
> > dig soa . @198.41.0.4 +dnssec +tcp +norec
> > dig dnskey . @198.41.0.4 +dnssec +tcp +norec
> > dig ds com @198.41.0.4 +dnssec +tcp +norec
> > dig com @198.41.0.4 +dnssec +tcp +norec
> >
> > dig dnskey org +dnssec @199.19.56.1 +ignore +norec
> > dig dnskey org +dnssec @199.19.56.1 +tcp +norec
>
> All but one request succeeded:
> s15418965:~ # dig dnskey org +dnssec @199.19.56.1 +ignore +norec
>
> ; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> dnskey org +dnssec @199.19.56.1
> +ignore +norec
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached

Which requires fragmented UDP to be passed by the firewall. The
rest of the test udp responses will all fit in a ethernet frame.

Test with

dig dnskey org +dnssec @199.19.56.1 +ignore +norec +bufsize=1432

Then set "edns-udp-size 1432;" in named.conf until you can get the firewall
fixed. This size allows for 4in6 and 6in4 encapuslations w/o fragmentation.

> I've captured with tcpdump (filter on port 53) and there were 3
> queries but no single reply packet.
> IP is reachable though.
> s15418965:~ # ping 199.19.56.1
> PING 199.19.56.1 (199.19.56.1) 56(84) bytes of data.
> 64 bytes from 199.19.56.1: icmp_seq=1 ttl=55 time=130 ms
>
>
> Wolfgang

[Wolfgang Rosenauer]

Hello all,

first let me thank you for your patience.

On Fri, Jul 11, 2014 at 10:47 AM, Mark Andrews <ma...@isc.org> wrote:
>
> In message <CALm7FAdeV4eqiAZc2vP=mnPKv4dO3C9YZu2...@mail.gmail.com>
> , Wolfgang Rosenauer writes:
>> All but one request succeeded:
>> s15418965:~ # dig dnskey org +dnssec @199.19.56.1 +ignore +norec
>>
>> ; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> dnskey org +dnssec @199.19.56.1
>> +ignore +norec
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>
> Which requires fragmented UDP to be passed by the firewall. The
> rest of the test udp responses will all fit in a ethernet frame.
>
> Test with
>
> dig dnskey org +dnssec @199.19.56.1 +ignore +norec +bufsize=1432

seems to work:
s15418965:/var/lib/named/log # dig dnskey org +dnssec @199.19.56.1
+ignore +norec +bufsize=1432

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> dnskey org +dnssec @199.19.56.1

+ignore +norec +bufsize=1432

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21075
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;org. IN DNSKEY

;; Query time: 131 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Fri Jul 11 11:19:15 CEST 2014
;; MSG SIZE rcvd: 32

> Then set "edns-udp-size 1432;" in named.conf until you can get the firewall
> fixed. This size allows for 4in6 and 6in4 encapuslations w/o fragmentation.

done that and basic resolution still is broken :-(

s15418965:/var/lib/named/log # dig @127.0.0.1 isc.org

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> @127.0.0.1 isc.org

; (1 server found)
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20035

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;isc.org. IN A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 11 11:19:58 CEST 2014
;; MSG SIZE rcvd: 36

I'm running out of ideas.
Meanwhile I've confirmed that the same setup and software versions
work on another hosted machine (bare metal, different hoster) so I
really agree it is some strange network setup. I'll ask the provider
again what's wrong but I'm really lost why I can ask an external bind
successfully while my own one still does not get the reply back.


Wolfgang