DNS problem when NS is used a domain controller

Yup. I did. Since my reverse proxy is 192.168.2.1 that’s one of the things I used.

…oh… and by the way, I would be happy to segregate my traffic internal and external as it was before using NS. Unfortunately, that’s the reason why I’m asking for assistance.

Hi @iampellegrino

Both NethServer and PFsense have more or less capable DNS servers built-in, at least for internal DNS usage.

Note:
I’m an OPNsense user, a fork of PFsense with much the same modules and capabilities. Just the GUI is much better on OPNsense. And the available source code actually compilie, not quite so for PFsense… :slight_smile:

The idea behind having internal / external DNS servers is simple:

Your internal DNS server should be able to resolve everything concerning your domain and network. That means: every PC, notebook, smartphone and also printers and other hardware with IP. And where possible, internal IPs. Where not possible, eg an externally hosted website, use the external IP.

External DNS should NOT know these devices, it’s also a security concern…

Your external DNS Hoster, Godaddy, only needs to know and serve out IPs relevant for the Internet.

The only caveat is: you need to enter every external host at least twice…
Then again, how often do these entries change?
Do you change your external hoster every week? Not really!

→ This concept is known as Split-Brain DNS…
Basically, it can be seen as a “need to know” basis for internal and external hosts…

I’d suggest using the NethServer as primary, and the PFsense as secondary internal DNS server.
These can be entered in your DHCP Server (PFsense), for distribution to your internal clients.

This way you can point internal hosts right to the correct internal IP of whatever container you’re trying to reach, bypassing the firewall completly.
External traffic will pass through the firewall as always…

Important: Do create at least an entry for the NethServer itself, but also one for your AD.
And for the AD, do add in a wildcard (like *.ad.domain.tld)…

→ All AD clients get all information needed for correct AD working - and AD IS dependent on DNS, eg for clients to find the AD Master…

Hope this helps!

My 2 cents
Andy

2 Likes

Thank you for the explanation Andy!

Agree!!! That’s exactly what I’m trying to re-achieve! :smile: t, since that migration to NS, if I use DNS resolver and map an IP to a domain name i.e. 192.168.2.25=machine1.mydomain.com it just doesn’t work. Same for haproxy. Works if I route via internet but again, only for machines on the LAN that are not joined to the domain. Any idea why?

that’s my actual config.

I just read about split-brain DSN. Very interesting but I actually don need this if I could resolve my servers internally.

Let me rephrase my question differently now that I know more. Where in NS can I configure that host1 is reacheable via host1.mydomain.com. I tried that DSN gui. not working.

Please elaborate on the above…


HAProxy? It’s OK, but nginx or even apache on NethServer may be a better choice…

So far, I’ve mainly used the NethServer for LetsEncrypt, even though the OPNsense could do that just as well.

The main reason for me is AD. A lot of Apps, especially Java and PHP programmed stuff require a valid SSL cert on the AD, if you want to use AD authentification. MeshCentral & Guacamole are two examples on the OpenSource/NethServer side which require a valid SSL cert for AD to work. EcoDMS, a commercial Java programmed software in common use in German speaking countries is another good example…

If using LetsEncrypt on NethServer, and NethServer is your AD, this is easily achieved.
You need to enter your AD (both name versions!) in your external DNS and - like your NethServer - point them to your firewalls external IP.

nano /etc/e-smith/events/certificate-update/S80push2ad

Contents:

cp -f -p /etc/pki/tls/certs/localhost.crt  /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
cp -f -p /etc/pki/tls/private/localhost.key  /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
systemctl -M nsdc restart samba

This will automatically copy the new certs to the NDSC container in NethServer, enabling your AD with a valid SSL cert.


Here’s a more complex problem, probably along the lines of what you’re trying to achieve later on with your containers…

At home, I have a PI-Hole.
It’s real hostname is:

awr7-pi-hole.r7.anwi.ch

and has the internal IP 192.168.31.29, which is distributed to the DHCP clients from my DHCP server, my OPNsense firewall.

This PI-Hole only uses http, no https.

But if you like, try this:

https://pi-hole.r7.anwi.ch

My PI-Hole will be displayed correctly, with a correct SSL cert, even though I’m behind a dynamic IP address… What gives? :slight_smile:

Behind the scenes:

At home, in my LAN, my NethServer handles all LetsEncrypt SSL certs. It has the name “pi-hole.r7.anwi.ch” entered in as alias for the PI-Hole.

Note: This is NOT the real hostname of the PI-Hole!

Internally, pi-hole.r7.anwi.ch also points to the NethServer, as the external DNS. The external DNS can’t really resolve the real hostname of my PI-Hole.

The NethServer acts as reverse Proxy, and adding in SSL protection at the same time. Externally, it “removes” the SSL layer before forwarding the traffic to my PI-Hole. The PI-Hole sees no SSL traffic and answers in normal http, which the reverse proxy attaches https encapsulation…

