AAAA records with IPv4 only ISP

JonathanLee · Jul 5, 2023, 9:54 PM

Hello fellow Netgate community members,

I have found that, "AAAA records are only used when a domain has an IPv6 address" (cloud flare).

So if WAN is set to IPv6 none because of ISP restrictions should the unbound DNS still had out AAAA records? The client should not be able to access IPv6 urls right because of no IPv6 wan address? I am just curious as before the unbound resolver didn't have issues with the clients URL requests, and all the sudden they are attempting to connect to IPV6 even if my ISP does not hand out a IPV6 address. It is set to none. Again if the host asks for a AAAA it's going to hand it out. My question is if the WAN already has it set to none why allow it.

Any thoughts?

mcury · Jul 5, 2023, 9:58 PM

@JonathanLee After reading all the topics about it here in the forum, and checking the unbound manual here:
https://manpages.debian.org/testing/unbound/unbound.conf.5.en.html

I ended up with:

server:
do-ip6: no
private-address: ::/0

It is working fine.

JonathanLee · Jul 5, 2023, 10:16 PM

@mcury what about clients that want DoH can unbound also handle those? That packet should look the same except the DoH server request that is sent out.

mcury · Jul 5, 2023, 10:20 PM

@JonathanLee said in AAAA records with IPv4 only ISP:

what about clients that want DoH can unbound also handle those?

I think so, I don't see a reason why it wouldn't.

But as I see it, DOH is not the best option..

If you set up a packet capture and check the Hello Packets, you will see a header called SNI (Server name indication), in which it is possible to see where you are connecting to.

So, if the provider wants to know where you are going, DOH won't stop them.

You won't be able to cache DNS too, so I would suggest to use the root servers and that is it.

JonathanLee · Jul 5, 2023, 10:48 PM

@mcury

https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-https.html

mcury · Jul 5, 2023, 11:11 PM

@JonathanLee said in AAAA records with IPv4 only ISP:

https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-https.html

Yes, it is nice that they want to increase the ratio of encrypted DNS traffic.
I went that route for a while and then I thought, why ?

When using the root servers:
I'm not sending my DNS data to my ISPs.
I'm not sending my DNS data to Google or other big company out there.
I'm able to use DNSSEC.
Edit Unbound will cache DNS.

When using DOH:
I'm not sending my DNS data to my ISP.
I'm sending my DNS data to someone other than me, and not to root servers.
Edit: I'm not sure if DOH is compatible with DNSSEC, I don't think so.. I know that DOT is.
Edit Unbound won't cache DNS since forward will be enabled.

And there is a possibility that the DOH server stops responding, go down and etc.

Either way, I prefer to send them directly to root servers.
Anyone in the path would be able to sniff it anyway just the way I showed above, through SNI header.
So, one more layer of complexity and prone to problems, for little or zero gain.

mcury · Jul 6, 2023, 5:48 AM

I don't think DOH and DNSSEC make sense together.. Someone correct me if I'm wrong about this.

johnpoz · Jul 5, 2023, 11:16 PM

@mcury said in AAAA records with IPv4 only ISP:

Edit Unbound will cache DNS.

unbound caches dns no matter if resolving or forwarding. With resolving you always get the full ttl, when you forward you get back whatever where you forward too had left on its cache. the only time you would really get the full ttl is if where you forward had to resolve what you asked for.

I'm not sure if DOH is compatible with DNSSEC

when you forward, if where you forward is doing dnssec you get dnssec, if they are not - then nope. Most all the major players you forward to would be doing dnssec, unless you forward to one of their special IPs that don't do it.

I prefer to send them directly to root servers.

Same here, I will resolve thank you very much, I have no desire to send all my dns to some service that says they have my best interest at heart. I find this is rarely the case ;)

mcury · Jul 6, 2023, 1:24 AM

Ow, I was about to ping you, I thought, I know someone that will help to clarify everything :)

@johnpoz said in AAAA records with IPv4 only ISP:

