[Unbound-users] "outgoing tcp": connect failed due to link-local destinations (and other bogus addresses)

[Jeroen Massar]

[2701:0] error: outgoing tcp: connect: Invalid argument
[2701:0] debug: failed address fe80:: port 53
[2701:0] error: serviced_tcp_initiate: failed to send tcp query
[2701:0] error: outgoing tcp: connect: Invalid argument
[2701:0] debug: failed address fe80:: port 53
[2701:0] error: serviced_tcp_initiate: failed to send tcp query

Seems somebody put fe80:: as a AAAA for a NS record in public DNS.

Would be fun to see what happens when somebody enters:

$ORIGIN example.com.
NS ns1.example.com
ns1 AAAA ff02::1

Or something similar, hence, please have a default option for filtering
out that kind of responses (for at least the outgoing connects by unbound.

And if there is such an option, should that not be a default?

(Browsers going to connect to local sites (RFC1918/link-local etc) is of
course a scary thing when it a remote site specifying some remotely
controlled DNS server specifying those local addresses, but that is a
browser issue).

Greets,
Jeroen

[Simon Deziel]

Post by Jeroen Massar
Seems somebody put fe80:: as a AAAA for a NS record in public DNS.
$ORIGIN example.com.
NS ns1.example.com
ns1 AAAA ff02::1
Or something similar, hence, please have a default option for filtering
out that kind of responses (for at least the outgoing connects by unbound.
And if there is such an option, should that not be a default?

You can add the following under "server:"

# Do not connect to IPv6 link-local addresses
do-not-query-address: fe80::/10

Regards,
Simon

[Yuri Schaeffer]

Hi Jeroen,

Post by Jeroen Massar
(Browsers going to connect to local sites (RFC1918/link-local etc)
is of course a scary thing when it a remote site specifying some
remotely controlled DNS server specifying those local addresses,
but that is a browser issue).

Using the "private-address" directive in unbound.conf, Unbound can
protect you against such DNS rebinding attacks.

Could you elaborate on the significance of querying multicast addresses?

Regards.,
Yuri

[Jeroen Massar]

Post by Yuri Schaeffer
Hi Jeroen,

Post by Jeroen Massar
(Browsers going to connect to local sites (RFC1918/link-local etc)
is of course a scary thing when it a remote site specifying some
remotely controlled DNS server specifying those local addresses,
but that is a browser issue).

Using the "private-address" directive in unbound.conf, Unbound can
protect you against such DNS rebinding attacks.

fe80::/10 should be in there per default then as without scope (which
AAAA records do not carry) one cannot connect to them anyway.

Post by Yuri Schaeffer
Could you elaborate on the significance of querying multicast addresses?

Unless one is trying to stuff a NS record pointing to mDNS (which won't
work globally and thus does not belong in a DNS AAAA record) it is
pretty futile.

Next to that there is a little bit of packet amplification, that
depending on the multicast-scope and router configuration can reach
quite far.

Like fe80::/10 not a useful thing to send packets too though, hence
should be considered unreachable per default.

Greets,
Jeroen

[W.C.A. Wijngaards]

Hi,

Post by Jeroen Massar

Post by Yuri Schaeffer
Hi Jeroen,

Post by Jeroen Massar
(Browsers going to connect to local sites (RFC1918/link-local
etc) is of course a scary thing when it a remote site
specifying some remotely controlled DNS server specifying those
local addresses, but that is a browser issue).

Using the "private-address" directive in unbound.conf, Unbound
can protect you against such DNS rebinding attacks.

fe80::/10 should be in there per default then as without scope
(which AAAA records do not carry) one cannot connect to them
anyway.

Post by Yuri Schaeffer
Could you elaborate on the significance of querying multicast
addresses?

Unless one is trying to stuff a NS record pointing to mDNS (which
won't work globally and thus does not belong in a DNS AAAA record)
it is pretty futile.
Next to that there is a little bit of packet amplification, that
depending on the multicast-scope and router configuration can
reach quite far.
Like fe80::/10 not a useful thing to send packets too though,
hence should be considered unreachable per default.

Yes that is true and multicast sends packets to too many destinations.
But then when I look at IPv4 that means blocking a large block of
address space where the RFC seems to talk about MBONE ... I am not
sure if blocking that address space in default DNS resolver
configuration is a good thing for IPv4 (future compatibility)?

multicast: block ff00::/8 and 224.0.0.0/4 and 255.255.255.255/32.
linkscope: block fe80::/10.
(linkscope ipv4 seems to be 224.0.0.0/24, but that is part of the
multicast IPv4 reservation).

Best regards,
Wouter