# Cannot resolve *.freebsd.org but everything else



## kodcode (Jul 25, 2022)

Hello,

I am running `local_unbound` and I can not resolve any of `*.freebsd.org`. (all other domains resolved)

In my /etc/resolv.conf I have:

```
# nameserver 1.1.1.3
# nameserver 1.0.0.3

nameserver 127.0.0.1
options edns0
```

and in /var/unbound/forward.conf:

```
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
        name: .
        forward-addr: 1.1.1.3
        forward-addr: 1.0.0.3
```

The outcome of `drill @1.1.1.3 pkg.freebsd.org` is:

```
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 21742
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; pkg.freebsd.org.     IN      A

;; ANSWER SECTION:
pkg.freebsd.org.        300     IN      CNAME   pkgmir.geo.freebsd.org.
pkgmir.geo.freebsd.org. 150     IN      A       139.178.72.201

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 403 msec
;; SERVER: 1.1.1.3
;; WHEN: Mon Jul 25 15:28:30 2022
;; MSG SIZE  rcvd: 74
```

I also have a script /etc/dhclient-enter-hooks:

```
add_new_resolv_conf() {
                      return 0
}
```

Many thanks in advance.


----------



## VladiBG (Jul 25, 2022)

> Server:  gns1.freebsd.org
> Address:  96.47.72.24
> 
> Name:    pkgmir.geo.freebsd.org
> Address:  139.178.72.201


You get the right resolve of pkgmir.geo.freebsd.org so the DNS is working.  Do you have connection to it? Lets say by ping?


----------



## Alain De Vos (Jul 25, 2022)

```
ping -4 pkg.freebsd.org
```


----------



## kodcode (Jul 25, 2022)

`ping pkgmir.geo.freebsd.org` just stays idle. (Same for pkg.freebsd.org)


----------



## Alain De Vos (Jul 25, 2022)

Try ping -4


----------



## kodcode (Jul 25, 2022)

Alain De Vos said:


> Try ping -4




```
ping: cannot resolve pkg.freebsd.org: Host name lookup failure
```


----------



## Alain De Vos (Jul 25, 2022)

This is my forward.conf for local_unbound,

```
forward-zone:
    name: "."
    # Opendns
    forward-addr:  2620:119:35::35
    forward-addr:  2620:119:53::53
    #Cloudfare
    forward-addr:  2606:4700:4700::1111
    forward-addr:  2606:4700:4700::1001
    #
```


----------



## VladiBG (Jul 25, 2022)

what is the output of:
`netstat -an4 | grep 53`
`drill @127.0.0.1 pkg.freebsd.org.`


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> what is the output of:
> `netstat -an4 | grep 53`
> `drill @127.0.0.1 pkg.freebsd.org.`


`netstat -an4 | grep 53`:

```
tcp4       0      0 127.0.0.1.53           *.*                    LISTEN    
tcp4       0      0 192.168.8.101.25653    64.233.167.109.993     ESTABLISHED
udp4       0      0 192.168.8.101.61388    1.1.1.3.53            
udp4       0      0 127.0.0.1.53           *.*
```
`drill @127.0.0.1 pkg.freebsd.org`:

```
Error: error sending query: Could not send or receive, because of network error
```


----------



## VladiBG (Jul 25, 2022)

do you have firewall?


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> do you have firewall?


No, I haven't.


----------



## Alain De Vos (Jul 25, 2022)

The output of

```
netstat -r
```
In order to verify there is no routing problem.


----------



## VladiBG (Jul 25, 2022)

The above error means that you are not allow to connect at port 53 to your localhost 127.0.0.1. Usually because of firewall.


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> The above error means that you are not allow to connect at port 53 to your localhost 127.0.0.1. Usually because of firewall.


Why would that only affect *.freebsd.org domains? I can ping and browse any other domain I've tried.


----------



## kodcode (Jul 25, 2022)

Alain De Vos said:


> The output of
> 
> ```
> netstat -r
> ...




```
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.8.1        UGS         re0
localhost          link#2             UH          lo0
192.168.8.0/24     link#1             U           re0
192.168.8.101      link#1             UHS         lo0