unbound caches dns no matter if resolving or forwarding. With resolving you always get the full ttl, when you forward you get back whatever where you forward too had left on its cache. the only time you would really get the full ttl is if where you forward had to resolve what you asked for.

Nice, I wasn't aware of that, noted.

@johnpoz said in AAAA records with IPv4 only ISP:

when you forward, if where you forward is doing dnssec you get dnssec, if they are not - then nope. Most all the major players you forward to would be doing dnssec, unless you forward to one of their special IPs that don't do it.

Ok, one more thing to my notes here

@johnpoz said in AAAA records with IPv4 only ISP:

Same here, I will resolve thank you very much, I have no desire to send all my dns to some service that says they have my best interest at heart. I find this is rarely the case ;)

Sometimes we just need to face DNS problems to ask , why I'm doing it like this.. :)

johnpoz · Jul 6, 2023, 1:33 AM

@mcury said in AAAA records with IPv4 only ISP:

Ok, one more thing to my notes here

So as example

dnssec fails to 9.9.9.9

$ dig www.dnssec-failed.org @9.9.9.9

; <<>> DiG 9.16.42 <<>> www.dnssec-failed.org @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45436
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 325 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jul 05 20:21:50 Central Daylight Time 2023
;; MSG SIZE  rcvd: 56

But if you ask their IP that doesn't do dnssec.

$ dig www.dnssec-failed.org @9.9.9.10

; <<>> DiG 9.16.42 <<>> www.dnssec-failed.org @9.9.9.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50356
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN      A       68.87.109.242
www.dnssec-failed.org.  7200    IN      A       69.252.193.191

;; Query time: 42 msec
;; SERVER: 9.9.9.10#53(9.9.9.10)
;; WHEN: Wed Jul 05 20:24:08 Central Daylight Time 2023
;; MSG SIZE  rcvd: 88

cloudflare provides a bit of info in their response with ede

$ dig www.dnssec-failed.org @1.1.1.1

; <<>> DiG 9.16.42 <<>> www.dnssec-failed.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30139
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 113 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jul 05 20:25:27 Central Daylight Time 2023
;; MSG SIZE  rcvd: 107

JonathanLee · Jul 6, 2023, 6:18 AM

@mcury DoH and DoT accomplish the same thing right? Just use of TLS. DoH uses port 443 DoT use 853. My question is if I want to let unbound do both can I? I want to configure DoH just to learn how to. You said you have set up DoH before, do I just add in the loop back or other items for this? It said it needs libnghttp2 library is that already installed in PfSense? My goal here is to take my huge squidguard DoH list and redirect it over to the unbound resolver when it hits them and DoH on the firewall it should work right? I have a proxy running, all other traffic not resolving to DoH servers just pass normally. I should see both DoH and 853 DNS info on the Squid proxy and keep doing inspection of bad guy traffic that way.

mcury · Jul 6, 2023, 2:23 PM

@johnpoz Thanks Johnpoz, everything is more clear to me now..

@JonathanLee When I was using DOH, it was directly through the OS and not through pfsense. I was using Clouflare for that purpose. I never used in pfSense.

@JonathanLee said in AAAA records with IPv4 only ISP:

DoH and DoT accomplish the same thing right?

Yes, both will encrypt your DNS.
DOT is easy to block, you can just block TCP port 853 outbound and that is it.
DOH is a problem for network administrators, I'm now disabling it through GPO, it is an easier way to disable it, I don't need huge DOH lists, just configure the GPO for Edge/Chrome/Firefox and deploy it.
With DOT and DOH disabled, I can user pfblockerNG to block things I want.

@JonathanLee said in AAAA records with IPv4 only ISP:

My question is if I want to let unbound do both can I? I

When speaking about Squid, you should use the same DNS as Squid, in your system.
As far as I remember, if you didn't, you would see an error about http/https, so many years that I don't use Squid but I remember about this problem. I can't tell if that has been fixed. So no, I wouldn't use both.
I'm also blocking UDP/80/443 outbound, QUIC can be a problem, you can do it by GPO or just block these ports.

