[SOLVED-DNS] No longer able to update a VM with 2.4.0 beta
-
Enter an option: 13
Updating repositories metadata…
Updating pfSense-core repository catalogue...
pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSen
se-core.sqlite) failed: No such file or directory
pkg: hxxps://beta.pfsense.org/packages/pfSense_master_amd64-pfSense_devel/meta.t
xz: No address record
repository pfSense has no meta file, using default settings
pkg: hxxps://beta.pfsense.org/packages/pfSense_master-amd64-pfSense_devel/packag
esite.txz: No address record
Unable to update repository pfSense
Error updating repositories!I had been updating every couple weeks just fine.
-
Weird. I had had an Allow rule in my baremetal production pfSense 2.3.4 box to allow 53/udp DNS queries from the 2.4.0 beta VM to the outside world, and it worked fine for weeks, but I noticed 53/tcp DNS traffic coming from the VM.
After modifying the rule to allow tcp/udp DNS traffic from the VM, everything is back to normal. I wasn't expecting tcp DNS traffic all of a sudden. Why the change?
-
DNS is always UDP and TCP. Never only UDP. It's been that way for decades but still the "UDP Only" myth persists. Large queries/responses get sent over TCP instead of UDP. In the past that was over 512B queries but IIRC now it's 4096.
DNSSEC is one common way that you'll end up with larger queries and responses, but it's not exclusively DNSSEC using it. Even queries for sites like Google that contain many address records will go over the limit.
-
I'm well aware that DNS is both udp and tcp 53. That wasn't what I was asking. I've never heard of this "udp only" myth, honestly. It's always used both protocols. Usually tcp zone transfers and larger queries/responses.
I was asking why I had had no problems updating 2.4.0 beta using just the 53/udp allow rule and suddenly it started using 53/tcp. I'm asking specifically what would change – comparing apples to apples -- that it would suddenly use tcp.
-
The fact that you thought a 53/udp rule would ever have worked to pass DNS successfully shows that you didn't know well enough that TCP was always required.
-
The fact that you thought a 53/udp rule would ever have worked to pass DNS successfully shows that you didn't know well enough that TCP was always required.
You're still not answering my question, and I'd genuinely appreciate an answer. I'd updated the VM a dozen times just fine in the past. What specifically would cause it to change to suddenly be using tcp when in the past it used udp?
-
It doesn't matter, it is not a valid question. "Why did my rule that wasn't valid stop working?". It worked before by pure chance, now it doesn't, also by pure chance. DNS is TCP/UDP, period.