Internet6:
Destination        Gateway            Flags     Netif Expire
::/96              localhost          UGRS        lo0
localhost          link#2             UHS         lo0
::ffff:0.0.0.0/96  localhost          UGRS        lo0
fe80::/10          localhost          UGRS        lo0
fe80::%lo0/64      link#2             U           lo0
fe80::1%lo0        link#2             UHS         lo0
ff02::/16          localhost          UGRS        lo0
```


----------



## VladiBG (Jul 25, 2022)

Try to query the localhost and check if unbound is working.

`service local_unbound restart
drill @127.0.0.1 localhost`
this should return localhost. 127.0.0.1

Also you can check if you can `ping 127.0.0.1` and connect using `telnet 127.0.0.1 53` If there's firewall if you are running this inside a jail you need to allow the lo0 interface


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> Try to query the localhost and check if unbound is working.
> 
> `service local_unbound restart
> drill @127.0.0.1 localhost`
> this should return localhost. 127.0.0.1


It does:

```
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 7381
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; localhost.   IN      A

;; ANSWER SECTION:
localhost.      10800   IN      A       127.0.0.1

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Jul 25 16:18:25 2022
;; MSG SIZE  rcvd: 43
```


----------



## SirDice (Jul 25, 2022)

Remove the `options edns0` from /etc/resolv.conf.


----------



## VladiBG (Jul 25, 2022)

Ok try again with `drill @127.0.0.1 pkg.freebsd.org.`


----------



## kodcode (Jul 25, 2022)

SirDice said:


> Remove the `options edns0` from /etc/resolv.conf.


Did not help.

And what VladiBG suggested, it just stays idle.


----------



## VladiBG (Jul 25, 2022)

Try to flush the cache of unbound unbound-control(8)

`local-unbound-control flush pkg.freebsd.org
local-unbound-control flush freebsd.org`

Then try to lookup the dns using
`local-unbound-control  lookup pkg.freebsd.org`


----------



## SirDice (Jul 25, 2022)

Also, run tcpdump(1) and see if there are DNS requests going out. Unbound has to be able to forward queries to external hosts. Maybe something isn't going out, or being blocked further upstream. If you can see requests going out but not getting any responses then you know you need to look further upstream for the issue.


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> Try to flush the cache of unbound unbound-control(8)
> 
> `local-unbound-control flush pkg.freebsd.org
> local-unbound-control flush freebsd.org`
> ...


Did the flushing first.
`local-unbound-control  lookup pkg.freebsd.org` returns:

```
The following name servers are used for lookup of pkg.freebsd.org.
forwarding request:
Delegation with 0 names, of which 0 can be examined to query further addresses.
It provides 2 IP addresses.
1.1.1.3                 rto 792 msec, ttl 894, ping 64 var 83 rtt 396, tA 0, tAAAA 0, tother 1, EDNS 0 probed.
1.0.0.3                 rto 540 msec, ttl 895, ping 6 var 66 rtt 270, tA 0, tAAAA 0, tother 1, EDNS 0 probed.
```


----------



## kodcode (Jul 25, 2022)

SirDice said:


> Also, run tcpdump(1) and see if there are DNS requests going out. Unbound has to be able to forward queries to external hosts. Maybe something isn't going out, or being blocked further upstream. If you can see requests going out but not getting any responses then you know you need to look further upstream for the issue.


I ran `drill @127.0.0.1 pkg.freebsd.org` while tcpdump was running.
This is the output. Any hint would be greatly appreciated.

```
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:03:30.174359 IP 192.168.8.101.47322 > 1.0.0.3.domain: 31443+% [1au] DNSKEY? freebsd.org. (40)
17:03:30.175372 IP 192.168.8.101.11850 > 1.0.0.3.domain: 56998+ [1au] PTR? 101.8.168.192.in-addr.arpa. (55)
17:03:30.228284 IP 1.0.0.3.domain > 192.168.8.101.11850: 56998 NXDomain 0/0/1 (55)
17:03:30.228805 IP 192.168.8.101.23114 > 1.0.0.3.domain: 55664+ [1au] PTR? 3.0.0.1.in-addr.arpa. (49)
17:03:30.265702 IP 1.0.0.3.domain > 192.168.8.101.23114: 55664 NXDomain 0/1/1 (114)
17:03:30.265871 IP 192.168.8.101.29475 > 1.0.0.3.domain: 43856+% [1au] DS? 0.1.in-addr.arpa. (45)
17:03:30.349091 IP 1.0.0.3.domain > 192.168.8.101.29475: 43856 0/4/1 (432)
17:03:30.349685 IP 192.168.8.101.43817 > 1.0.0.3.domain: 41389+% [1au] DS? 0.0.1.in-addr.arpa. (47)
17:03:30.794045 IP 1.0.0.3.domain > 192.168.8.101.43817: 41389 0/4/1 (437)
17:03:31.973389 IP 192.168.8.101.36702 > 1.0.0.3.domain: 60089+% [1au] DNSKEY? freebsd.org. (40)
17:03:32.777350 IP 192.168.8.101.50005 > 1.0.0.3.domain: 26612+% [1au] DNSKEY? freebsd.org. (40)
17:03:33.573409 IP 192.168.8.101.50416 > 1.0.0.3.domain: 25587+% [1au] DNSKEY? freebsd.org. (40)
17:03:35.152364 IP 192.168.8.101.61135 > 1.0.0.3.domain: 41219+% [1au] DNSKEY? freebsd.org. (40)
17:03:35.232985 ARP, Request who-has 192.168.8.101 tell 192.168.8.1, length 46
17:03:35.233025 ARP, Reply 192.168.8.101 is-at 3c:2c:30:d9:ee:bc (oui Unknown), length 28
17:03:35.233394 IP 192.168.8.101.41490 > 1.1.1.3.domain: 55963+ [1au] PTR? 1.8.168.192.in-addr.arpa. (53)
17:03:35.265778 IP 1.1.1.3.domain > 192.168.8.101.41490: 55963 NXDomain 0/0/1 (53)
17:03:36.741387 IP 192.168.8.101.9759 > 1.1.1.3.domain: 50876+% [1au] DNSKEY? freebsd.org. (40)
17:03:36.910427 IP 192.168.8.101.28269 > 1.1.1.3.domain: 36336+% [1au] DNSKEY? freebsd.org. (40)
17:03:37.090052 IP 192.168.8.101.4527 > 1.1.1.3.domain: 16880+% [1au] DNSKEY? freebsd.org. (40)
17:03:37.445351 IP 192.168.8.101.28670 > 1.1.1.3.domain: 24075+% [1au] DNSKEY? freebsd.org. (40)
17:03:37.790809 IP 192.168.8.101.47304 > 1.0.0.3.domain: 21006+% [1au] DNSKEY? freebsd.org. (40)
17:03:40.947354 IP 192.168.8.101.27634 > 1.0.0.3.domain: 1206+% [1au] DNSKEY? freebsd.org. (40)
17:03:44.133477 IP 192.168.8.101.38231 > 1.1.1.3.domain: 34340+% [1au] DNSKEY? freebsd.org. (40)
17:03:44.848491 IP 192.168.8.101.61678 > 1.1.1.3.domain: 53891+% [1au] DNSKEY? freebsd.org. (40)
17:03:45.563512 IP 192.168.8.101.22603 > 1.1.1.3.domain: 28053+% [1au] DNSKEY? freebsd.org. (40)
17:03:46.992507 IP 192.168.8.101.11557 > 1.1.1.3.domain: 23180+% [1au] DNSKEY? freebsd.org. (40)
17:03:48.421526 IP 192.168.8.101.46228 > 1.1.1.3.domain: 862+% [1au] DNSKEY? freebsd.org. (40)
17:03:51.179030 IP 192.168.8.101.51086 > 1.1.1.3.domain: 41168+% [1au] DNSKEY? freebsd.org. (40)
17:03:54.017557 IP 192.168.8.101.27975 > 1.1.1.3.domain: 7384+% [1au] DNSKEY? freebsd.org. (40)
```

Strangly enough, I can also not browse to www.freebsd.org in my browser.


----------



## Alain De Vos (Jul 25, 2022)

Does everything work without using local_unbound ?
Ie. put just a DNS 8.8.8.8 in resolv.conf

Can you post your,
control.conf
forward.conf
lan-zones.conf
unbound.conf
To see if there is something strange ?


----------



## kodcode (Jul 25, 2022)

Without `local_unbound` everything works. *With* `local_unbound` all domains I've tested work, *besides* *.freebsd.org


```
# cat /var/unbound/control.conf 
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
remote-control:
        control-enable: yes
        control-interface: /var/run/local_unbound.ctl
        control-use-cert: no