The configuration that worked for me when I used Squid was, pfSense uses Unbound (Use local DNS, 127.0.0.1, and my users would point to Unbound in pfSense as their DNS server. Then, you can configure DOT outbound in pfSense for the server of your choice.

Not sure if I answered everything, let me know.

JonathanLee · Jul 6, 2023, 3:23 PM

@mcury this is exactly how mine is configured currently.

Quick confirmation, if my ISP does not hand out IPv6 I have no access to any AAAA based records, meaning I can query them but not browse them with a host.

My goal is to have clamav work better as well as have the url filter get more visibility, I do block DoH my own list and a blacklist of blocks.

mcury · Jul 6, 2023, 2:48 PM

@JonathanLee said in AAAA records with IPv4 only ISP:

this is exactly how mine is configured currently. Quick confirmation, if my ISP does not hand out IPv6 I have no access to any AAAA based records, meaning I can query them but not browse them with a host.

I don't think I'm the right user to answer you that. my understanding about IPv6 is not good.

This is my understanding about it, which could be wrong, once again someone correct me if there is something wrong here:

Things get a little more complicated when you have a multiWAN environment, you would need to use NPt that is currently not compatible with DHCP6-PD, and here where I live, this is the "normal".

Now, imagine this multiWAN environment, in which you have two gateway groups, one for IPv4 and another one for IPv6, how would that work.. Would it be reliable ?
Just to think about that makes me don't want to use it.

Also, a lot of ISPs out there would give you a /64, so, if you have a bunch of VLANs, only one of those would be able to use the Track interface feature.

I don't like the idea of my servers using IPv6 either, I like to see and identify quickly what is happening, who is connecting and etc..

I've been disabling it for years and not a single issue so far.

Now that this is out of the way, if you only receive IPv4 address, you won't be able to connect to IPv6 addresses, thus ignoring AAAA wouldn't be a concern, unless you use a tunnel broker or something like it.

This is my personal opinion about IPv6, could be wrong since I'm far from being an expert about this subject. So I would say, just disable it.
Feel free to correct me if I'm wrong about something here.

mcury · Jul 6, 2023, 3:52 PM

@JonathanLee said in AAAA records with IPv4 only ISP:

My goal is to have clamav work better as well as have the url filter get more visibility, I do block DoH my own list and a blacklist of blocks.

I don't use Squid/Squidguard since a long time.
So, what I'm going to say may no longer apply.

Clamav, to be useful, needs to check the payload of the packet.

Nowadays everything is HTTPS, this means that you would need to import custom certificates to all users.

So now, you broke HTTPS and that will definitely cause a lot of problems.

When I was using Squid/Squidguard, I opted by using the Splice all method, which only checks the SNI header and decisions are taken based on it, block or not. This is much less problematic.. But Clamav is useless now (it will only be able to check HTTP packets).
Splice all doesn't require the user to import certificates.

Note that a proxy, by nature, will mess with the packet headers, so this method is also problematic.
Even more problematic when speaking about government sites, financial sites, whatsapp, windows update and etc.

Based on my comments above, even using splice all, you would need a bypass list.

If you opt by using transparent proxy, this bypass list would have to have IP ranges and networks, which changes all the time, so a lot of maintenance and work for the IT team.
Devices such as dongles (chromecast and etc), mobile phones, would be in trouble almost instantly.

If you opt by using explicit proxy (the end user knows about the proxy), you would also need a bypass list.
But this list can have domains, regex, and etc, much easier to maintain and less likely to cause problems.
This method is also far from perfect, new domains, new apps, new redirects and everything else that you might need to tweak this bypass list again.

By doing like this, the client will send to the proxy everything that is not in the bypass list.
Destinations that are in the bypass list, the client will connect directly to the destination, thus not breaking the HTTPS.

So, either way, lots of maintenance and tweaking, forever because the Internet is not static.

I would say that an antivirus solution installed at the client side is a much better solution.

And, If you really need to block things, check if you can do it by using DNS using the method I mentioned above, disabling DOT/DOH/QUIC and etc.

This is my experience with using proxy for a long time, and I can say one thing for sure, people will call you everyday because something is "not working".