Would this help?
Or this
DNSSEC is not needed for the ISP because the traffic is already secured by the ISP by embedded encryption hardware. That is why its not a valid option for that connection.
If you want to use DNSSEC web on a isp system like this, you use DNSSEC at the client computer and force the use of this dnssec server in the client computer.
As a side note
Do you have your IPfire behind a Verizon router?
ONT—Verizon router—IPfire.
I had lots of trouble with my Verizon router and port forwarding.
Removed it.
ONT—IPfire
No problem!
1 Like
Hopefully that is the case.
The ONT signs onto the network in a secure connection of its own, that is why the ISP DNS doesn’t use dnssec because that connection is already secured. Even if the ONT is bridged out so multiple outside ip addresses can be obtained, the link to the isp DNS is still secured. But regardless of DNS server type, they can log your requests even if you have a dnssec connection to them if they are doing that anyways.
I absolutely do not have anything between the ONT and IPfire_. I had the old Verizon G1100 and wanted to have my own hardware with at least a 2.5 gig wired backbone.
Can you check from console if DNSEC is working with
dig dns.cloudflare.com @8.8.8.8 +dnssec
; <<>> DiG 9.20.1 <<>> dns.cloudflare.com @8.8.8.8 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23603
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;dns.cloudflare.com. IN A;; ANSWER SECTION:
dns.cloudflare.com. 146 IN A 104.16.133.229
dns.cloudflare.com. 146 IN A 104.16.132.229
dns.cloudflare.com. 146 IN RRSIG A 13 3 300 20241114134837 20241112114837 34505 cloudflare.com. QvriTiByzjMQmCR88BskgLVH5RvowARNAZ0d8bA/MRoRzRZAOOkiW8/I v0wYfLQQcDvJEOMGFQZpXeHIE6MnLQ==;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Nov 13 13:51:11 CET 2024
;; MSG SIZE rcvd: 189
Response must be NOERROR and the Flag -ad must set and EDNS flag do
If this is ok try:
dig NSEC3 dns9.quad9.net +dnssec @8.8.8.8
; <<>> DiG 9.20.1 <<>> NSEC3 dns9.quad9.net +dnssec @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16682
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;dns9.quad9.net. IN NSEC3;; AUTHORITY SECTION:
quad9.net. 14 IN SOA admin1.sjc.rrdns.pch.net. hostmaster.pch.net. 3999410443 10800 3600 172800 600
quad9.net. 14 IN RRSIG SOA 8 2 1200 20241128130000 20241111130000 4309 quad9.net. XZlhSr1aaOON6RzTgSt6gkJj+Y/kLtO2gvfj/XoPsLtjjEFEU5NEyeyO KWLCKV3gLADAJD39zHJ8PfLNQT4fLUE6PRRgtJcVGH40SM4VvKjBjl81 yNBQMJ3tBp85wyXFWmBeKuBNYXbMs9BMCAYMGWR5evDeBTKCubeDt40e 2vV/Pl4Z2rEpOpvPtJbPBOAmzjr864ikO6t7UUsj7bUYXBxMZre+orKG vDRZzEHniFaLvhHhvg4GjrdGi4FsMG78FX+9IsHWw6uUHA0casfzOb0t rvU54kGrJrg27sTSlMdu6hDZYmZuPLvqcCGvTn+BytYaSVziYrkxTbRe rXukjg==
K93Q80FELM84KNHA8GMTHEQCOKROJVDU.quad9.net. 14 IN NSEC3 1 1 0 69B31FAC KGHQSSLCAD42G8QBS9PH0031BG0CAGMP A MX AAAA RRSIG
K93Q80FELM84KNHA8GMTHEQCOKROJVDU.quad9.net. 14 IN RRSIG NSEC3 8 3 600 20241128130000 20241111130000 4309 quad9.net. vX7ap6BerChO5f6f+m2wUUkBfFAxEJ4KM8rc0uCj4vIG7RNT7UeWYHui BMCu6Ha+YN+c0KXvXm4aE5MzIN6mvk6PZm6aX4ggi/RPGuUC0cQ+iam3 zjx3Xy8hjaos6gQaOlr2dPPxnu3bp1dNTUG6GVClFh3t59T/JYHf93V7 mVwFEdw95In9cKPetFfT7su0ye1HpO1eDmfjQNUaI/G4Nj2JTzUGCoaJ Tq76uhMQNDXAn66JWqcf0CPktT5jmIfziG9JeZKfmwB74Pfl4hkjN2Hl 9ni5aBRHdQ1En/DoZ2WFSyBPZ/08ywgIrjhDBYR+7s9gqGYw6g3M3YoD U09Lhg==;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Nov 13 14:04:42 CET 2024
;; MSG SIZE rcvd: 788
no -ad flag in answer but flag -do shows that a DNSSEC request was made. Here I get the Info (NSEC3) which is in your log missing. info:
if you make a request without DNSSEC
dig NSEC3 dns9.quad9.net @8.8.8.8
; <<>> DiG 9.20.1 <<>> NSEC3 dns9.quad9.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3045
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dns9.quad9.net. IN NSEC3;; AUTHORITY SECTION:
quad9.net. 600 IN SOA admin1.sjc.rrdns.pch.net. hostmaster.pch.net. 3999410443 10800 3600 172800 600;; Query time: 47 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Nov 13 14:08:54 CET 2024
;; MSG SIZE rcvd: 111
you should get the same answer.
Now the magic, ask ipfire (with 9.9.9.9 as DNS Provider) at 192.168.1.1
dig dns.cloudflare.com +dnssec @192.168.1.1
; <<>> DiG 9.20.1 <<>> dns.cloudflare.com +dnssec @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44122
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;dns.cloudflare.com. IN A;; ANSWER SECTION:
dns.cloudflare.com. 290 IN A 104.16.133.229
dns.cloudflare.com. 290 IN A 104.16.132.229
dns.cloudflare.com. 290 IN RRSIG A 13 3 300 20241114142834 20241112122834 34505 cloudflare.com. o/VAI1Rmd+DIW+lNyK8cZMfW6qX8SEZdqoAgB8E8qsmEQhUOBM/xZhZ+ 2/8IhaSZ44osZpJbvdMleuJ8qYpSnw==;; Query time: 84 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Nov 13 14:28:44 CET 2024
;; MSG SIZE rcvd: 189
you should have a full DNSSEC query, even for your local domains
dig home.localdomain +dnssec @192.168.1.1
; <<>> DiG 9.20.1 <<>> home.localdomain +dnssec @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16534
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;home.localdomain. IN A;; ANSWER SECTION:
home.localdomain. 60 IN A 192.168.1.13;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Nov 13 14:35:12 CET 2024
;; MSG SIZE rcvd: 72
if not you can test it now for any DNS provider.
Your ISP may be running a transparent DNS proxy, but that’s rather unlikely.
If I’m wrong, please correct me, but that would be my troubleshooting suggestion.
1 Like
These all worked as you stated above. I’m marking Bernhard as the solution. This issue is because my ONT is losing connection randomly. I put the cart before the horse thinking this was an IPFire_ issue, when I now think it’s a hardware problem with Verizon.
I appreciate all your help on this!
|21:19:21|dhcpcd[1932]|: red0: adding default route via 173.50.100.1|
|---|---|---|
|21:19:21|dhcpcd[1932]|: red0: adding route to 173.50.100.0/24|
|21:19:21|dhcpcd[1932]|: red0: leased 173.50.100.230 for 7200 seconds|
|21:19:16|dhcpcd[1932]|: red0: probing address 173.50.100.230/24|
|21:19:16|dhcpcd[1932]|: red0: rebinding lease of 173.50.100.230|
|21:19:14|dhcpcd[1932]|: red0: IAID 1e:d2:de:4a|
|21:19:14|dhcpcd[1932]|: red0: carrier acquired|
|21:19:11|dhcpcd[1932]|: red0: carrier lost|
|21:19:10|dhcpcd[1932]|: red0: IAID 1e:d2:de:4a|
|21:19:10|dhcpcd[1932]|: red0: carrier acquired|
|21:19:03|dhcpcd[1932]|: red0: deleting default route via 173.50.100.1|
|21:19:03|dhcpcd[1932]|: red0: deleting route to 173.50.100.0/24|
|21:19:03|dhcpcd[1932]|: red0: carrier lost|
|21:17:35|dhcpcd[1932]|: red0: adding default route via 173.50.100.1|
|21:17:35|dhcpcd[1932]|: red0: adding route to 173.50.100.0/24|
|21:17:35|dhcpcd[1932]|: red0: leased 173.50.100.230 for 7200 seconds|
|21:17:30|dhcpcd[1932]|: red0: probing address 173.50.100.230/24|
|21:17:30|dhcpcd[1932]|: red0: rebinding lease of 173.50.100.230|
|21:17:29|dhcpcd[1932]|: red0: IAID 1e:d2:de:4a|
|21:17:29|dhcpcd[1932]|: red0: carrier acquired|
|21:17:25|dhcpcd[1932]|: red0: carrier lost|
|21:17:23|dhcpcd[1932]|: red0: probing address 173.50.100.230/24|
|21:17:23|dhcpcd[1932]|: red0: rebinding lease of 173.50.100.230|
|21:17:22|dhcpcd[1932]|: red0: IAID 1e:d2:de:4a|
|21:17:22|dhcpcd[1932]|: red0: carrier acquired|
|21:17:19|dhcpcd[1932]|: red0: carrier lost|
|21:17:19|dhcpcd[1932]|: red0: rebinding lease of 173.50.100.230|
|21:17:18|dhcpcd[1932]|: red0: IAID 1e:d2:de:4a|
|21:17:18|dhcpcd[1932]|: red0: carrier acquired|
|21:17:15|dhcpcd[1932]|: red0: deleting default route via 173.50.100.1|
|21:17:15|dhcpcd[1932]|: red0: deleting route to 173.50.100.0/24|
|21:17:15|dhcpcd[1932]|: red0: carrier lost|
2 Likes
It does look like cabling or a hardware issue, but if the L2 ONT is the account control (yes in this case because you are not signing in like a pppoe) You might have to use the isp dns to have a stable connection.
also I really don’t understand why the static over DNSSEC because its not necessary and if it was, the isp would be running it.
These issues are happening with or without using the ISP DNS. I reenabled ISP DNS as you suggested and still had the carrier signal loss I posted.
There is also another layer to dns setting. You need to change “Protocol for DNS queries” to UDP or TCP and you might have to use TCP if they didn’t update their DNS server to accept UDP which they should have by now.
This doesn’t explain the ‘carrier lost’ messages.
2 Likes
There are only a few things that causes the “carrier lost” error. They are:
- bad network cable
- ip address conflict
- not responding to a specific dns server
#1 and #3 are the most common and sometimes the dns server is not the same one that dhcp advertises. So I would look in the old router to see if there is a dns server setting manually set. Also, it may or may not be plain dhcp either, so I would check to see if all of the settings in the old router is the same WAN settings used in ipfire.
DNS was not manually set on my old router (Verizon G1100). The DNS was obtained automatically. A bad cable is always possible. I’m trying to get Verizon to access the ONT logs to validate my carrier loss from last night. It’s like talking to a toddler. And unfortunately they are no help. But I will look into cabling being the issue. I have an ethernet coupler / extender I’m using that I wasn’t before when I moved the router from the garage to the office.
1 Like
It is quite likely that then. When the RED NIC detects a lost link it is literally that cable that is plugged in and whatever is on the other side. It is not further down the line as in a cable/fibre modem. It’s the Ethernet link on the way.
Regarding DNSSEC: it is very bad style from VZ to block anything. It is simply their surveillance machine that they are trying to feed with data. However I understand that very often there is not a (very good) choice between ISPs.
I would strongly recommend against disabling DNSSEC.
If you must you can try using the DNS Forwarding feature and forward the Root zone to the VZ DNS servers and there is a checkbox to disable DNSSEC. But you would be on you own then…
2 Likes
My original Verizon ONT failed and was replaced.
The Verizon support tech had me open up the utility box to look at the ONT and it was, of course, all green. If it’s the ONT, the only way I’m going to catch it is to run outside when RED goes down again if I’m around and take a photo of it.
At this point, I have a new ethernet coupler on order and I should get it tomorrow. I’m hoping that’s the issue. It’s entirely possible because that’s really the difference between what’s changed recently since I replaced the Verizon G1100 I had in the garage before. Otherwise, if that’s not it and it’s not the ONT, I’m going to have to rewire my CAT-5 from the garage to the office. That’s not going to be fun. It’s quality plenum cable that’s been good for ~10 years, so I’m skeptical that just took a dump all of a sudden. I was planning on putting the Fluke meter on it when I can get a chance this weekend just to make sure the connection is still solid.
1 Like
Having speed issues at my home.
Just ordered some cat6. Cat5e not cutting it I guess.
That doesn’t make sense unless it is a distance issue and you’re trying to do something like 10 gig. I’ve got regular Cat5 plenum that I bought over 20 years ago in a 1000 ft box and I have no problems with 2.5 gigabits over the relatively short distances in a house. The garage to the office is my longest run and that’s at most 60 feet because I’m going through the attic. If your terminations are good, and you’re at less than 150 ft, Cat5e should be fine for 2.5 gig. I’d even bet you could get 10 gig at short distances with it – for sure like 50 feet or less.
I think its because you don’t understand the ONT has established an encrypted connection, so its not going to establish a new DNSSEC inside another to the same DNS server. When I program a SPF module to replace an ONT in a system, I have to flash certain software inside them so they can sign on. That is the reason why I can tell you it makes no difference because that link is already DNSSEC by PPPOe Pond sign on.
As long as its 250-350 Mhz cable. Which cat5e should be.
Plenum cable is ok to run in a attic provided its in a conduit. This I believe is actually an electrical code. CMX rated cable is the only real hostile environment cable as its the only flameproof type available. But plain plenum cable can de-rate but the common failures I’ve seen is sharp kinks in the wire or runs that have cable staples in them. There are only a few types of couplings that are decent enough to use. But the one thing to avoid is CCA (copper clad aluminum) wire sold now these days as it is not up to standards.
I would have to look cat5e used for 2.5G limitations. I think its 50 feet But if you have to run new cable, I would suggest cat8 so you would never have an issue with wire and speed.