# cat /var/unbound/lan-zones.conf 
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
        # Unblock reverse lookups for LAN addresses
        unblock-lan-zones: yes
        insecure-lan-zones: yes

# cat /var/unbound/unbound.conf 
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf

# cat /var/unbound/forward.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
        name: .
        forward-addr: 1.1.1.3
        forward-addr: 1.0.0.3
```


----------



## SirDice (Jul 25, 2022)

kodcode said:


> This is the output.


Ok, we can see requests going out, and some requests getting an answer. But the DNSKEY request for freebsd.org gets forwarded but there's never any response.


----------



## VladiBG (Jul 25, 2022)

`local-unbound-anchor -c /var/unbound/unbound.conf`
`service local_unbound restart`







						DNS lookups times out and unbound trust anchors DNSKEY rrset is not secure
					

DNS hostname lookups timed out, and by looking at the logs, unbound was giving errors when restarting



					blog.stigok.com


----------



## kodcode (Jul 25, 2022)

VladiBG said:


> `local-unbound-anchor -c /var/unbound/unbound.conf`
> `service local_unbound restart`
> 
> 
> ...


I appreciate your help, but this did not solve my problem.


----------



## Alain De Vos (Jul 25, 2022)

Try as forward.conf:

```
forward-zone:
    name: "."
    forward-addr:  8.8.8.8