This gives me the best of both worlds.

Clean SSL protection and same access internally and externally, but also a seperate access via internal IP or real hostname if I need to eg update the PI-Hole or it’s OS.

Hope this is all somewhat understandable… :slight_smile:

My 2 cents
Andy

DNS entries on NethServer?

Best here:

The DNS on NethServer can’t correctly handle CNAMEs, the only exceptions are CNAMEs pointing to NethServer itself. These can be entered in the first page of cockpit, see “aliases”…

:slight_smile:

My 2 cents
Andy

How do you point it internally? Do you mean adding a DNS record in NS via the GUI?

Reverse Proxy entry:

Real DNS entry:

Alias on Dashboard page:

I see all your DNS entries. That’s exactly what doesn’t work in my NS implementation (I also use a VM for NS).

Regardless if I add a DNS entry with server/ip combination, it doesn’t work. None of my clients can resolve the names afterward.

please see the pic as a confirmation:

You can see the IP, is an active IIS,
the URL can’t be resolved despite being entered in DNS records and that machine being joined to the network.

That’s exactly what I’m trying to understand… why it isn’t working!

Same result if I change the IP to the IP of my reverse proxy. Can’t resolve any entry in the DNS field.

Hi @iampellegrino

Sorry, I think I fell asleep…

Opening a Browser is not a way to test DNS.

Using a console (DOS-Shell) and nslookup would be correct.
After all, it could be a browser plug-in issue…

nslookup dns-name ip_of_dns_server_to_check

My 2 cents
Andy

1 Like

Please post the results of ping machine.example.com and nslookup machine.example.com of a domain machine and a non-domain machine to see what’s not working and which DNS server is used.

Did you try different browsers and flush DNS cache on clients?

ipconfig /flushdns

1 Like

@mrmarkuz @mrmarkuz…as discussed,

NB: sorry had to remove all dots (.) in the domain names as per your forums’ policy

my client DNS config:

result of ipconfig /all =
DNS Servers . . . . . . . . . . . : 192.168.2.9
192.168.2.1
info: 1st server = NS (…2.9), 2nd = pfsense (…2.1)


step 1: FLUSHED DSN
ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.


NSLOOKUPS

  1. (from the main DNS/NS)
    nslookup science dot ibiopro dot com 192.168.2.9
    Server: UnKnown
    Address: 192.168.2.9

RESPONSE: *** UnKnown can’t find science dot ibiopro dot com: Non-existent domain

  1. (from pfsense)
    nslookup science dot ibiopro dotcom 192.168.2.1
    Server: gateway dot ibopro dot com
    Address: 192.168.2.1

RESPONSE: *** gateway dot ibspro dot com can’t find science dot ibiopro dot com: Non-existent domain

Y:>ping 192.168.2.54

Pinging 192.168.2.54 with 32 bytes of data:
Reply from 192.168.2.54: bytes=32 time=5ms TTL=128
Reply from 192.168.2.54: bytes=32 time=4ms TTL=128
Reply from 192.168.2.54: bytes=32 time=4ms TTL=128
Reply from 192.168.2.54: bytes=32 time=5ms TTL=128

Ping statistics for 192.168.2.54:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 5ms, Average = 4ms


just wondering if were using lets encrypt would we just change

/etc/pki/tls/certs/ to /etc/letsencrypt/live/yournethserver.com/

Did you already try to change this to 192.168.2.1 to use your pfsense DNS?

I assume this is from the domain-joined client. On the not-joined clients the pfsense DNS resolves correctly?

Please test with name instead of IP like ping science.ibiopro... to see what IP ping gives back.

When you choose a default certificate, it is copied to /etc/pki/tls/certs/localhost.crt, so the script copies letsencrypt certs too.

1 Like

Exactly

using name =
Y:>ping science.ibiopro.com
Ping request could not find host science.ibiopro.com. Please check the name and try again.

The problem is the same from PFSENSE" = * Host “science.ibiopro dot com” did not respond or could not be resolved.

That’s why I felt there is a problem with the DNS portion of my NS server. It doesn’t perform name resolution.

Are you sure because dig or nslookup don’t give back an IP:

# dig science.ibiopro.com
;; flags: qr rd ra; QUERY: 1, ANSWER: 0

# nslookup science.ibiopro.com
** server can't find science.ibiopro.com: NXDOMAIN

1 Like

out of curiosity could it be something simple like port 53 being blocked

No, the DNS entries are simply non-existant, as a check with Google or Whois will show:

nslookup -query=any science.ibiopro.com 8.8.8.8
nslookup -query=any ibiopro.com 8.8.8.8

The Subdomain does not exist, the domain does…

Not really an issue with NethServer, but handling DNS at a Registrar… :slight_smile:

so godaddy