Logging (and querying) results by IP address contained in response?

[jgrisham]

{this is probably basic; perhaps I’ve just not found the correct search terms / jargon}

AFAIK, Pi-hole currently logs in the text log, but does not store in a database^:

• the IP address returned to a client in response to a request for an A or AAAA record.

Also, while the web interface allows a ‘tail’ view of the logs, AFAIK there is no search function in that interface that would allow searching those logs by the IP address that was returned to a client in response to a DNS RR request (or for any other arbitrary text).

A. Is any of the above incorrect?

B. Has anyone found a solution (using Pi-hole or other software) for the following use case?

(^ maybe some data is stored in a RAM-based ‘cache’ database by the Dnsmasq-based ‘pihole-ftl’?)

---

Scenario: an outbound connection attempt is allowed (or blocked) by a router or a connection to an IP address is noticed either in a router connection list or on an individual end user device (e.g. via ‘netstat’ or a “Little Snitch”-style alert). Let’s say it’s a port 3329 TCP connection to 1.2.3.4.

1. A user^^ sees this and wishes to type “1.2.3.4” somewhere (e.g. a web form field) to determine what DNS requests may have provided that IP address to a client (and when).
   
   (bonus points if the request was the result of a CNAME query, and the search shows the whole ‘CNAME query tree’: leading back to the original client request; this can be especially relevant when load-balancers or CDNs are involved)

2. Assuming 1.2.3.4 doesn’t have a normal reverse DNS entry (shared hosting, inadvertently or intentionally omitted, etc.), how could this user most easilyuse the stored data on the Pi-hole to determine that ‘a client received 1.2.3.4 in response to a query for “sneakytracker.eviladtechbros.ru” at 0821 UTC today’?

3. If there is a way for a user to determine this with a simple search, presumably most competent programmers could then write a simple API allowing this sort of request to be made from a variety of methods (e.g. a command-line tool, batch-processing a .csv, or even a custom function for MS Excel), right?

(^^ This is already manually possible when a terminal shell on the Pi-hole machine itself by filtering the log file using ‘grep’ or ‘tail’; double-bonus points if this user can successfully complete this task using an iPhone or random web browser, and double-super-dog-bonus points if they are your non-technical boss or auntie)

---

Am I just re-hashing old stuff with new words here?

[jfb]

grep "1.2.3.4" /var/log/pihole.log*

tail -f /var/log/pihole.log | grep IP-address-here

[jgrisham]

@jgrisham

3. If there is a way for a user to determine this with a simple search, presumably most competent programmers could then write a simple API allowing this sort of request to be made from a variety of methods (e.g. a command-line tool, batch-processing a .csv, or even a custom function for MS Excel) , right?

Even better, one could configure/write a custom reverse-DNS resolver to do this automatically for any reverse (‘in-addr.arpa’) queries that don’t return other results (or perhaps even with an option to override authoritative results in the case of ‘chained CNAME’ queries).

• (Perhaps ‘unbound’ can already do this by running an arbitrary shell command in response to certain queries?)

Once this was enabled on a particular network, any tools that normally attempt reverse-lookups (e.g. Wireshark) would immediately and automatically benefit from this data in their user interfaces.

[yubiuser]

@jgrisham

AFAIK, Pi-hole currently logs in the text log, but does not store in a database^:

That's correct. A DNS record might change so it will return a different address tomorrow than it did yesterday. There might be only a limited use-case to save the returned IP address of records for up to a year (default database record time)

[jgrisham]

@yubiuser

There might be only a limited use-case to save the returned IP address of records for up to a year (default database record time)

Agreed. For many users, storing that sort of data likely would be an unnecessary use of memory/storage (at least as long as semi-structured text logs are still produced).

---

The most recent data presumably must exist in the FTL/Dnsmasq RAM cache (assuming the user hasn‘t disabled caching), right?