```


----------



## kodcode (Jul 25, 2022)

SirDice said:


> Ok, we can see requests going out, and some requests getting an answer. But the DNSKEY request for freebsd.org gets forwarded but there's never any response.


Is there anything concrete I should be looking further into?


----------



## eternal_noob (Jul 25, 2022)

I use a Raspberry Pi 400 without a hardware clock. I had troubles connecting to freebsd.org because time was incorrect. I had to run ntpd to be able to connect.


----------



## kodcode (Jul 25, 2022)

ntpd has been running.


----------



## SirDice (Jul 25, 2022)

Have you tried updating that root key?

```
auto-trust-anchor-file: /var/unbound/root.key
```


----------



## kodcode (Jul 25, 2022)

SirDice said:


> Have you tried updating that root key?
> 
> ```
> auto-trust-anchor-file: /var/unbound/root.key
> ```


I deleted /var/unbound/root.key and ran `local-unbound-anchor` and a new root.key got created. Did not help.


----------



## SirDice (Jul 25, 2022)

Is that file owned by the `unbound` user? Just remove that file and restart /etc/rc.d/local_unbound, if I read the script correctly it should create a new one if it's missing.


----------



## kodcode (Jul 25, 2022)

SirDice said:


> Is that file owned by the `unbound` user? Just remove that file and restart /etc/rc.d/local_unbound, if I read the script correctly it should create a new one if it's missing.


Yes, it's owned by the `unbound` user. I recreated it as suggested, but also this did not help :/


----------



## Alain De Vos (Jul 25, 2022)

Alain De Vos said:


> Try as forward.conf:
> 
> ```
> forward-zone:
> ...


----------



## kodcode (Jul 25, 2022)

I've tried that already once. Did not help.

