Page MenuHomeVyOS Platform

pdns recursor does not resolve .io domains
Closed, InvalidPublicBUG

Description

Bug description:

For example, the hosts api.snapcraft.io and vyos.io cannot be resolved from "behind" VyOS. On VyOS itself, they resolve fine.

Expected behavior:

VyOS allows correct resolving of all existing domains, including its own website :-)

Best!
Al

PS: Version information:
VyOS 1.3-rolling-202004111646 (self-built, d64011558e3257-dirty); pdns-recursor v4.2.1-1pdns.buster

VyOS DNS forwarder config:

vyos@vyos# show service dns 
 forwarding {
     allow-from 192.168.45.0/24
     allow-from 192.168.44.0/24
     allow-from 192.168.30.0/24
     allow-from 192.168.20.0/24
     allow-from 172.31.255.0/24
     cache-size 512
     dnssec off
     listen-address 192.168.45.254
     listen-address 172.31.255.1
     listen-address 192.168.30.254
     listen-address 192.168.44.254
     listen-address 192.168.20.254
     name-server 192.168.0.100
     name-server 8.8.4.4
     name-server 8.8.8.8
 }
[edit]
vyos@vyos#

Details

Difficulty level
Unknown (require assessment)
Version
VyOS 1.3-rolling-202004111646 (self-built, d64011558e3257-dirty); pdns-recursor v4.2.1-1pdns.buster
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

Found the culprit.

I had a host named "io" in the same subnet which received its IP by DHCP. DHCP was set to update the /etc/hosts:

set service dhcp-server hostfile-update

Resulting workaround:
1.) remove the entry for "io" from /etc/hosts
2.) delete service dhcp-server hostfile-update
3.) set service dhcp-server shared-network-name WIFI subnet 192.168.XX.YY/24 domain-name mydomain.local
4.) commit && save

However, this is not really an answer as I still miss the part why the entry for a hostname "io" supersedes the TLD ".io"...

That's how DNS forwarders usually work. If they can find a domain
locally, they'll use it, if not forward to upstream. The same behaviour
is everywhere, on all resolvers.

hostsfile-update allows DNS poisoning attacks as any DHCP client
(untrusted) can set its hostname to a domain it wants to spoof, and it
gets the DNS for it turned to its IP. You couldn't ask for a better MITM
attack vector.

hostsfile-update should be used strictly in very tightly controlled
network segments where there *can't* be a untrusted client - which is
more or less *never* (you'd need to keep the whole L2 segment behind
locked doors, never have a cable leaving it).

The way to do dynamic DNS updates is with a DNS server with RFC2136 with
authorization and access control. For example FreeIPA does it that way
with PKI authenticated hosts.

Perhaps the docs and the command completion help should have a big
warning about using it.

Apr 14, 2020 11:19:43 AM alainlamar (Alain Lamar)
<phabricator@mg.vyos.io>:

alainlamar added a comment.

Found the culprit.

I had a host named "io" in the same subnet which received its IP by

DHCP. DHCP was set to update the /etc/hosts:

set service dhcp-server hostfile-update

Resulting workaround:
1.) remove the entry for "io" from /etc/hosts
2.) delete service dhcp-server hostfile-update
3.) `set service dhcp-server shared-network-name WIFI subnet

192.168.XX.YY/24 domain-name mydomain.local`

4.) commit && save

However, this is not really an answer as I still miss the part why the

entry for a hostname "io" supersedes the TLD ".io"...

TASK DETAIL
https://phabricator.vyos.net/T2290

EMAIL PREFERENCES
https://phabricator.vyos.net/settings/panel/emailpreferences/

To: alainlamar
Cc: Active contributors, Maintainers, alainlamar, teadur,

jack9603301, hard, pa4ka, jestabro, Alfa80, dongjunbo, hexes, pasik

Hi @jjakob

thanks for explaining the backgrounds! I wonder if a removal of the hostfile-update option should be suggested.

With respect to the elaborated backgrounds, I'll consider my "workaround" a real fix and mark this ticket invalid.

Thanks again everybody for helping!
Al

erkin set Issue type to Bug (incorrect behavior).Aug 30 2021, 7:06 AM
erkin removed a subscriber: Active contributors.