I haven’t dug deeply into that documentation/code yet, but perhaps it would be possible to query the FTL cache data directly (it wouldn’t have the query time^ or ‘cname chains’, but it would probably be enough data to do basic reverse-mapping from an IP address back to a FQDN).

(Edit: the live FTL data appears to live in shared memory at /dev/shm/FTL-*)


(^ Actually, it might… it should at least contain the necessary data in order to reconstruct the time of the most query time for that FQDN; how else would TTL-based cache eviction be possible?)

[jfb]

@jgrisham

The most recent data presumably exists in the FTL/Dnsmasq RAM cache (assuming the user hasn‘t disabled caching) , right?

The most recent 5 days of queries (plus today) are stored in text form (along with the replies) in the dnsmasq logs in /var/log.

It's a simple lookup there to get what you seek.

[jgrisham]

@jfb

The most recent 5 days of queries (plus today) are stored in text form (along with the replies) in the dnsmasq logs in /var/log.

It's a simple lookup there to get what you seek.

So, one could, for example,

A. Write a shell script that:

1. Searches /var/log/pihole.log (and the corresponding rotated daily log files) for the desired IP address:
   a. e.g. grep -e “$ipaddress” /var/log/pihole.log

2. Filters the most recent result and extract the FQDN from between the strings “reply ” (or “cached ”) and “ is”:
   a. regex: (?:reply |cached )(/S+)(?: is)
   
   b. optionally, make sure that is a valid FQDN; regex: (?=^.{4,253}\.?$)(^((?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.)+[a-zA-Z]{2,63}\.?$)

3. Repeat step #1 using the result of step #2 instead of the IP address to determine if any CNAMEs were queried that resulted in that FQDN as a response

4. Repeat step #3 until it returns no results, in order to recover an entire ‘CNAME chain’ (as are commonly used these days with CDNs)

B. Install that shell script as a CGI^ (and write a html page containing a form calling that CGI / displaying the results)^ to allow a user to do all this from a simple search field in a web browser.

^ (or whatever the kids are using these days as modern equivalents)

---

The above wouldn’t cover every case (e.g. fonts.google.com is sometimes queried directly, but other times a CNAME is queried that resolves to fonts.google.com; the above will imply that the latter always happens even if the most request request was for the former).

[jgrisham]

@jgrisham

3. Repeat step #1 using the result of step #2 instead of the IP address to determine if any CNAMEs were queried that resulted in that FQDN as a response
4. Repeat step #3 until it returns no results, in order to recover an entire ‘CNAME chain’ (as are commonly used these days with CDNs)

… except that I forgot that the CNAME result doesn’t directly show up in the logs, (i.e. on the same line; perhaps this is a configurable option).

• Example: Nov 12 01:00:01 dnsmasq[603]: reply tracker.socialstalker.co.uk is <CNAME>

So, unless that can be turned (back?) on, we’ll have to try and parse previous log lines to determine the actual query. This may be more complex depending on how many simultaneous requests are ‘in-flight’ on a particular network.

More importantly, since CNAME and host (e.g. A/AAAA) RRs often have different TTLs (i.e. a client device won’t necessarily re-request a CNAME RR if it there is a valid version in its local cache), extracting this from the logs may be more difficult/messy still.

---

Trying to parse the /dev/shm/FTL-dns-cache and /dev/shm/FTL-queries may be required after all, to try to get access to a more structured / relational version of this data.

I say harrumph.

[jgrisham]

@jgrisham

… except that I forgot that the CNAME result doesn’t directly show up in the logs, (i.e. on the same line; perhaps this is a configurable option) .

It appears that it is indeed _not_ configurable at this time:

[dnsmasq.git] / src / cache.c:

2021   else if (flags & F_CNAME)
2022     dest = "<CNAME>";

FTL / src / dnsmasq / cache.c:

1988   /**** P-hole modified: Added file and line and serve log_query via macro defined in dnsmasq.h ****/
1989   void _log_query(unsigned int flags, char *name, union all_addr *addr, char *arg, unsigned short type, const char *file, const int line)
1990   {
1991     char *source, *dest = arg;
1992     char *verb = "is";
1993     char *extra = "";
1994
1995     FTL_hook(flags, name, addr, arg, daemon->log_display_id, type, file, line);
...

FTL / src / dnsmasq / dnsmasq.h:

1266   /********************************************* Pi-hole modification ***********************************************/
1267   #define log_query(flags,name,addr,arg,type) _log_query(flags, name, addr, arg, type, __FILE__, __LINE__)
1268   void _log_query(unsigned int flags, char *name, union all_addr *addr, char *arg, unsigned short type, const char* file, const int line); 
...

[Bucking_Horn]

@jgrisham

a connection attempt is allowed (or blocked) by a router

An inbound connection attempt by an external client is only passing through your router.
Pi-hole as DNS resolver isn't involved here at all.

@jgrisham

a connection to an IP address is noticed

While such a connection is likely to be preceded by a plain DNS lookup via Pi-hole, it doesn't have to. There are other ways to resolve a domain (like DoH), Pi-hole may be by-passed via certain misconfigurations (often router's IPv6), a client may keep DNS results beyond their TTL, or a client may use hard-coded IP addresses.
So, your search may come back empty-handed, but maybe that's what you're interested in as well.

@jgrisham

except that I forgot that the CNAME result doesn’t directly show up in the logs

That's wrong.
CNAME results do show up directly in the log.
If required, they can be collated by a serial number through a custom dnsmasq configuration option log-queries=extra.

(click for sample output)

~$ grep " 241 " /var/log/pihole.log
Nov 13 08:25:17 dnsmasq[1281]: 241 192.168.1.200/52369 query[A] github-cloud.s3.amazonaws.com from 192.168.1.200
Nov 13 08:25:17 dnsmasq[1281]: 241 192.168.1.200/52369 forwarded github-cloud.s3.amazonaws.com to 127.0.1.1
Nov 13 08:25:18 dnsmasq[1281]: 241 192.168.1.200/52369 validation result is INSECURE
Nov 13 08:25:18 dnsmasq[1281]: 241 192.168.1.200/52369 reply github-cloud.s3.amazonaws.com is <CNAME>
Nov 13 08:25:18 dnsmasq[1281]: 241 192.168.1.200/52369 reply s3-1-w.amazonaws.com is <CNAME>
Nov 13 08:25:18 dnsmasq[1281]: 241 192.168.1.200/52369 reply s3-w.us-east-1.amazonaws.com is 52.216.129.115

@jgrisham

B. Has anyone found a solution (using Pi-hole or other software) for the following use case?

I think jfb's initial reply is that solution.
Combined with log-queries=extra to tackle CNAMEs, it will allow you to search the logs in any way you or others(!) see fit.

[jgrisham]

@Bucking_Horn

An inbound connection attempt by an external client is only passing through your router.
Pi-hole as DNS resolver isn't involved here at all.

Totally agreed. With any connection the router only knows the IP addresses and is completely independent of the Pi-hole; apologies if I implied otherwise. (I’ll edit the original post to make it clear I was referring to an outbound connection attempt.)

The DNS query data that exists in the Pi-hole logs / FTL cache, however, has the possibility of helping to understand how client devices may have obtained those IP addresses.

---

@Bucking_Horn

There are other ways to resolve a domain (like DoH), Pi-hole may be by-passed via certain misconfigurations (often router's IPv6), a client may keep DNS results beyond their TTL, or a client may use hard-coded IP addresses.

So, your search may come back empty-handed, but maybe that's what you're interested in as well.

Good point - while I hadn’t explicitly considered that here, a negative result could be quite useful for identifying leaks due to network mis-configurations or even hard-coded IP addresses (in addition to the other examples that you mentioned).

---

@Bucking_Horn

CNAME results do show up directly in the log.
If required, they can be collated by a serial number through a custom dnsmasq configuration option log-queries=extra .

I was a bit imprecise in my use of “directly”. I was referring to the CNAME not appearing on the same log line, which would have made a single-line ‘grep’-style (or other ‘line-based’ tools) solution easier.

... specifically, that the logs look like this (when they’re not interspersed with other requests or responses on a high-volume or high-latency installation):

Nov 13 08:25:17 dnsmasq[1281]: query[A] github-cloud.s3.amazonaws.com from 192.168.1.200
Nov 13 08:25:17 dnsmasq[1281]: forwarded github-cloud.s3.amazonaws.com to 127.0.1.1
Nov 13 08:25:18 dnsmasq[1281]: validation result is INSECURE
Nov 13 08:25:18 dnsmasq[1281]: reply github-cloud.s3.amazonaws.com is <CNAME>
Nov 13 08:25:18 dnsmasq[1281]: reply s3-1-w.amazonaws.com is <CNAME>
Nov 13 08:25:18 dnsmasq[1281]: reply s3-w.us-east-1.amazonaws.com is 52.216.129.115

... instead of this:

Nov 13 08:25:17 dnsmasq[1281]: query[A] github-cloud.s3.amazonaws.com from 192.168.1.200
Nov 13 08:25:17 dnsmasq[1281]: forwarded github-cloud.s3.amazonaws.com to 127.0.1.1
Nov 13 08:25:18 dnsmasq[1281]: validation result is INSECURE
Nov 13 08:25:18 dnsmasq[1281]: reply github-cloud.s3.amazonaws.com is s3-1-w.amazonaws.com
Nov 13 08:25:18 dnsmasq[1281]: reply s3-1-w.amazonaws.com is s3-w.us-east-1.amazonaws.com
Nov 13 08:25:18 dnsmasq[1281]: reply s3-w.us-east-1.amazonaws.com is 52.216.129.115

(line prefixes edited for clarity in both examples)

That’s not Pi-hole-specific limitation; it’s in the upstream dnsmasq code (excerpted above in a different reply). Also, for clarity, I’m not advocating for it (or anything else) to be changed.

(In case anyone asks “What’s the difference?”: with the latter the log lines can be processed without regard to order or it they could be simultaneously searched for the possible ‘parent(s)’ and ‘child’ of a CNAME with a simple ‘grep’ command.)

Using the above example log entries, a simple command such as grep -e "s3-1-w.amazonaws.com" /var/log/pihole.log, even on a fully stock installation, would produce something like:

Nov 13 08:25:18 dnsmasq[1281]: reply github-cloud.s3.amazonaws.com is s3-1-w.amazonaws.com
Nov 13 08:25:18 dnsmasq[1281]: reply s3-1-w.amazonaws.com is s3-w.us-east-1.amazonaws.com

---

@Bucking_Horn

Combined with log-queries=extra to tackle CNAMEs, it will allow you to search the logs in any way you or others(!) see fit

Thanks, I’ll look into that!

That dnsmasq option to tag each request / response with a serial number so they can be more easily correlated will help.

[jfb]

log-queries=extra

This is the dnsmasq log without this parameter set:

Nov 13 13:08:47 dnsmasq[31660]: query[A] Mac-Mini-2018 from 192.168.0.135
Nov 13 13:08:47 dnsmasq[31660]: /etc/hosts Mac-Mini-2018 is 192.168.0.135
Nov 13 13:08:57 dnsmasq[31660]: query[A] docs.pi-hole.net from 192.168.0.135
Nov 13 13:08:57 dnsmasq[31660]: forwarded docs.pi-hole.net to 127.0.0.1
Nov 13 13:08:57 dnsmasq[31660]: reply docs.pi-hole.net is <CNAME>
Nov 13 13:08:57 dnsmasq[31660]: reply pihole-docs.netlify.app is 34.204.131.44
Nov 13 13:08:57 dnsmasq[31660]: reply pihole-docs.netlify.app is 52.73.87.228

This is the log with the parameter set. The extra transaction ID will let you group all the entries that correspond to a single query.

Nov 13 13:11:26 dnsmasq[10348]: 8 192.168.0.135/59839 query[A] p34-fmip.icloud.com from 192.168.0.135
Nov 13 13:11:26 dnsmasq[10348]: 8 192.168.0.135/59839 forwarded p34-fmip.icloud.com to 127.0.0.1
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply p34-fmip.icloud.com is <CNAME>
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.202
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.199
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.196
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.197
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.212
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.207
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.217
Nov 13 13:11:27 dnsmasq[10348]: 8 192.168.0.135/59839 reply fmip.fe.apple-dns.net is 17.248.139.201
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 query[A] p66-fmip.icloud.com from 192.168.0.135
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 forwarded p66-fmip.icloud.com to 127.0.0.1
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply p66-fmip.icloud.com is <CNAME>
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.201
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.202
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.199
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.196
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.197
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.212
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.207
Nov 13 13:11:27 dnsmasq[10348]: 9 192.168.0.135/53082 reply fmip.fe.apple-dns.net is 17.248.139.217

[jgrisham]

A summary of the entire current dnsmasq/FTL cache can be dumped to pihole.log:

• sudo killall -SIGUSR1 pihole-FTL
  
  (caution: doing this repeatedly will rapidly increase the size of the log file)

The currently cached target of an IP address or CNAME (and any cached CNAME ‘parent(s)’, but not necessarily any ‘grandparent(s)’) can then be seen with a single, simple ‘grep’ search.

Example A:

$ grep -e "mix.linkedin.com" /var/log/pihole.log

Nov 13 14:06:33 dnsmasq[603]: mix.linkedin.com           any-na.mix.linkedin.com    CF    Sat Nov 13 14:07:31 2021
Nov 13 14:06:33 dnsmasq[603]: carddav.linkedin.com       mix.linkedin.com           CF    Sun Nov 14 13:48:14 2021
Nov 13 14:06:33 dnsmasq[603]: any-na.mix.linkedin.com    108.174.10.14              4F    Sun Nov 14 12:38:25 2021
Nov 13 14:06:33 dnsmasq[603]: any-na.mix.linkedin.com    2620:109:c002::6cae:a0e    6F    Sun Nov 14 13:48:14 2021

Legend:                       ^                          ^                          ^     ^
                              |_ RR                      |_ answer                  |     |_ TTL/cache expiration
                                                                                    |
                                                                                    |_ Type
                                                                                       4F: 'A' record (IPv4 host)
                                                                                       6F: 'AAAA' record (IPv6 host)
                                                                                       CF: 'CNAME' record

Not perfect by any means, but it’s a start on an alternative path towards a more automated solution.

References:

• https://superuser.com/questions/1256727/dnsmasq-cache-dump
• https://stackoverflow.com/questions/6168636/how-to-trigger-sigusr1-and-sigusr2

Example B (narrower scope, so perhaps better for use in an API):

Bash function to copy into shell (only needed once per session):
$ rdnscachesearch () { cat $1 | sed -n -r '/^(... .. [0-9:]+) dnsmasq\[([0-9]+)\]:\s+(\S+)\s+('"$2"')\s+([46CKSV ][F ][R ][I ][D ][N ][X ][H ][V ])\s+(... ... .. ..:..:.. ....)?$/s//\3/p' ; } && rdnscachesearch /var/log/pihole.log mix.linkedin.com

Command:

rdnscachesearch /var/log/pihole.log mix.linkedin.com

Output:

carddav.linkedin.com

Example C (full search of a CNAME chain):

A silly proof-of-concept function that can be pasted directly into a bash shell:

recursiverdnscachesearch ()
{
    logfile=$1
    searchterm=$2
    echo $searchterm
    last=$( cat $logfile | sed -n -r '/^(... .. [0-9:]+) dnsmasq\[([0-9]+)\]:\s+(\S+)\s+('"$searchterm"')\s+([46CKSV ])([F ][R ][I ][D ][N ][X ][H ][V ])\s+(... ... .. ..:..:.. ....)?$/s//\3/p' )
    if [ $last ]; then
        echo " |_ $last"
        recursiverdnscachesearch $logfile $last
    fi
} && recursiverdnscachesearch /var/log/pihole.log 108.174.10.14

Output:

108.174.10.14
 |_ any-na.mix.linkedin.com
any-na.mix.linkedin.com
 |_ mix.linkedin.com
mix.linkedin.com
 |_ carddav.linkedin.com
carddav.linkedin.com

(After the first time, $ recursiverdnscachesearch /var/log/pihole.log 108.174.10.14 will do the same thing.)

---

Examples B and C show what might be possible by leveraging the data that is already present on a stock Pi-hole installation ...

1. reverse_lookup 108.174.10.14:

   any-na.mix.linkedin.com
   

2. reverse_lookup_detail 108.174.10.14:

   108.174.10.14
   ​|_ any-na.mix.linkedin.com
      ​|_ mix.linkedin.com
         ​|_ carddav.linkedin.com
   

3. reverse_lookup_full 108.174.10.14:

   ​carddav.linkedin.com
   

   ​This could easily be embedded into an Excel formula to find hostnames for a whole list of IP addresses.

4. For comparison, nslookup 108.174.10.14 gives us this gem:

   ​Non-authoritative answer:
   ​
   14.10.174.108.in-addr.arpa name = 108-174-10-14.fwd.linkedin.com.
   

---

PSA for anyone still reading: A separate monitoring/logging tool such as gamelinux/passivedns has better logs than dnsmasq for CNAME answers. (It’s something else to set up and maintain, but there would also be the added benefit of being able to monitor DNS traffic that bypasses the Pi-hole.)

Technical notes for the insane:

A. dnsmasq 'cache dump' log format:

Nov 13 14:06:33 dnsmasq[603]: Host                                     Address                        Flags      Expires
                              ---------------------------------------- ------------------------------ ---------- ------------------------
Nov 13 14:06:33 dnsmasq[603]: thekelleys.org.uk              2001:ba8:1f1:f049::2                     6F      V  Sat Nov 13 19:44:43 2021

                                                                                           || Legend: _FRIDNXHV      Flag name (dnsmasq)
                                                                                           ||         |||||||||      -------------------
                                                                                           ||         |||||||||__ V: DNSSECOK
                                                                                           ||         ||||||||
                                                DS and NEG:  kkkkk aaa ddd                 ||         ||||||||___ H: HOSTS
                                                             |     |   |___ ds.digest      ||         |||||||
                                                             |     |_______ ds.algo        ||         |||||||____ X: NXDOMAIN
                                                             |_____________ ds.keytag      ||         ||||||
                                                                                           ||         ||||||_____ N: NEG
                                                DNSKKEY:     kkkkk aaa fff                 ||         |||||
                                                             |     |   |___ key.flags      ||         |||||______ D: DHCP                 
                                                             |     |_______ key.algo        \\        ||||
                                                             |_____________ key.keytag       \\       ||||_______ I: IMMORTAL
                                                                                              \\      |||
                                                SRV:         ppp www  sssss *                  \\     |||________ R: REVERSE
                                                             |   |    |____ srv.srvport         ||    ||
                                                             |   |_________ srv.weight          ||    ||_________ F: FORWARD
                                                             |_____________ srv.priority        ||    |
                                                                                                ||    |________      Record type
                                                             * (field lengths shrink to fit)    ||             |_ 4: A      - IPv4 Host
                                                                                                ||             |_ 6: AAAA   - IPv6 Host
                                                                                                ||             |_ C: CNAME  - alias to a RR
                                                                                                ||             |_ K: DNSKEY - DNSKEY
                                                                                                 \\            |_ S: DS     - Delegation Signer
                                                                                                  \\           |_ V: SRV    - Server Selection
                                                                                                   \\          |_  : (n/a)  - none of the above
                                                                                                    \\                        (e.g. TYPE65)
                                                                                                     \\
                                                                                                      \|________________________________

Nov 13 14:06:33 dnsmasq[603]: Host                                     Address                        Flags      Expires
<--------- LOG_INFO --------->---------------------------------------- ------------------------------ ---------- ------------------------
<--------- LOG_INFO --------->
                              ---------------------------------------- ------------------------------ ---------- ------------------------
MMM DD HH:MM:SS dnsmasq[PID]: HOSTNAME                       ADDRESS                                  FLAGS      EXPIRATION
MMM DD HH:MM:SS dnsmasq[PID]: HOSTNAME                       ADDRESS                                  _FRIDNXHV  DDD MMM DD HH:MM:SS YYYY
... .. [0-9:]+ dnsmasq\[(?<PID>[0-9]+)\]:\s+(?<HOST>\S+)\s+(?<ADDRESS>\S+)\s+(?<FLAGS>[46CKSV ][F ][R ][I ][D ][N ][X ][H ][V ]

Six fields:
 LOGTIME                PID   HOSTNAME                       ADDRESS                                  FLAGS      EXPIRES
      /1                 /2         /3                            /4                                  /5 /6           /7

 A. Search for /4, return /3 (recursively, if possible!; if /5 = C then recurse)
 
   
Nov 13 14:06:33 dnsmasq[603]: thekelleys.org.uk              2001:ba8:1f1:f049::2                     6F      V  Sat Nov 13 19:44:43 2021
                         ^                                                                                     ||
                         |_ (probably changes overall line length if # of digits change - jhg)                 ||
                                                                                                               ||_ Why 2 spaces?? jhg 2021-11-13
                                                                                                                   (see ref [cache.c])
                                                                                                                   

cache.c

B. dnsmasq query logging (similar to pihole.log format)

_____________________________________________________________________________________________________________________________________
|                                   (partial) TRUTH TABLE FOR DNSMASQ QUERY LOGGING STRINGS                                         |
|                                                                                                                                   |
|                                 {documented 2021-11-13 by Jim Grisham from [dnsmasq/cache.c]}                                     |
|                                                                                                                                   |
|                                                                                                                                   |
|                                                                             O |                                                   |
| |<----------------    {Internal dnsmasq flags ("F_....")}   ----------->|   P |                                                   |
|                        (see seperate table for F_NOEXTRA)                   T |                                                   |
|                                                                             _ |                                                   |
|         N                                   U                           D   E |                                                   |
| R       X                                   P   S                       N   X |                                                   |
| E       D                   R   C           S   E       S       D       S   T |                                                   |
| V       O           C       R   O       H   T   C       E   Q   N   I   S   R | |<----- {standard dnsmasq log entry fields} --->| |
| E       M   I   I   N       N   N   D   O   R   S   A   R   U   S   P   E   A |                                                   |
| R   N   A   P   P   A   S   A   F   H   S   E   T   U   V   E   S   S   C   L |                                                   |
| S   E   I   V   V   M   R   M   I   C   T   A   A   T   E   R   E   E   O   O |                                                   |
| E   G   N   4   6   E   V   E   G   P   S   M   T   H   R   Y   C   T   K   G |                                                   |
| |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   | | source     name   verb  dest      extra           |
|-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|-| ---------- ------ ---- ---------- --------------- |
|                                                     {defaults}  ---------->>> » {arg}      [a]    is   {arg}      -               |
| |```|```|```|```|```|```|```|```|```|```|```|```|```|```|```|```|```|```|```| | ``````````````````````````````````````````````````|
| -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   1   1 » -          -      -    -           (DNSSEC signed)|
| 1   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          [b]    -    {name}     -               |
| -   1   1   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    NXDOMAIN   -               |
| -   1   0   1   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    NODATA-IPv4-               |
| -   1   0   0   1   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    NODATA-IPv6-               |
| -   1   0   0   0   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    NODATA     -               |
| -   0   -   -   -   1   -   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    <CNAME>    -               |
| -   0   -   -   -   0   1   -   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    <SRV>      -               |
| -   0   -   -   -   0   0   1   -   -   -   -   -   -   -   -   -   -   -   - » -          -      -    {arg}      -               |
| -   -   -   -   -   -   -   -   1   -   -   -   -   -   -   -   -   -   -   - » config     -      -    -          -               |
| -   -   -   -   -   -   -   -   0   1   -   -   -   -   -   -   -   -   -   - » DHCP       -      -    -          -               |
| -   -   -   -   -   -   -   -   0   0   1   -   -   -   -   -   -   -   -   - » {arg}      -      -    -          -               |
| -   -   -   -   -   -   -   -   0   0   0   1   -   -   -   -   -   -   -   - » reply      -      -    -          -               |
| -   -   -   -   -   -   -   -   0   0   0   0   1   -   -   -   -   -   -   - » validation -      -    {arg}      [b]             |
| -   -   -   -   -   -   -   -   0   0   0   0   0   1   -   -   -   -   -   - » auth       -      -    -          -               |
| -   -   -   -   -   -   -   -   0   0   0   0   0   0   1   -   -   -   -   - » forwarded  -      to   -          -               |
| -   -   -   -   -   -   -   -   0   0   0   0   0   0   0   1   -   -   -   - » {arg}      -      from -          -               |
| -   -   -   -   -   -   -   -   0   0   0   0   0   0   0   0   1   -   -   - » {arg}      -      to   -          -               |
| -   -   -   -   -   -   -   -   0   0   0   0   0   0   0   0   0   1   -   - » [c]        {arg}  -    {name}     -               |
| -   -   -   -   -   -   -   -   0   0   0   0   0   0   0   0   0   0   -   - » cached     -      -    -          -               |
|                                                                               |                                                   |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|                                                                               |  -  = undefined or blank                          |
|    Key: '1' = true                                                            | [a] = sanitise(name)                              |
|         '0' = false                                                           | [b] = daemon->addrbuff;                           |
|         '-' = unevaluated, unknown, or not relevant                           | [c] = type ? "ipset add" : "nftset add";          |
|_______________________________________________________________________________|___________________________________________________|

C. If F_KEYTAG is NOT set

If F_KEYTAG is NOT set:
	 
    F_RCODE    addr->log.rcode    dest label
    -------    ---------------    ---------------
               SERVFAIL           SERVFAIL
               REFUSED            REFUSED
               NOTIMP             not implemented

D. Logging format changes with extra details

________________________________________________________________________________________________________________________
|         |                                                                                                            |
|  O      |                                                                                                            |
|  P      |                                                                                                            |
|  T      |                                                                                                            |
|  _   F  |                                                                                                            |
|  E   _  |                    my_syslog(LOG_INFO, {{Format string}}, {{Replacement values}});                         |
|  X   N  |                                                                                                            |
|  T   O  |                                                                                                            |
|  R   E  |                                                                                                            |
|  A   X  |                                                                                                            |
|  L   T  |                                                                                                            |
|  O   R  |                                                                                                            |
|  G   A  | {{Format string}}         {{Replacement values}}                                                           |
| -|---|--| ------------------------  -------------------------------------------------------------------------------- |
|  1   0  » "%u %s/%u %s %s %s %s%s"  daemon->log_display_id, daemon->addrbuff2, port, source, name, verb, dest, extra |
|  1   1  » "%u"     "%s %s %s %s%s"  daemon->log_display_id,                          source, name, verb, dest, extra |
|  0   -  »          "%s %s %s %s%s"                                                   source, name, verb, dest, extra |
|         |                                                                                                            |
|~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|         |                                                                                                            |
|         |                           int port = prettyprint_addr(daemon->log_source_addr, daemon->addrbuff2);         |
|_________|____________________________________________________________________________________________________________|