search

pi-hole / FTL

The Pi-hole FTL engine
https://pi-hole.net
Other
1.36k stars 194 forks source link

Pihole asking 1.0.0.127 for RFC1918 arpa info #1195

Closed Bingo600 closed 2 years ago

Bingo600 commented 2 years ago

Versions

Pi-hole version is v5.5 (Latest: v5.5) AdminLTE version is v5.7 (Latest: v5.7) FTL version is v5.10.2 (Latest: v5.10.2)

Platform

$ cat os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian

Expected behavior

I have a setup where my piholes are forwarding DNS queries to my two linux bind9 servers (on same subnet) No other DNS serves are specified (or selected) in the pihole-setup.

The Pi-Holes have always behaved well , and i have never seen any DNS requests to other servers. I have blocked (pfSense firewall) DNS queries from pihole ip to any other DNS servers.

After me updating my two PI-Holes to latest , PI-Hole had begun to send DNS queries to 1.0.0.127 (Cloudflare)

Actual behavior / bug

I'm beginning to see these block lines in my pfSense , after i updated yesterday. On both my piholes.

Oct 2 08:00:50 Pihole-Vlan Deny Outside access DNS from local IP's (1522486856) Pihole-IP:51765 1.0.0.127:53 UDP Oct 2 08:00:45 Pihole-Vlan Deny Outside access DNS from local IP's (1522486856) Pihole-IP:38610 1.0.0.127:53 UDP Oct 2 08:00:40 Pihole-Vlan Deny Outside access DNS from local IP's (1522486856) Pihole-IP:38610 1.0.0.127:53 UDP

Maybe see: https://forum.netgate.com/topic/166933/pi-hole-new-version-leaking/1

This is not a major issue - But why have it begun doing that ??? Pi-Hole has always been well behaved.

My pihole network is setup to a static ip , and use "localhost" as dns resolver. Technically it could be the Debian OS doing this query , i can just see it comming from the pihole ip.

`$ cat /etc/resolv.conf

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 127.0.0.1 search mydomain.org $ `

After a bit more digging , it seems to be reverse resolving of the "Top Clients" that causes the queries to 1.0.0.127 It seems there is a resolver job running every hour at 00.

Firewall log - Easy to see the hourly job - It began yesterday after pihole update to latest pihole-block.txt.zip

pfSense pcap trace of the actions today at 10:00 (just match on 1.0.0.127 UDP 53) pihole-1.0.0.127-dns-packetcapture.cap.zip

Steps to reproduce

Unknown .. It has never done that before. Well capture DNS on the hour 00 , and see if your Local (rfc1918) Top Clients also gets resolved at some external server

Debug Token

NA pihole-forwarders pihole-ver

DL6ER commented 2 years ago

Thanks for your report and sorry to hear you are experiencing an issue. Pi-hole should obviously not send queries to servers that are not configured. The IP address mentioned pretty much looks like a bug to me.

It is not entirely clear to me, also looking at the linked forum, what I think it is that Pi-hole is sending a query to the IP address 1.0.0.127 which is not configures as upstream resolver anywhere. Is this correct or is there more? I've seen a checkbox that is mentioned at the other forum that ticking/unticking changes the behavior. However, as I'm not member of this forum, I cannot see the screenshots rendering most of the discussion pretty opaque to me. You may want to mention this ticket over here so users know and see that we're discussion here and can maybe contribute (and receive the fix once we identified the issue).

This can either be a bug or a mis-configuration. Given that the embedded dnsmasq was largely re-designed within the past two versions, it may even be a hybrid because we've already seen on the dnsmasq mailing list that the interpretation of some edge-case config lines has changed.

For investigating, I'm proposing three things right now:

  1. I'd like see why Pi-hole is doing this. Could you

    grep -C5 "1.0.0.127" /var/log/pihole.log

    after a full hour and check if this IP address is mentioned? If so, can you quote a few lines?

  2. After restarting pihole-FTL (pihole restartdns), the file /var/log/pihole.log will contain a few lines like

    Oct  2 16:26:21 dnsmasq[149206]: using nameserver 127.0.0.1#5353