Even though I did not understand how changing from Cloudflare to Google could solve this. (And if you are referring to the syntax of rather "." then . - I've tried that, too, even though those files are generated by unbound itself.)


----------



## chrbr (Jul 26, 2022)

Please check if you have anything as

```
local-zone: "www.eivamos.com" static
local-zone: "clk.cloudyisland.com" static
local-zone: "sdk.iappgame.com" static
...
```
in your *.conf files. Of course with the non working domains instead of the three examples below. This is a method to block DNS requests. May be the FreeBSD domain has been added by accident or for testing purpose. Good luck!


----------



## kodcode (Jul 26, 2022)

chrbr said:


> Please check if you have anything as
> 
> ```
> local-zone: "www.eivamos.com" static
> ...


I've checked that. Nothing like that there. I even deleted all of /var/unbound/* and let unbound recreate the config files. All this did not help.


----------



## VladiBG (Jul 26, 2022)

Is there DNS service on your router at 192.168.8.1?


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> Is there DNS service on your router at 192.168.8.1?


According to my knowledge, every router has a DNS service. /etc/resolv.conf points, if unbound is not running, to my router.

Please keep in mind, other domains resolve fine. Just not *.freebsd.org


----------



## VladiBG (Jul 26, 2022)

According your tcpdump you didn't get any response from 1.0.0.3 or 1.1.1.3
try `drill -TD @1.1.1.3 freebsd.org.`
and also `drill -TD @192.168.8.1 freebsd.org.`

did you get the dnskey record?


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> According your tcpdump you didn't get any response from 1.0.0.3 or 1.1.1.3
> try `drill -TD @1.1.1.3 freebsd.org.`
> and also `drill -TD @192.168.8.1 freebsd.org.`
> 
> did you get the dnskey record?


Both mentioned commands just idle after this message displayed: `;;Number of trusted keys: 1`


----------



## VladiBG (Jul 26, 2022)

i suspect that your UDP/53 is blocked on your router. Can you try with regular query over TCP
`drill -t @1.1.1.3 freebsd.org.`
`drill -t @1.1.1.3 google.com.`
`drill -t @192.168.8.1 freebsd.org.`


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> i suspect that your UDP/53 is blocked on your router. Can you try with regular query over TCP
> `drill -t @1.1.1.3 freebsd.org.`
> `drill -t @1.1.1.3 google.com.`
> `drill -t @192.168.8.1 freebsd.org.`


The first to commands resolved.
The third not. (idle)


----------



## VladiBG (Jul 26, 2022)

So you don't have DNS forwarder on your router at 192.168.8.1 and you get DNS response over TCP
just to double check try again with UDP query and if you don't get response then search the problem in your router/firewall at 192.168.8.1
`drill -u @1.1.1.3 google.com.`
This will ask the DNS 1.1.1.3 on UDP/53 and if your router is blocking the UDP/53 then it will timeout.

Edit:
another reason can be the Don't Fragment blocking on the firewall when the UDP packets are above the MTU size. More info here:





						DNS message fragments
					

This document describes a method to transmit DNS messages over       multiple UDP datagrams by fragmenting them at the application       layer. The objective is to allow authoriative servers to       successfully reply to DNS queries via UDP using multiple smaller       datagrams, where larger...



					www.ietf.org


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> So you don't have DNS forwarder on your router at 192.168.8.1 and you get DNS response over TCP
> just to double check try again with UDP query and if you don't get response then search the problem in your router/firewall at 192.168.8.1
> `drill -u @1.1.1.3 google.com.`
> This will ask the DNS 1.1.1.3 on UDP/53 and if your router is blocking the UDP/53 then it will timeout.
> ...


Your last mentioned command did resolve. 

What can I conclude from this? And does this explain the exceptional behaviour for *.freebsd.org?

Many thanks!


----------



## VladiBG (Jul 26, 2022)

Most likely your router is blocking your DNS responses which are bigger than 512 bytes and when you query DNSSEC you didn't get any DNS response from the server because those responses are a lot bigger.
You can try the same using the DNS server that your ISP is providing you and verify if you can get the DNSSEC chain using drill -TD @IPaddress_of_ISP_DNS google.com.

Example:


> versus@nginx:~ % drill -TD @1.1.1.3 freebsd.org.
> ;; Number of trusted keys: 1
> ;; Domain: .
> [T] . 172800 IN DNSKEY 256 3 8 ;{id = 20826 (zsk), size = 2048b}
> ...



What model is your router at 192.168.8.1? Is it some small SOHO router or it's dedicated PC?


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> Most likely your router is blocking your DNS responses which are bigger than 512 bytes and when you query DNSSEC you didn't get any DNS response from the server because those responses are a lot bigger.
> You can try the same using the DNS server that your ISP is providing you and verify if you can get the DNSSEC chain using drill -TD @IPaddress_of_ISP_DNS google.com.
> 
> Example:


Indeed, querying my ISP's DNS server with `drill -TD @ISP_DNS_IP google.com` did not resolve either.

I am still unclear why only *.freebsd.org did not resolve!?

PS Learning something new every day...


----------



## VladiBG (Jul 26, 2022)

Because it's trying to verify the DNS using DNSSEC to be sure that the data is not tampered with. The DNS is not secure and it can be easy spoofed and you can be redirected to unofficial (phishing) site. That's important to trust your DNS server as your security depends on it.





__





						DNSSEC – What Is It and Why Is It Important? - ICANN
					






					www.icann.org


----------



## kodcode (Jul 26, 2022)

VladiBG said:


> Because it's trying to verify the DNS using DNSSEC to be sure that the data is not tampered with. The DNS is not secure and it can be easy spoofed and you can be redirected to unofficial (phishing) site. That's important to trust your DNS server as your security depends on it.
> 
> 
> 
> ...


I am right to assume that turning off DNSSEC in `unbound` would be an option in my case, since DNSSEC is either way not supported by my router? (With or without `unbound` running I am at the same security level due to my router)


----------



## VladiBG (Jul 26, 2022)

It's better to test if the issue is in your router by connecting directly without it, or replace it with some different one.


----------



## tux2bsd (Jul 27, 2022)

It's far more likely to be a local problem on his FreeBSD machine, if he can do the look up without unbound it won't be the router.  If the FreeBSD machine is running pf (or other) allow UDP *and* TCP port 53.


----------

