filterlog output question
-
In my filter log I have a lot of entries like
[meta sequenceId="55257"] DNS-reply,Nov 15 12:05:14,resolver,DS,NSEC3,900,nyt.com,127.0.0.1,NSEC3,unkWhat is the significance of NSEC3,unk? Is this the result of a mis-configuration in my pfSense?
I am using 25.07-1 Release and KEA
In General Setup I have DNS servers blank and using the default loopback w/ fallback to remote DNS for resolution.Or is this just routine chatter in DNS?
-
After waiting nearly a month, I am replying to myself in case someone else finds this useful. I decided to google the entry. Should have done that to begin with. A hit from wikipedia produced:
Context of the Reply
This DNS reply indicates that a query was made for the domain "nyt.com" and the response included security-related records (DS and NSEC3). The use of a local IP address (127.0.0.1) suggests that the query was processed by a local DNS resolver, possibly for testing or development purposes. The "unk" status may require further investigation to determine its significance.That answers my question.
-
DNS-reply,Nov 15 12:05:14,resolver,DS,NSEC3,900,nyt.com,127.0.0.1,NSEC3,unk
DNSSEC is a more involved as classic DNS resolve process.
DNS request are 'NS' 'A', and probably 'AAAA' requests.
DNSSEC adds more types : DS, RRSIG, DNSKEY, maybe NSEC3 and some others are also possible.Here you can see them : https://dnsviz.net/d/test-domaine.fr/dnssec/ and unbound resolves them all from top to bottom to and up with a signed (so secure) final answer.
https://dnsviz.net/d/test-domaine.fr/dnssec/
Go to "Responses" to see them all : https://dnsviz.net/d/test-domaine.fr/responses/
The good news is that most of these replies can and will be cached, so the final DNS traffic will be less.edit : your https://dnsviz.net/d/nyt.com/dnssec/ = nyt.com isn't using DNSSEC.
That is, the 'root' (== ID 20326 for now) is signed for many years now, as is the dot com TLD.
The owner of 'nyt' domain didn't bother to activate the DNSSEC functionality, as he probably doesn't know what DNS spoofing is, and what the risk is if it happens. -
@Gertjan Thanks!! I'll check that link out. The main reason I'm looking at this stuff is the NSEC and DNSKEY are new to me. But also, in my little home network I have a lot of Apple devices w/ Bonjour (Avahi) and I see stuff like
DNS-reply,Dec 11 21:41:56,cache,A,A,3567,Jean-iPhone.local,192.168.10.68,NXDOMAIN,unkThat Apple device is set to auto dhcp and so it gets .local because it's Apple.
I'm trying to figure out how to 'fix' NXDOMAIN and not getting anwhere. pfSense is using a domain of .home.arpa but this apple device is using .local for a domain. I discovered that is due to MDNS and so don't know if this is just the way logging handles it or if there is a setting I can fiddle with.
I run the unbound resolver.
I tried pinging Jean-iPhone.local and nothing. But pinging the IP works fine. Now I'm wondering if I toggle Avahi setting for "disable support for ipV4" will have a negative effect. Seems to me that it may not matter but I need to find more info before I start messing around. Maybe I should just live with NXDOMAIN log entry and not worry about it since everything is working.
One thing I found that I need to spend more time with is in the Apple device I have a search domain of both pfSense IP and .local and when I remove .local from one device it looks like it cleared the logs up. I need to review them more carefully.
-
@JonH said in filterlog output question:
I tried pinging Jean-iPhone.local and nothing. But pinging the IP works fine
Don't bother with .local. Use Jean-iPhone.home.arpa.
When unbound starts, it uses this file : /etc/hosts
This host file is created with hosts that are know to the system : goto Services > DHCP Server > LAN at the bottom of the page : all the static MAC lease you've created.
You can also inform the DHCP server to 'register' into the DNS all the host names it receives, these will also be added to /etc/hosts - and will thus be known by unbound as 'locally avaible'.Example :
add all your devices you have, map them to an IP, and now you can chose also the host name of every device, even if the use themselves another name.
(btw : the same list has to be created for all IPv6 capable devices)
Ones done, it's easy to maintain..local is probably Apple stuff. I've several iphone and pads here, and not one device is asking for 'myappledevice.local'.
My devices receive, when doing a DHCP lease (V4 and V6), my local domain name: "bhf.tld", so my phone is known in my network as "Gertjan.bhf.tld" and it points to 192.168.1.46 (and its IPv6 GUA equivalent also).
I use Avahi.
I use kea. -
@Gertjan said in filterlog output question:
.local is probably Apple stuff. I've several iphone and pads here, and not one device is asking for 'myappledevice.local'.
My devices receive, when doing a DHCP lease (V4 and V6), my local domain name: "bhf.tld", so my phone is known in my network as "Gertjan.bhf.tld" and it points to 192.168.1.46 (and its IPv6 GUA equivalent also).
I use Avahi.
I use kea.Thanks again, I'm grateful for your input. .local is most certainly Apple's implementation for its networking ecosphere. I was afraid that without 'local' in the search domain that apple devices would not work correctly between each other on my lan side. Apparently I was mistaken. I do have 6 devices that are 'airplay' so I remain uncertain if not using local with them will work so I'll know that answer shortly.
In addition to Avahi & kea, I use UniFi WAP behind my pfSense but that AP does not handle DNS/DHCP so I cannot specify the domain within UniFi's controller. Going through most, but not yet all of my Apple devices I found that I had added local as a 'search domain'. A quick look at logging indicates that my problem may have been resolved by removing the search domain entry but I'll need to monitor my logs longer to understand if removing this search domain 'fixed' my perceived issue with NXDOMAIN entries.
As for apple & .local, apparently the fact that I had local as a search domain seemed to insert that domain suffix into the DNS config within the devices. This would explain why you don't have .local on any of your apple devices yet mine did. I haven't yet checked all of them.
I also looked for search domain in the pfSense resolver but unless it's simply not there I missed it. Maybe it is a client and not a server setting. I'm just a half-literate shade-tree DIY guy so there is a lot of advanced details in pfSense that elude me in spite of studying the documentation.
I have mapped a couple of IP's but most remain unmapped as I don't really have a need to address them often enough to make it worth my time. Even the mapped IP's had a client domain of .local entry in the logs before I removed the search domain entry.
I'm going to have to put all this stuff on the back burner now that I have the 25.11 release notes and install to do.