Oct  2 16:26:21 dnsmasq[149206]: using nameserver 192.168.2.1#53 for domain 2.168.192.in-addr.arpa (no DNSSEC)
Oct  2 16:26:21 dnsmasq[149206]: using nameserver 192.168.2.1#53 for domain fritz.box (no DNSSEC)

    Do you see similar lines? Can you quote them?

  3. Can you also provide the output of grep -R "server=" /etc/dnsmasq.* so we can check if there is an issue with your configuration?

Thanks for your assistance, we'll make sure this gets resolved quickly by providing a bugfix as soon as possible once we know what is going on. Sorry again for the trouble.

mrjohnpoz commented 2 years ago

I am seeing the same thing where queries are being made to 1.0.0.127.. I did a pihole restartdns and this is what I see

Oct  2 16:26:46 dnsmasq[25010]: exiting on receipt of SIGTERM
Oct  2 16:26:50 dnsmasq[2457]: started, version pi-hole-2.87test3 cachesize 10000
Oct  2 16:26:50 dnsmasq[2457]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Oct  2 16:26:50 dnsmasq[2457]: using nameserver 192.168.3.253#53
Oct  2 16:26:50 dnsmasq[2457]: using only locally-known addresses for onion
Oct  2 16:26:50 dnsmasq[2457]: using only locally-known addresses for bind
Oct  2 16:26:50 dnsmasq[2457]: using only locally-known addresses for invalid
Oct  2 16:26:50 dnsmasq[2457]: using only locally-known addresses for localhost
Oct  2 16:26:50 dnsmasq[2457]: using only locally-known addresses for test
Oct  2 16:26:50 dnsmasq[2457]: read /etc/hosts - 5 addresses
Oct  2 16:26:50 dnsmasq[2457]: read /etc/pihole/custom.list - 0 addresses
Oct  2 16:26:50 dnsmasq[2457]: read /etc/pihole/local.list - 0 addresses
root@pi-hole:/home/pi# grep -R "server=" /etc/dnsmasq.*
/etc/dnsmasq.conf.dpkg-dist:#server=/localnet/192.168.0.1
/etc/dnsmasq.conf.dpkg-dist:#server=/3.168.192.in-addr.arpa/10.1.2.3
/etc/dnsmasq.conf.dpkg-dist:# server=10.1.2.3@eth1
/etc/dnsmasq.conf.dpkg-dist:# server=10.1.2.3@192.168.1.1#55
/etc/dnsmasq.d/01-pihole.conf:server=192.168.3.253#53
/etc/dnsmasq.d/06-rfc6761.conf:server=/test/
/etc/dnsmasq.d/06-rfc6761.conf:server=/localhost/
/etc/dnsmasq.d/06-rfc6761.conf:server=/invalid/
/etc/dnsmasq.d/06-rfc6761.conf:server=/bind/
/etc/dnsmasq.d/06-rfc6761.conf:server=/onion/
root@pi-hole:/home/pi#

Every hour on the hour see querys to 1.0.0.127, the check markmark mentioned was for forwarding ptr, which some reason on update maybe got rechecked and no local ptrs resolved. But even with than unchecked so local ptr can be resolved still queries are being sent to 1.0.0.127

Here it did it on restartdns of pihole restart

Bingo600 commented 2 years ago

I see that mrjonpoz have also answered w. info (we're both active in the thread at Netgate too)

Here is the requested info

# grep -C5 "1.0.0.127" /var/log/pihole.log

# grep -R "server=" /etc/dnsmasq.* 
/etc/dnsmasq.d/01-pihole.conf:server=192.168.xx.102
/etc/dnsmasq.d/01-pihole.conf:server=192.168.xx.34
/etc/dnsmasq.d/06-rfc6761.conf:server=/test/
/etc/dnsmasq.d/06-rfc6761.conf:server=/localhost/
/etc/dnsmasq.d/06-rfc6761.conf:server=/invalid/
/etc/dnsmasq.d/06-rfc6761.conf:server=/bind/
/etc/dnsmasq.d/06-rfc6761.conf:server=/onion/`

$ pihole restartdns
#tail -f /var/log/pihole.log
Oct  3 06:10:38 dnsmasq[17942]: exiting on receipt of SIGTERM
Oct  3 06:10:40 dnsmasq[1351]: started, version pi-hole-2.87test3 cachesize 10000
Oct  3 06:10:40 dnsmasq[1351]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Oct  3 06:10:40 dnsmasq[1351]: using nameserver 192.168.xx.102#53
Oct  3 06:10:40 dnsmasq[1351]: using nameserver 192.168.xx.34#53
Oct  3 06:10:40 dnsmasq[1351]: using only locally-known addresses for onion
Oct  3 06:10:40 dnsmasq[1351]: using only locally-known addresses for bind
Oct  3 06:10:40 dnsmasq[1351]: using only locally-known addresses for invalid
Oct  3 06:10:40 dnsmasq[1351]: using only locally-known addresses for localhost
Oct  3 06:10:40 dnsmasq[1351]: using only locally-known addresses for test
Oct  3 06:10:40 dnsmasq[1351]: read /etc/hosts - 5 addresses
Oct  3 06:10:40 dnsmasq[1351]: read /etc/pihole/custom.list - 0 addresses
Oct  3 06:10:40 dnsmasq[1351]: read /etc/pihole/local.list - 0 addresses

Extras :-)

# cat pihole.log
Oct  3 05:59:43 dnsmasq[17942]: gravity blocked ssl.google-analytics.com is 0.0.0.0

Oct  3 06:00:10 dnsmasq[17942]: query[PTR] 101.60.xx.10.in-addr.arpa from 127.0.0.1
Oct  3 06:00:10 dnsmasq[17942]: forwarded 101.60.xx.10.in-addr.arpa to 192.168.xx.34
Oct  3 06:00:10 dnsmasq[17942]: reply 10.xx.60.101 is sv-remix-01.mydomain.org
Oct  3 06:00:20 dnsmasq[17942]: query[PTR] 146.60.xx.10.in-addr.arpa from 127.0.0.1
Oct  3 06:00:20 dnsmasq[17942]: forwarded 146.60.xx.10.in-addr.arpa to 192.168.xx.34
Oct  3 06:00:20 dnsmasq[17942]: reply 10.xx.60.146 is JeanetteiPhone.mydomain.org
Oct  3 06:00:30 dnsmasq[17942]: query[PTR] 144.60.xx.10.in-addr.arpa from 127.0.0.1
Oct  3 06:00:30 dnsmasq[17942]: forwarded 144.60.xx.10.in-addr.arpa to 192.168.xx.34
Oct  3 06:00:30 dnsmasq[17942]: reply 10.xx.60.144 is Fozz-XR.mydomain.org
Oct  3 06:00:40 dnsmasq[17942]: query[PTR] 101.30.xx.10.in-addr.arpa from 127.0.0.1
Oct  3 06:00:40 dnsmasq[17942]: forwarded 101.30.xx.10.in-addr.arpa to 192.168.xx.34
Oct  3 06:00:40 dnsmasq[17942]: reply 10.xx.30.101 is sv-lgtv-01.mydomain.org
Oct  3 06:00:50 dnsmasq[17942]: query[PTR] 102.xx.168.192.in-addr.arpa from 127.0.0.1
Oct  3 06:00:50 dnsmasq[17942]: cached 192.168.xx.102 is pippin.mydomain.org
Oct  3 06:01:00 dnsmasq[17942]: query[PTR] 34.xx.168.192.in-addr.arpa from 127.0.0.1
Oct  3 06:01:00 dnsmasq[17942]: cached 192.168.xx.34 is opiz2.mydomain.org

Oct  3 06:01:43 dnsmasq[17942]: query[A] ssl.google-analytics.com from 10.xx.60.101
# 
# grep "1.0.0.127" firewall.log
Oct  3 06:00:00 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,33018,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,57195,53,52
Oct  3 06:00:05 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,33161,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,57195,53,52
Oct  3 06:00:11 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,33751,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,49365,53,52
Oct  3 06:00:16 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,34237,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,49365,53,52
Oct  3 06:00:21 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,34958,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,37601,53,52
Oct  3 06:00:26 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,35022,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,37601,53,52
Oct  3 06:00:31 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,35755,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,42562,53,52
Oct  3 06:00:36 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,35913,0,DF,17,udp,72,192.168.xx.33,1.0.0.127,42562,53,52
Oct  3 06:00:41 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,36394,0,DF,17,udp,74,192.168.xx.33,1.0.0.127,39026,53,54
Oct  3 06:00:46 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,37352,0,DF,17,udp,74,192.168.xx.33,1.0.0.127,39026,53,54
Oct  3 06:00:51 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,38005,0,DF,17,udp,73,192.168.xx.33,1.0.0.127,47183,53,53
Oct  3 06:00:56 fw-01.mydomain.org filterlog: 197,,,1633156101,igb1.100,match,block,in,4,0x0,,64,38033,0,DF,17,udp,73,192.168.xx.33,1.0.0.127,47183,53,53
#

I tried to list info around 06:00 , from various logs too.

Referred to this issue in the Netgate (pfSense forum post)

The "interesting" picture you can't see on the forum was this , where the pihole update somehow "enabled" the : Never forward reverse lookups for private IP ranges (pihole dns settings) image

As you mention .. there's no 100% proof that it is pihole doing this query (yet) , but imho it points in that direction. I'm running it on a Deb10 VM (via the curl installer script , and i think the only two other packages installed are ntp & zabbix_agent.

mrjohnpoz is running it on a "Real PI"

Thank you for looking into this. /Bingo

mrjohnpoz commented 2 years ago

there's no 100% proof that it is pihole doing this query (yet) , but imho it points in that direction.

I have to think so as well, since a restartdns forces it to do the queries, as seen in the firewall logs I posted.

DL6ER commented 2 years ago

Okay, thanks for your responses. From @Bingo600's Pi-hole logs, at first glance, it doesn't seem like it is Pi-hole doing them (because of no grep match). Do you have no grep match, too @mrjohnpoz ?

So now we seem to enter the ugly "this is a bug" path with my current best guess is that the embedded dnsmasq is sending PTRs to some other IP address than it writes into its logs.

Looking at @Bingo600's pfSense trace from the first post, it definitely looks like some PTR requests for name refreshing, Pi-hole does on the full hour

2021-10-02 10:00:00.483058 IP 192.168.118.33.44794 > 1.0.0.127.53: 8216+ PTR? 101.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:05.487549 IP 192.168.118.33.44794 > 1.0.0.127.53: 8216+ PTR? 101.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:10.493436 IP 192.168.118.33.59323 > 1.0.0.127.53: 10436+ PTR? 146.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:15.498528 IP 192.168.118.33.59323 > 1.0.0.127.53: 10436+ PTR? 146.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:20.503358 IP 192.168.118.33.49608 > 1.0.0.127.53: 26317+ PTR? 144.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:25.508103 IP 192.168.118.33.49608 > 1.0.0.127.53: 26317+ PTR? 144.60.118.10.in-addr.arpa. (44)
2021-10-02 10:00:30.513806 IP 192.168.118.33.37184 > 1.0.0.127.53: 11834+ PTR? 101.30.118.10.in-addr.arpa. (44)
2021-10-02 10:00:35.517808 IP 192.168.118.33.37184 > 1.0.0.127.53: 11834+ PTR? 101.30.118.10.in-addr.arpa. (44)
2021-10-02 10:00:40.523492 IP 192.168.118.33.38499 > 1.0.0.127.53: 64632+ PTR? 34.118.168.192.in-addr.arpa. (45)
2021-10-02 10:00:45.528469 IP 192.168.118.33.38499 > 1.0.0.127.53: 64632+ PTR? 34.118.168.192.in-addr.arpa. (45)
2021-10-02 10:00:50.533940 IP 192.168.118.33.44045 > 1.0.0.127.53: 53371+ PTR? 102.118.168.192.in-addr.arpa. (46)
2021-10-02 10:00:55.539037 IP 192.168.118.33.44045 > 1.0.0.127.53: 53371+ PTR? 102.118.168.192.in-addr.arpa. (46)

Can you get the corresponding lines from /var/log/pihole.log ? They might have been rotated away into the file /var/log/pihole.log.1 meanwhile.

mrjohnpoz commented 2 years ago

I get no grep match either. for grep -C5 "1.0.0.127" /var/log/pihole.log

But if I do restartdns, instantly I see the queries being blocked at the firewall.

hits

And also see them on the hour every hour.

hour

hour23

And I really have nothing installed on the pi, other than pihole

root@pi-hole:/home/pi# uname -a
Linux pi-hole 5.10.60-v7+ pi-hole/pi-hole#1449 SMP Wed Aug 25 15:00:01 BST 2021 armv7l GNU/Linux
root@pi-hole:/home/pi# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
root@pi-hole:/home/pi#
DL6ER commented 2 years ago

Okay, thanks. What we currently know is that Pi-hole is forwarding the queries to a server that is not configured but doesn't log this. A plausible explanation is that some bug causes the send routines to send to another server than the application actually wants to. We'll get this fixed. Bugs are not allowed to survive!

I'd like to ask you to add two additional debug settings:

  1. Enable debugging mode of FTL Please add

    DEBUG_QUERIES=true

    to the file /etc/pihole/pihole-FTL.conf (create if it does not exist)

    Next time this happens, there should be corresponding lines also in /var/log/pihole-FTL.conf

  2. Enable Pi-hole's internal pcap generation as well. This way we can look both at the firewall and the Pi-hole's recordings. They should match but I just want to verify this. Please add

    dumpfile=/tmp/pihole.pcap
dumpmask=0xFFFF

    to a new file /etc/dnsmasq.d/99-pcap.conf

After you did that, run

pihole restartdns

so FTL uses the new configuration.

When this happens again, please attach:

  1. Corresponding lines from /var/log/pihole.log
  2. Corresponding lines from /var/log/pihole-FTL.log
  3. pfSense pcap
  4. Pi-hole's pcap (/tmp/pihole.pcap)
DL6ER commented 2 years ago

Ah, stop that. I know what is going on: We're using the constant INADDR_LOOPBACK which is in host byte order while the struct in_addr expects the address in network byte order (reversed). This transforms the IP address 127.0.0.1 for internal queries into 1.0.0.127 (reversed bytes).

Please try if

pihole checkout ftl fix/local_queries

resolves the issue for you.

Bingo600 commented 2 years ago

My guess too ... From the pfSense thread

image

So no need to send the debug pcaps etc .. I just managed to set it up for 10:00 today

Btw: If i checkout that "Branch" , easily could i revert to the "master" ? pihole seems rather angry when i run that command , so i ansvered NO in the first place.

Is in summerhouse , have to drive back .. Wifeys order Would be 3+ hours

DL6ER commented 2 years ago

Nothing usually breaks, this is just too stop people checking out random branches (sometimes years old) and of course things break when combining a v2.10 branch with otherwise v5 components. But really no need to rush. I just want to provide a fix and you can test it whenever you want.

It was indeed a network/host byte order issue as the documentation on that sockaddr and in_addr need different byte order wasn't very clear

Maybe @mrjohnpoz can confirm with less "risk" :-)

mrjohnpoz commented 2 years ago

I just applied that version.. And seems to have fixed it.. I see no queries on restartdns in the firewall. I am still able to resolve my local PTR records. I do see blocks in the firewall at 6am, in about 20 minutes at 7am here will be able to tell if the hourly queries no longer happen.. 


root@pi-hole:/home/pi# pihole checkout ftl fix/local_queries
  Please note that changing branches severely alters your Pi-hole subsystems
  Features that work on the master branch, may not on a development branch
  This feature is NOT supported unless a Pi-hole developer explicitly asks!
  Have you read and understood this? [y/N] y

  [✓] Branch fix/local_queries exists
  [i] Switching to branch: "fix/local_queries" from "master"
  [✓] Downloading and Installing FTL
  [✓] Restarting pihole-FTL service...
  [✓] Enabling pihole-FTL service to start on reboot...
root@pi-hole:/home/pi# pihole restartdns
  [✓] Restarting DNS server
DL6ER commented 2 years ago

The linked PR #1196 should fix this. I also edited the title as the mentioning of "Cloudflare" confused not only me and kinda slowed down finding the real cause (network byte order). Thanks for your reports and your continued tests and debugging efforts! This all helps us a lot to make an ever better software for us all!

mrjohnpoz commented 2 years ago

So it is now couple minutes after 7am here - and I see no queries for that 1.0.0.127 in my firewall.

Thank You for the quick fix..

Bingo600 commented 2 years ago

I can corfirm that i have no pfSense blocks on my "Summerhouse" pihole , after switching to the suggested release. My "Home" pihole hasn't been switched , and here the firewall still logs the 1.0.0.127.

Re: Cloudflare - It was who "whois" said owned the IP block.


$ whois 1.0.0.127
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '1.0.0.0 - 1.0.0.255'

% Abuse contact for '1.0.0.0 - 1.0.0.255' is 'helpdesk@apnic.net'

inetnum:        1.0.0.0 - 1.0.0.255
netname:        APNIC-LABS
descr:          APNIC and Cloudflare DNS Resolver project
descr:          Routed globally by AS13335/Cloudflare
descr:          Research prefix for APNIC Labs
country:        AU
org:            ORG-ARAD1-AP
admin-c:        AR302-AP
tech-c:         AR302-AP
abuse-c:        AA1412-AP
status:         ASSIGNED PORTABLE
remarks:        ---------------
remarks:        All Cloudflare abuse reporting can be done via
remarks:        resolver-abuse@cloudflare.com
remarks:        ---------------
mnt-by:         APNIC-HM
mnt-routes:     MAINT-AU-APNIC-GM85-AP
mnt-irt:        IRT-APNICRANDNET-AU
last-modified:  2020-07-15T13:10:57Z
source:         APNIC

irt:            IRT-APNICRANDNET-AU
address:        PO Box 3646
address:        South Brisbane, QLD 4101
address:        Australia
e-mail:         helpdesk@apnic.net
abuse-mailbox:  helpdesk@apnic.net
admin-c:        AR302-AP
tech-c:         AR302-AP
auth:           # Filtered
remarks:        helpdesk@apnic.net was validated on 2021-02-09
mnt-by:         MAINT-AU-APNIC-GM85-AP
last-modified:  2021-03-09T01:10:21Z
source:         APNIC

organisation:   ORG-ARAD1-AP
org-name:       APNIC Research and Development
country:        AU
address:        6 Cordelia St
phone:          +61-7-38583100
fax-no:         +61-7-38583199
e-mail:         helpdesk@apnic.net
mnt-ref:        APNIC-HM
mnt-by:         APNIC-HM
last-modified:  2017-10-11T01:28:39Z
source:         APNIC

role:           ABUSE APNICRANDNETAU
address:        PO Box 3646
address:        South Brisbane, QLD 4101
address:        Australia
country:        ZZ
phone:          +000000000
e-mail:         helpdesk@apnic.net
admin-c:        AR302-AP
tech-c:         AR302-AP
nic-hdl:        AA1412-AP
remarks:        Generated from irt object IRT-APNICRANDNET-AU
abuse-mailbox:  helpdesk@apnic.net
mnt-by:         APNIC-ABUSE
last-modified:  2021-03-09T01:10:22Z
source:         APNIC

role:           APNIC RESEARCH
address:        PO Box 3646
address:        South Brisbane, QLD 4101
address:        Australia
country:        AU
phone:          +61-7-3858-3188
fax-no:         +61-7-3858-3199
e-mail:         research@apnic.net
nic-hdl:        AR302-AP
tech-c:         AH256-AP
admin-c:        AH256-AP
mnt-by:         MAINT-APNIC-AP
last-modified:  2018-04-04T04:26:04Z
source:         APNIC

% Information related to '1.0.0.0/24AS13335'

route:          1.0.0.0/24
origin:         AS13335
descr:          APNIC Research and Development
                6 Cordelia St
mnt-by:         MAINT-AU-APNIC-GM85-AP
last-modified:  2018-03-16T16:58:27Z
source:         APNIC

% This query was served by the APNIC Whois Service version 1.88.15-SNAPSHOT (WHOIS-UK3)

$

Thank you for the Quick fix.

Btw. Any Quick guide on how2 switch back to master branch ?

yubiuser commented 2 years ago

Btw. Any Quick guide on how2 switch back to master branch ?

pihole checkout master

DL6ER commented 2 years ago

The next version of FTL has been released. Please update and run

pihole checkout master

to get back on-track. The branch you switched to will not receive any further updates.

Thanks for helping us to make Pi-hole better for us all!

If you have any issues, please either reopen this ticket or (preferably) create a new ticket describing the issues in further detail and only reference this ticket. This will help us to help you best.